SchemaがGoogleの検証ツールに合格しても、AIエンジンが構造化データを取得できるとは限りません。両者では解析経路が異なるからです。Rich Results Testが確認するのは、Googleが対応する一部のリッチリザルトの要件を満たしているかどうかです。一方、Schema.org Validatorは、構文がschema.orgの語彙仕様に準拠しているかを検証します。どちらも、ChatGPT、Perplexity、Google AI Overviewsのクローラーがページ上で実際に何を読み取るかまでは教えてくれません。検証結果がすべて正常でも、AI回答にはまったく現れないページがあります。ここに見落とされやすいギャップがあります。
「検証に合格」と「AIが読み取れる」は、なぜ同じではないのか
検証ツールの役割は「仕様への適合確認」であり、「読み取り可能性の確認」ではありません。Schema.org ValidatorはJSON-LDをschema.orgの語彙と照合し、型やプロパティのスペル、入れ子構造の妥当性を確認します。Rich Results TestはGooglebotによるページのレンダリングを再現し、特定のリッチリザルトを表示できるか判定します。この2つで分かるのは、「構文が正しいか」と「Googleのリッチリザルト要件を満たすか」までです。多くのAIクローラーは、サーバーが返した元のHTMLを直接取得し、JavaScriptを実行しません。また、リッチリザルトの対象かどうかも重視しません。AIが読み取れるかを実質的に左右するのは、JSON-LDが元のHTMLに含まれているか、そして各エンティティが正しく結び付いているかです。
欠かせない2つのツールと、それぞれの盲点
まず両ツールの役割を明確にすると、それぞれが何を見落とすのかが分かります。
- Rich Results Test（search.google.com/test/rich-results）：Googlebotを使って実際にページをレンダリングし、JSを実行したうえで、検出したリッチリザルトの種類、エラー、警告を項目ごとに表示します。盲点は、対象がGoogleの対応する約30種類に限られることです。リッチリザルトを発生させないOrganizationやPersonなどをマークアップすると「アイテムが検出されませんでした」と表示されますが、Schemaが無効という意味ではありません。
- Schema.org Validator（validator.schema.org）：Googleの対応状況にかかわらず、すべての型を含む完全なエンティティツリーを表示するため、構文と語彙の確認に適しています。盲点は、標準ではJSを実行しないことです。ソースコードを貼り付けたりURLを指定したりしても、未レンダリングの内容が取得される場合があります。また、リッチリザルトの要件は判定せず、一部の意味上の誤りにも寛容すぎる面があります。
結論は明快です。両方を使い、各工程で何を確認しているのかを区別してください。Schema.org Validatorでは構文とエンティティ構造を、Rich Results TestではGoogleのリッチリザルト要件とレンダリング結果を確認します。ただし、どちらも「JSを実行しないクローラーから見えるか」には答えられません。それを確かめるには、次の工程でソースコードを調査する必要があります。
繰り返し使えるSchema検証フロー
検証を固定の手順に分け、すべてのページと改修で同じチェックリストを実行します。毎回の感覚的な確認を避けることで、改修のたびに異なる見落としが生じるのを防げます。
- Schema.org Validatorに「レンダリング後」のHTMLを貼り付け、構文と語彙が正しいことを確認します。完全なエンティティツリーを展開し、型と必須プロパティを順に点検してください。
- Rich Results Testに本番URLを入力し、Googleがレンダリング後の内容を取得できること、意図したリッチリザルトの種類が認識されていること、赤いエラーがないことを確認します。
- curlまたはview-sourceを使い、「JSを実行せずに」元のHTMLを取得します。application/ld+jsonを検索し、サーバーから返される内容にJSON-LDが実際に含まれていることを確認してください。この工程は、多くのAIクローラーの挙動を再現するものです。
- @idと@typeの相互参照を確認します。Organization、WebSite、Article、Personが一貫した@idで関連付けられ、著者がどの組織に属し、記事がどのWebサイトに属するのかをエンジンが判定できる状態になっているかを点検してください。
- Schema内の値とページ上の表示内容を項目ごとに照合します。価格、タイトル、評価、日付は一致していなければなりません。不一致があるとGoogleに無視され、AIからの信頼性も低下します。
- 基準となるスナップショットを保存します。その後は改修のたびにリスト全体を再実行し、差分をリグレッションとして確認してください。
AIエンジンが実際には読み取れないエラーの典型例
構文上は合格していても、「ツールでは問題ないのに、AIには読めない」という種類のエラーは数多く残ります。クライアント向けの監査で特によく見つかるのは、次のようなケースです。
- JSON-LDが、フロントエンドフレームワークやタグマネージャーによってブラウザー側で挿入されている。サーバーが返す元のHTMLには記述がまったくなく、JSを実行しないクローラーからは一切見えません。
- @idがない、または表記が統一されていないため、エンティティ同士を関連付けられない。エンジンは著者、組織、記事を同じナレッジグラフ上のノードとして結び付けられません。
- 型の選択は正しくても、値を入れるフィールドが間違っている。priceに通貨を入れる、nameに説明文全体を入れる、offersにpriceCurrencyがない、といったケースです。
- 構文は正しくても、意味上の情報が不足している。Productにoffersがない、Articleにauthorまたはpublisherがない、FAQPageのanswerが空文字になっている、といったケースです。
- 同じページ内に、内容の矛盾する複数のJSON-LDが存在している。たとえば、トップページのテンプレートに含まれるOrganizationと、個別ページ側のOrganizationが競合し、エンジンがどちらを採用すべきか判断できない状態です。
- 日付がISO 8601形式ではない、画像が絶対URLではなく相対パスになっている。寛容なValidatorでは合格しても、抽出時に破棄されやすいデータです。
ツールの結果だけでなく、「レンダリング後のDOM」と「ソースコード」の差を見る
確実な検証の要点は、ページの2つの姿を同時に確認することです。DevToolsのElementsパネルに表示されるのは、ブラウザーがレンダリングしたDOMであり、おおむねGooglebotから見える状態です。一方、view-sourceやcurlで確認できるのは、サーバーが最初に返す元のHTMLで、多くのAIクローラーが目にする状態です。構造化データが前者にしかなく、後者に存在しなければ、その差分がAIに読み取られない領域になります。検証ツールは前者の確認に役立ちますが、後者は自分で確かめなければなりません。
Schema検証は、公開時に一度実施して終わる作業ではありません。改修のたびに再実行すべき工程です。CMSのアップグレードやテンプレートの調整だけでも、エンティティツリー全体が気付かないうちに崩れる可能性があります。— Tenten GEO Technical Audit Notes
検証を公開前の固定工程に組み込む
最も実践的なのは、記憶に頼ってその都度確認するのではなく、このリストを公開フローに組み込むことです。CIにスクリプトを追加し、本番URLの元のHTMLを取得してJSON-LDを抽出し、必須プロパティと@id参照を照合します。不足があればデプロイを停止する仕組みにできます。CIがないチームでも、少なくとも6つの手順を公開前チェックリストに記載し、改修後に各項目を確認してください。構造化データの価値は、機械が安定して抽出できることにあります。その安定性を生むのは、手作業による検証の運ではなく、運用プロセスです。JSを実行しないクローラーから自社ページがどう見えるのか、AIがまったく読み取れないSchemaはどれかを把握したい方は、/contactから30分間のGEO診断をご予約ください。実際のページを対象に、この検証フローを実施します。
