※本記事のコードは参考情報です。Schema.org仕様やGoogleガイドラインは随時変更されます。実装は自己責任で。
1. なぜWeb3ブログに構造化データが必須なのか
仮想通貨・Web3情報が直面する「YMYL」の壁
ユーザーの財産や人生に重大な影響を与える情報を扱う領域において、検索エンジンは情報の信頼性を極めて厳しくチェックしています。特にビットコイン(BTC)やDeFi、新たなL1・L2ブロックチェーンなどのWeb3領域は、詐欺的な情報も多く、個人メディアがテキストだけで発信者の素性や信頼性を証明するのは困難な時代です。
Googleはこの領域を「YMYL(Your Money or Your Life)」と定義し、医療・法律・金融と同等の評価基準を適用します。個人ブログであっても例外はありません。
E-E-A-Tを言葉ではなく「コード」で証明する
記事内に「私はWeb3のアナリストです」「コミュニティのモデレーターをやっています」と日本語で書いても、検索エンジンがその言葉を発信者の信頼性と正確に紐付けるには時間がかかります。
そこで必要になるのが構造化データ(JSON-LD)です。構造化データとは、サイトの運営者・執筆者の経歴・サイトの目的を、検索エンジンのクローラーが一発で理解できるように記述する「仕様書」です。発信者の信頼性を検索エンジンに正確に自己申告するための、公式かつ最適な手段といえます。
特にYMYLカテゴリでは、E-E-A-T(経験・専門性・権威性・信頼性)の4要素をコードレベルで申告できるかどうかが、長期的な検索評価を左右します。
2. 実装した構造の全体像:@graph エンティティグラフの設計思想
当ブログ「Blockchain FAQ」では、ページごとにバラバラのJSON-LDを記述するのではなく、1つの<script>タグ内に@graph(グラフ構造)を用いてすべてのエンティティを内包させる設計を採用しています。一世代前のMovable typeベースのライブドアブログCMSでは、WordPressのようなプラグインが存在しないため、テンプレートHTMLに直接コードを埋め込む必要があります。その制約の中で、いかにしてWordPress有料テーマと同等の構造を実現するか、その設計思想を公開します。
Person → Organization → WebSite の連鎖
検索エンジンに伝えているのは、以下のような「エンティティ(実体)の繋がり」です。
- 「nukolcore.core(
Person= 執筆者・アナリスト)」という人物がいる - その人物が「Blockchain FAQ(
Organization)」のFounderである - その組織が運営するメディアが「Blockchain FAQ(
WebSite)」である - この記事(
Article)はそのWebSiteの一部であり、そのPersonが執筆した
各エンティティに一意の@id(固有識別子)を付与し、isPartOf・author・founder・mainEntityといったプロパティで相互に参照させることで、「誰がどこで何を発信しているのか」の相関図を構造化データとして完成させます。
全ページ共通の3つのアンカーノード
当ブログでは以下の3ノードを全ページのJSON-LDに共通して宣言し、ページ固有のノード(Article・CollectionPage等)がこれらを@id参照する設計にしています。
- WebSite(
#website):サイト全体の定義・SearchAction - Organization(
#organization):運営主体・ロゴ・Founder参照 - Person(
#author):執筆者の詳細・sameAs・hasCredential
この設計により、トップページ・個別記事・カテゴリアーカイブ・プロフィールページのいずれにアクセスしても、検索エンジンは「同一の著者が書いた同一のサイトのコンテンツ」として一貫して認識できます。
※この選択が後述するGSC警告の原因になる(Section 6で詳述)
3. ライブドアブログCMSでの実装コードと解説
WordPressであればプラグインが自動生成してくれますが、一世代前のMovable typeベースのライブドアブログCMSでは標準のテンプレートHTMLをカスタマイズし、ライブドアブログ独自のテンプレートタグ変数(独自タグ)とJavaScriptを組み合わせる必要があります。
① JSON-LD(@graph)のベースコード:個別記事テンプレート
個別記事テンプレートの</body>直前に以下を配置します。<$ArticlePermalink$>等はライブドアブログの独自タグで、ページ生成時に動的な値へ置換されます。
Article と BlogPosting のどちらを使うか
Schema.orgではArticle(記事全般)と、そのサブタイプであるBlogPosting(ブログ投稿に特化)のどちらも使用できます。純粋なブログ記事であれば意味的にはBlogPostingの方がより正確な申告になります。ただし当ブログでは、技術分析・一次情報・教育記事といった多様なコンテンツを扱うメディアとしての性格を重視し、Articleを採用しています。GSC計測データの継続性を維持することを考慮した総合的な判断です。
"@type": "Article" の部分を "@type": "BlogPosting" に置き換えてください。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Article",
"@id": "<$ArticlePermalink$>#article",
"isPartOf": { "@id": "https://blockchain-faq.xyz/#website" },
"author": { "@id": "https://blockchain-faq.xyz/about.html#author" },
"publisher": { "@id": "https://blockchain-faq.xyz/#organization" },
"headline": "<$ArticleTitle ESCAPE$>",
"description": "<$ArticleDescription ESCAPE$>",
"datePublished": "<$ArticleDateISO8601$>",
"dateModified": "<$ArticleDateISO8601$>", // ← JS動的更新で上書きされます(Section 4参照)
"articleSection": "<$ArticleCategory$>",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "<$ArticlePermalink$>"
},
"image": {
"@type": "ImageObject",
"url": "https://livedoor.blogimg.jp/nuko_at_core/imgs/f/6/f632e3fe.png",
"width": 1200,
"height": 630
}
},
{
"@type": "WebSite",
"@id": "https://blockchain-faq.xyz/#website",
"url": "https://blockchain-faq.xyz/",
"name": "Blockchain FAQ:仮想通貨とWeb3.0を深掘りする専門ブログ",
"publisher": { "@id": "https://blockchain-faq.xyz/#organization" }
},
{
"@type": "Organization",
"@id": "https://blockchain-faq.xyz/#organization",
"name": "Blockchain FAQ",
"url": "https://blockchain-faq.xyz/",
"logo": {
"@type": "ImageObject",
"url": "https://livedoor.blogimg.jp/nuko_at_core/imgs/f/2/f2129b64.jpg",
"width": 400,
"height": 400
},
"founder": { "@id": "https://blockchain-faq.xyz/about.html#author" }
},
{
"@type": "BreadcrumbList",
"@id": "<$ArticlePermalink$>#breadcrumb",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "ホーム",
"item": "https://blockchain-faq.xyz/"
},
{
"@type": "ListItem",
"position": 2,
"name": "<$ArticleTitle ESCAPE$>",
"item": "<$ArticlePermalink$>"
}
]
}
]
}
</script>
主要なライブドアブログ独自タグ一覧
<$ArticlePermalink$>:記事の固定URL<$ArticleTitle ESCAPE$>:記事タイトル(HTMLエスケープ済み)<$ArticleDescription ESCAPE$>:記事の説明文<$ArticleDateISO8601$>:公開日時(ISO8601形式)<$ArticleCategory$>:設定カテゴリ名(第1カテゴリ)
② Person(著者)ノードの実装:about.htmlへの配置
著者情報は個別記事テンプレートに記述するのではなく、プロフィールページ(about.html等)の本文内に単独で定義し、全ページから@id参照する設計が最も効率的です。
※ライブドアブログでは【画像/file】からアップロードした静的HTMLページを運用する方法もありますが、静的ページはCMS管理画面から編集できないため、当ブログでは個別記事として運用しています。この選択が後々、構造化データ上のトラブルを招くことになりましたが……(Section 6で詳述)。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Person",
"@id": "https://blockchain-faq.xyz/about.html#author",
"name": "nukolcore.core",
"image": {
"@type": "ImageObject",
"url": "https://livedoor.blogimg.jp/nuko_at_core/imgs/5/7/57867ee0.jpg",
"width": 800,
"height": 800
},
"url": "https://blockchain-faq.xyz/about.html",
"description": "CoreDAOテストネット黎明期(2022年9月)からエコシステムに参加し、480本以上の技術分析・教育記事を公開。LiteCORE DAOコミュニティ運営統括・Core JP Community Mods・2025年Bitget推奨ブロガーとして日本語圏のWeb3知識普及に取り組むアナリスト兼アーキビスト。",
"sameAs": [
"https://x.com/Okusuri2020",
"https://x.com/LiteC0REDA0",
"https://litecoredao.com/",
"https://litecoredao.com/ja/",
"https://sites.google.com/view/btcs-core/",
"https://blog.with2.net/link/?id=2121544",
"https://t.me/nuko_core",
"https://www.bitget.com/ja/wiki/1196909"
],
"knowsAbout": ["CoreDAO", "BTCfi", "Bitcoin DeFi", "L1 Blockchain", "L2 Blockchain", "DPoW Consensus", "Web3 Community", "DAO Governance", "Tokenomics"],
"hasCredential": {
"@type": "EducationalOccupationalCredential",
"name": "Bitget Wiki 推奨ブロガー(2025年2月選出)",
"url": "https://www.bitget.com/ja/wiki/1196909"
},
"jobTitle": "アナリスト / アーキビスト / コミュニティ運営統括"
},
{
"@type": "ProfilePage",
"@id": "https://blockchain-faq.xyz/about.html#profilepage",
"url": "https://blockchain-faq.xyz/about.html",
"name": "著者プロフィール:CoreDAOテクニカルオーソリティ & Web3コミュニティ戦略家",
"dateModified": "2026-05-06T00:00:00+09:00",
"mainEntity": { "@id": "https://blockchain-faq.xyz/about.html#author" },
"isPartOf": { "@id": "https://blockchain-faq.xyz/#website" }
}
]
}
</script>
Personノード設計の重要ポイント
- sameAs:実在性を証明できる外部URLを可能な限り列挙する。Googleはこの一覧からエンティティの実在性を検証する
- hasCredential:外部機関からの認定実績がある場合は必ず記述する。YMYLカテゴリでの権威性証明として直接機能する
- ProfilePageのauthorプロパティは設定しない:
mainEntityでPersonを指定しているため、authorを重複して記述すると警告が発生する
4. 【難所】dateModifiedをJavaScriptで動的に書き換える
ライブドアブログCMSの最大の制約として、「記事を最終更新した日時(dateModified)」を出力する独自タグが存在しません。
情報の新鮮さや定期的なメンテナンスを証明するdateModifiedは、特にYMYLカテゴリにおいて検索エンジンが重視するシグナルです。現在のデファクトスタンダードであるWordPressでは提供されているタグですが、用意されていない以上利用できません。これを補完するため、当ブログでは以下の方法を実装しました。
実装の仕組み:HTMLコメント → JavaScript → JSON-LD注入
- 記事をリライトした際、記事本文の任意の箇所にHTMLコメントで更新日を記録する
- JavaScriptがページ読み込み時にそのコメントを検索・抽出する
- 抽出した日付をISO8601形式に整形してJSON-LD内の
dateModifiedを上書きする
記事本文への記述方法
リライト・更新した記事の本文内の任意の位置(末尾推奨)に以下を記述します。
<!-- last-modified: 2026-05-22 -->
このHTMLコメントは画面上には表示されません。記事を更新した日付に書き換えるだけで、後述のJavaScriptが自動的にJSON-LDを更新します。なお、コメント内の日付はYYYY-MM-DD形式(10文字)で記述します。ライブドアブログCMSの『定型文』にテンプレート登録して、日付のみ書き換えるのがイージーです。ISO8601への変換・タイムゾーン補完は後述のJavaScript側で自動処理します。
JavaScript実装コード(テンプレートのbody末尾に配置)
<script>
document.addEventListener("DOMContentLoaded", function() {
const publishedMeta = document.querySelector('meta[property="article:published_time"]');
// TreeWalkerでHTMLコメントノードのみを安全に走査
let manualDate = null;
const walker = document.createTreeWalker(
document.body,
NodeFilter.SHOW_COMMENT,
null,
false
);
let node;
while (node = walker.nextNode()) {
const m = node.nodeValue.match(/^\s*last-modified:\s*(\d{4}-\d{2}-\d{2})\s*$/);
if (m) { manualDate = m[1]; break; }
}
const publishedRaw = publishedMeta ? publishedMeta.getAttribute("content") : null;
if (!manualDate && !publishedRaw) return;
const jsonLdScripts = document.querySelectorAll('script[type="application/ld+json"]');
jsonLdScripts.forEach(function(script) {
try {
let jsonData = JSON.parse(script.textContent);
if (!jsonData) return;
let updated = false;
function processItem(item) {
if (item["@type"] === "Article" || item["@type"] === "BlogPosting") {
let pubDateStr = item["datePublished"] || publishedRaw || "";
// 日付のみ(10文字)の場合にタイムゾーンを補完
if (pubDateStr.length === 10) {
pubDateStr = pubDateStr + "T00:00:00+09:00";
item["datePublished"] = pubDateStr;
}
if (manualDate) {
const pubDay = pubDateStr.substring(0, 10);
if (manualDate === pubDay) {
item["dateModified"] = pubDateStr;
} else {
// 更新日が公開日と異なる場合:23:59:59+09:00を付与
item["dateModified"] = manualDate + "T23:59:59+09:00";
}
} else {
item["dateModified"] = pubDateStr;
}
updated = true;
}
}
if (Array.isArray(jsonData["@graph"])) {
jsonData["@graph"].forEach(processItem);
} else {
processItem(jsonData);
}
if (updated) {
script.textContent = JSON.stringify(jsonData, null, 2);
}
} catch(e) {
console.warn("JSON-LD update error:", e);
}
});
});
</script>
innerHTML ではなく TreeWalker を使う理由
document.body.innerHTMLから正規表現で検索する方法は、サードパーティスクリプトのHTMLコメントを誤検知するリスクがあります。TreeWalkerでコメントノードのみを走査することで、安全に抽出できます。
Googlebotはこのスクリプトを読めるか
GooglebotはChromiumベースのレンダリングエンジンを持ち、JavaScriptを実行してからページを評価します。公式の「リッチリザルトテスト」を用いて、このスクリプトによるJSON-LDの書き換えがレンダリング後に正しく反映されていることを実際に確認済みです。
JSON-LDでdateModifiedを正しく構造化することが本実装の主目的です。そのため、記事をアップデートする際には本文の修正と併せて更新日コメントの調整を行うことを運用ルールとしています。この一連の作業により、ライブドアブログの制約下でもYMYL領域に求められる情報の鮮度シグナルを適切に発信できるようになります。
5. Microdataとの競合問題と解決
ライブドアブログのデフォルトHTMLテンプレートには、古い構造化データ仕様であるMicrodata(HTMLタグ内にitemscope・itemprop等を直接記述する形式)が埋め込まれています。
なぜ除去が必要か
1つのページ内に「古いMicrodataによる不完全なデータ」と「新しく追加した高度なJSON-LD(@graph)」が混在すると、クローラーが混乱し、構造化データのエラーの原因になります。
除去した箇所と残した箇所の判断基準
除去した箇所
- 個別記事テンプレートの
<html>タグ:itemscope itemtype="http://schema.org/Blog" - 記事ループ内の
<article>タグ:itemscope itemtype="http://schema.org/BlogPosting" - 記事タイトルの
<h1>・<a>:itemprop="name"・itemprop="url" - 公開日の
<time>タグ:itemprop="datePublished" - 記事本文の
<div>:itemprop="articleBody"
残した箇所とその理由
- トップページの
<html>タグ:CMSが自動出力する範囲のため除去が困難。JSON-LDが優先的に評価されるため実害は軽微です。 - about.html本文内のitemprop:記事本文として手書きしているため残存しているが、JSON-LDノードが完全に定義されているため影響は限定的です。
6. Google Search Consoleでの問題検出と解決の記録
2026年5月22日、Google Search Consoleから当ブログに対して以下の通知が届きました。
「https://blockchain-faq.xyz/ で新しいプロフィールページの構造化データの問題が検出されました」
- 「dateModified」の日時値が無効です
- 項目「author」を認識できません
問題① dateModified の日時値が無効
原因:about.htmlのProfilePageノードで"dateModified": "2026-05-06"と日付のみを記述していた。GoogleはISO8601完全形式を要求するためです。
// 修正前
"dateModified": "2026-05-06"
// 修正後
"dateModified": "2026-05-06T00:00:00+09:00"
問題② 項目「author」を認識できません
原因:ProfilePageノードにauthorとmainEntityの両方が設定されていたためです。正式プロパティであるmainEntityのみに絞る必要があります。
// 修正前
{
"@type": "ProfilePage",
"author": { "@id": "...#author" }, ← 削除
"mainEntity": { "@id": "...#author" }
}
// 修正後
{
"@type": "ProfilePage",
"mainEntity": { "@id": "...#author" }
}
問題③ robots.txtによるCSSリソースのブロック
原因:設定していたDisallow: /*?*が、内部のCSSやJSファイルまでブロックしていたためです。
# 修正前
Disallow: /*?*
# 修正後(/*?* を削除し、個別にAllow指定)
Allow: /*.css?*
Allow: /*.js?*
Allow: /settings/*
7. リッチリザルトテストでの検証結果
上記すべての修正後、Googleの公式ツール「リッチリザルトテスト」で各ページタイプを検証しました。
about.html(プロフィールページ)
- 検出されたアイテム:nukolcore.core(ProfilePage) ✅ 有効
- 警告:0件(修正前は2件)
カテゴリアーカイブページ
- 検出されたアイテム:BreadcrumbList ✅ 有効
8. 無料CMSでWordPress有料テーマ同等を実現したコスト比較
「インフラを整えるために、毎月高いサーバー代を払ってWordPressを維持し、数万円の有料テーマを買う」というのは、個人ブロガーや立ち上げ初期のWeb3コミュニティにとって小さくないコストです。
| 項目 | WordPress+有料テーマ | ライブドアブログ+手実装(当ブログ) |
|---|---|---|
| サーバー・ドメイン代(年間) | 約15,000〜30,000円 | 約1,650円(独自ドメイン代のみ) |
| 有料テーマ・プラグイン | SWELL(17,600円)等+Yoast Premium(19,800円/年) | 0円(HTML/CSS/JSの手実装) |
| @graph エンティティグラフ | テーマ・プラグインの仕様に依存 | 完全自由設計・独自実装 |
| ProfilePage・CollectionPage対応 | Yoast等のプラグインでは非対応→手動JSON-LD実装が別途必要 | テンプレートに直接実装済み |
| sameAs・hasCredential等の詳細設定 | プラグインUIの範囲外→手動実装が必要 | 任意で自由に設定可能 |
注目すべきは、WordPressの有料プラグインが自動生成する@graphでも、詳細設定等はプラグインの対応外であり、結局は手動でのJSON-LD追記が必要になる点です。
つまり「プラグイン+デザイナー代行の合算を超える実装が、年間1,650円で完成している」というのが当ブログの現状です。
まとめ:アーキビストとして記録を遺すということ
Web3の世界は「Don't Trust, Verify(信じるな、検証せよ)」が基本原則です。これは、検索エンジンに対するアプローチも全く同じです。
どれだけ価値ある一次情報を持っていても、それを検索エンジンが正確に評価できる形で申告できなければ、情報は届きません。構造化データは「発信者が誰であるか」を機械語で証明する唯一の公式手段です。
「無料CMSだから正当に評価されない」と言い訳をする前に、公開されているルールをコードで忠実に実装し、Google公式ツールで検証する。この実装記録そのものが、当ブログがアナリスト兼アーキビストとして提示できる、何よりのExperience(経験の証明)です。
同じくWeb3領域での情報発信、コミュニティ運営、あるいはニッチなCMSカスタマイズで打開策を模索している方の参考になれば幸いです。
NFA / DYOR
「実装編の背後にある“設計思想”を体系化したアーキテクチャ論文」
実装編が「コード」なら、概念設計編は 「設計思想(アーキテクチャ)」。
なぜWeb3の活動(DIDやオンチェーン実績)はGoogleに届かないのか?
Web2技術へと“翻訳”して検索流入を爆発させる全体像の設計図です。
Person、Organization、WebSiteの三位一体設計がもたらす「静かな土台」。散発的な断片テキストを一つの連続した視点としてLLMや検索エンジンに再構成させるための、思想的背景を解説しています。
SSI / Digital Sovereignty 関連ハブ
Self Sovereign Identity(SSI)とは?Monero・Zcash急騰の裏側でプライバシーコインが示す2026年の未来自己主権型アイデンティティの本質と、2026年規制時代におけるプライバシー技術の意義を解説した中心記事。
Person、Organization、WebSiteの三位一体設計がもたらす「静かな土台」。散発的な断片テキストを一つの連続した視点としてLLMや検索エンジンに再構成させるための、思想的背景を解説しています。
本実装記録に関連する理論・設計記事:
当ブログについて
本記事はSEO・ブログ運営の実装記録です。当ブログ「Blockchain FAQ」は、CoreDAOをテストネット黎明期(2022年)から追い続けた仮想通貨・Web3の一次情報ブログです。仮想通貨の基礎から最前線まで、以下のページを入口にどうぞ。
- インフォグラフィックで学ぶ仮想通貨&Web3入門 — ビジュアルで理解する初心者向けガイドブック
- 「ブロックチェーンは異世界MMOだ」オフチェーンの民へ贈る冒険の書 — ゲーム感覚でブロックチェーンの世界へ
- 【2026年H1版】ブロックチェーン系統別リスト — BTC・ETHから独自系統まで一覧で把握
- ブロックチェーンと暗号資産のLegendたち:系統別総覧 — 主要ブロックチェーンの歴史と系譜
参考リンク
ライブドアブログ 公式・サポート
Schema.org 公式仕様
- schema.org/Article — 公式型定義
- schema.org/BlogPosting — 公式型定義(Articleのサブタイプ)
- schema.org/Person — 公式型定義
- schema.org/ProfilePage — 公式型定義
- schema.org/CollectionPage — 公式型定義
コメント