※本記事のコードは参考情報です。Schema.org仕様やGoogleガイドラインは随時変更されます。実装は自己責任で。

なぜWeb3ブロガーが構造化データを深掘りするのか
—その答えは単純です。
仮想通貨・DeFi・ブロックチェーンの情報はGoogleが最も厳しく審査するYMYLカテゴリに分類されており、発信者の信頼性を証明できなければ情報は届かないからです。どれだけ正確なCoreDAO ecosystemの一次情報を持っていても、構造化データという「機械語の自己申告」が整っていなければ、検索エンジンはその情報の価値を正しく評価できません。

本記事は前回の実装記録の概念補足編です。「なぜこの設計か」を理解すると、コードの意図が見えてきます。同じくWeb3・仮想通貨領域で情報発信をしている方にとっては、自分のサイト設計を見直すチェックリストとしても機能します。

1. 全体アーキテクチャ概要（Entity Relationship）

まずこの関係図全体が示しているのは、「Googleの知識グラフ（Knowledge Graph）に対して、どのような実体（エンティティ）の連鎖を申告するか」という設計図です。

                  +-------------------+
                  |     WebSite       |
                  | blockchain-faq.xyz|
                  +---------+---------+
                            |
                +-----------+-----------+
                |                       |
     +----------v----------+   +--------v--------+
     |   Organization      |   |     Person      |
     |   Blockchain FAQ    |   | nukolcore.core  |
     +----------+----------+   +--------+--------+
                |                       |
                +-----------+-----------+
                            |
                 +----------v----------+
                 |   Individual Pages  |
                 +----------+----------+
                            |
          +-----------------+-----------------+
          |                 |                 |
   ProfilePage           Article         CollectionPage
   (About)           (個別記事)       (カテゴリ/アーカイブ)

ブロックチェーンのトランザクションに署名者のアドレスが紐付くように、ここでもすべてのノードは固有の@id（識別子URL）を持ち、プロパティを通じて互いに参照し合います。WebSiteがOrganizationを参照し、OrganizationがPersonを参照し、各記事ページがその連鎖の末端に繋がる。
—この有向グラフ構造が、Googleの知識グラフに「同一著者・同一組織・同一サイト」として一貫して刻まれる仕組みです。

重要なのは、どのページから入ってきてもクローラーが同じ結論に辿り着けることです。トップページを経由しようと、個別記事を直接クロールされようと、カテゴリアーカイブを巡回されようと、3つのアンカーノード（WebSite / Organization / Person）への参照が常に含まれているため、評価が分散しません。この設計思想はWordPressのYoast SEOプラグインが自動生成する@graphと同一ですが、当ブログでは実装の自由度を最大限に活かして独自拡張しています。

2. ページタイプ別JSON-LD構造（修正後）

Schema.orgには100種類以上の@typeが存在しますが、ブログ運営で使うのは実質5〜6種類に絞られます。重要なのはページの「役割」と@typeを厳密に対応させることです。たとえばAboutページにWebPageを使っても動きますが、ProfilePageを使うことで「このページは著者情報を提示するためのページである」という意図がGoogleに直接伝わります。型の選択は意味論（セマンティクス）の問題であり、間違えると構造化データの警告ではなく、評価精度の低下として静かに損失が積み上がります。

特にProfilePageのmainEntityプロパティは誤用が多いポイントです。authorプロパティとmainEntityを両方設定すると「このPersonは著者でもあり主体でもある」という二重申告になり、GSC側で「項目authorを認識できません」という警告として検出されます。前回の記事(実装編)でまさにこのパターンを踏みました。ProfilePageにはmainEntityのみ ―これが正解です。

3. 知識グラフの視覚化

この図が示しているのは、各エンティティが孤立したJSONオブジェクトではなく、有向グラフ（Directed Graph）として連結されている状態です。ブロックチェーンのトランザクションDAG（有向非巡回グラフ）と構造的に似ています。―各ノードが他のノードを一方向に参照し、全体として一貫した意味のネットワークを形成します。

sameAsプロパティによる外部URL列挙（X、Telegram、Bitget Wiki等）は、いわばエンティティのオンチェーン実在証明に相当します。Googleはこれらの外部URLを辿り、「このPersonノードに記述されたエンティティは、実際にこれらのプラットフォーム上で活動している実在の人物である」という照合を行います。単独URLより複数の外部参照が存在するほど、エンティティとしての一意性スコアが上昇します。hasCredentialでBitget Wiki推奨ブロガーを申告しているのも、第三者機関による承認記録をグラフに組み込むためです。また、CoreDAO JPコミュニティ運営統括という実績がsameAsとhasCredentialとして申告されているのも同様です。
―これがE-E-A-TのAuthority（権威性）層に直接作用します。

4. JavaScript動的更新の仕組み

ページ読み込み (DOMContentLoaded)
          ↓
1. HTMLコメントから last-modified 日付取得
          ↓
2. meta[property="article:published_time"] から公開日取得
          ↓
3. ページ内の全JSON-LD scriptを走査
          ↓
4. BlogPosting / Article を検出
          ↓
5. datePublished / dateModified を正規化（+09:00補完）
          ↓
6. JSONを更新して script.textContent に書き戻し

このフローが解決しているのは、「CMSの構造的制約」と「Googleが要求する品質シグナル」の間のギャップです。

ライブドアブログCMSにはWordPressのget_the_modified_date()に相当するテンプレートタグが存在しません。しかしGoogleは特にYMYLカテゴリにおいてdateModifiedを情報鮮度の評価シグナルとして重視します。この実装はDOMのコメントノードという副作用のないチャンネルを使って更新日を「ページに埋め込む」ことで、CMSが出力できない情報をクライアントサイドで補完します。

技術的に重要な点が2つあります。第一にTreeWalkerによるコメントノードの安全な走査。document.body.innerHTMLを正規表現でスキャンする方法は、GTMやサードパーティスクリプトが埋め込んだHTMLコメントを誤検知するリスクがあります。NodeFilter.SHOW_COMMENTでコメントノードのみに絞ることで、この衝突を構造的に排除しています。第二にISO8601タイムゾーン補完の自動化。GSCが「日時値が無効です」として警告するのは、日付のみ（YYYY-MM-DD）の記述に対してです。Schema.org仕様上は許容値ですが、Googleの実装はYYYY-MM-DDTHH:MM:SS+09:00の完全形式を要求します。スクリプト側で自動補完することで、記事の更新作業時に意識するコストをゼロにしています。

主な処理フロー:

• 手動更新日 > 公開日の場合 → dateModifiedに手動日（23:59:59+09:00）を設定
• 同日の場合 → datePublishedをそのままdateModifiedにコピー
• ISO形式の正規化でGSC警告を防止

なお、GooglebotはChromiumベースのレンダリングエンジンを持ち、JavaScriptを実行してからページを評価します。このスクリプトはDOMContentLoadedで起動するため、Googlebotのレンダリング完了時点では正しくJSON-LDが書き換わった状態になります。前回の記事(実装編)掲載のリッチリザルトテストのスクリーンショットがその実証です。

まとめ

ライブドアブログCMSという「制約」を逆手に取り、構造化データの設計を深化させてきた記録を、概念レベルで整理します。

① @graphによるエンティティ連鎖設計——「一貫性」の担保
Person・Organization・WebSiteの3ノードを固有@idで宣言し、全ページから参照する設計により、どのURLからクロールされても「同一著者・同一組織のサイト」としてGoogleの知識グラフに登録されます。ページ単位でバラバラに記述する旧来の方式と比べて、エンティティの実在確度と評価の一貫性が格段に向上します。WordPressのYoast Premiumが自動生成するグラフと同等以上の構造が、手実装で実現できています。

② ページ役割と@typeの厳密な対応——「意味精度」の追求
AboutページへのProfilePage適用、個別記事へのArticle/BlogPosting適用、リストページへのCollectionPage適用と、ページの「機能的役割」にSchema.orgの型を正確に対応させることで、検索エンジンへの申告精度が高まります。型の選択ミスは即時エラーとして検出されにくい分、静かに評価精度を損ない続けます。GSC通知で実際に踏んだ落とし穴の修正記録は前回の記事(実装編)を参照してください。

③ JavaScriptによるCMS制約の構造的補完——「鮮度シグナル」の自動化
HTMLコメントを更新日の記録チャンネルとして活用し、TreeWalkerで安全に抽出してJSON-LDに動的注入する仕組みは、CMSのテンプレートタグでは出力できないdateModifiedをYMYLカテゴリの品質要件レベルで自動管理します。記事更新のたびに日付を書き換えるだけで、ISO8601完全形式への変換・タイムゾーン補完・JSON-LD書き戻しまで自動化されます。

構造化データは「正直な自己申告」の仕組みです。誰がどこで何を書いているかを、機械語で正確に証明する。それがYMYL領域でWeb3の一次情報を発信し続けるための、技術面の最低ラインだと考えています。
NFA / DYOR

参考リンク

Schema.org 公式仕様

• schema.org/WebSite — サイト全体の定義・SearchAction
• schema.org/Organization — 運営主体・ロゴ・Founder参照
• schema.org/Person — sameAs・hasCredential・knowsAbout
• schema.org/ProfilePage — mainEntityによるPerson参照
• schema.org/Article — 記事全般
• schema.org/BlogPosting — Articleのサブタイプ（ブログ記事特化）
• schema.org/CollectionPage — カテゴリ・アーカイブ等リストページ
• schema.org/BreadcrumbList — パンくずリスト
• schema.org/EducationalOccupationalCredential — hasCredentialの値型

Google 公式ドキュメント・ツール（E-E-A-T関連）

• 構造化データの概要 — Google for Developers
• 記事（Article）の構造化データ — Google for Developers
• プロフィールページの構造化データ — Google for Developers
• E-E-A-T とコンテンツ品質 — Google 検索の基礎
• robots.txt の概要 — Google for Developers
• リッチリザルトテスト — Google Search Console
• Google Search Console
• 構造化データに関するポリシー — Google for Developers

ライブドアブログ 公式・サポート

• デザインをカスタマイズする — livedoorお客様サポートセンター
• デザインをカスタマイズする — ライブドアブログヘルプ（PC向け）
• はじめてガイド — ライブドアブログ公式