リッチリザルトテストは、Google検索が対応する構造化データをURLやコードで検査し、検出された項目とエラーを確かめる道具です。結果が有効でも、検索結果での表示が約束されるわけではありません。
公開前はコードを、公開後はURLを検査してください。エラーが出たら、項目を開いて該当箇所を特定し、CMSやテンプレートの出力元を直します。最後に、実際の画面に書かれた内容と一致するかを確認します。
会社情報や記事、パンくずのどの種類を使うかは構造化データの役割で扱っています。このページは、すでに入れたデータの検査と、修正後の確認に絞ります。
Googleとschema.orgのテストは、どう使い分ける？
同じページを調べても、対象の範囲が違います。一方の結果だけで、もう一方も確認済みとは扱わないでください。
| 道具 |
主に調べる対象 |
結果だけで決まらないこと |
| リッチリザルトテスト |
Googleの対応する表示形式 |
実際の検索表示 |
| スキーマ検証ツール |
schema.orgの構造化データ |
Google固有の表示要件 |
Googleのテストの公式ヘルプは、検出したリッチリザルトの種類と問題を表示すると説明しています。Googleが対象にしていない型まで、すべての書き方を調べる道具ではありません。
schema.orgの公式説明は、検証ツールの対象を次のように示しています。
Schema.org-based structured data embedded in web pages
ページに埋め込まれたschema.orgの構造化データを検証するものです。スキーマ マークアップ検証ツールで認識されても、それをGoogleがリッチリザルトとして表示するかは別です。
製造業の設備紹介に使う情報がschema.orgで検出されたとしても、設備紹介専用の検索表示が付くとは限りません。Googleの対応する種類と、そのページが満たす条件を確認します。テストの表示を増やすために、ページと無関係な型を足すことはしません。
公開前のコードは、どうテストする？
リッチリザルトテストを開き、URLの代わりにコードを選びます。テストしたいHTMLやコードを貼り付けて実行してください。公式ヘルプでは、JSON-LD、RDFa、microdataが対象です。
- 実際に出力するコードを貼る
- 使用するユーザーエージェントを確認する
- テストを実行する
- 検出した種類と、各項目の詳細を開く
- 問題を直し、同じコードを再テストする
コード欄で直しただけでは、自社サイトのファイルは変わりません。確認できた修正をCMSやテンプレートへ戻し、公開後にURLでも検査します。検証画面にだけ正しい版が残る状態を避けてください。
例として、製品一覧から技術記事へ移るパンくずを考えます。JSONの構文が正しくても、画面の階層と違う順番なら内容の確認が必要です。構造そのものの作り方はパンくずと階層の設計で整理します。
公開したURLで、何を確認する？
URLの欄にページの完全なURLを入力して実行します。調べたいのがトップなのか製品詳細なのかを確認し、各種類の代表ページを検査してください。トップだけの成功で、全ページの出力を確認したことにはなりません。
取得に失敗したときは、先にURLとアクセス条件を調べます。認証が必要なページや、ファイアウォールで検査ツールを拒否するページでは、コードの内容以前に取得で止まります。
取得できたら、検出された型と項目を開きます。元のファイルだけでなく、テストが取得・処理したHTMLを確認してください。CMSのプラグインやJavaScriptが追加したデータは、手元で見た原稿と違うことがあります。
古い出力と新しい出力が両方あるなら、どちらを残すかを決めて出力元を統合します。手書きのJSON-LDを足して、プラグインの古い会社情報を残したままにすると、テストで読めても情報が食い違います。
エラーと警告は、どう読む？
Search Consoleのリッチリザルトの説明では、重大な問題がある項目は無効になります。重大ではない問題は、表示を改善できる点として区別されています。
エラーがある項目
問題名を開き、どの型の、どの項目が無効かを確認します。必須のプロパティ不足なのか、値の形式なのか、JSON自体を解析できないのかで修正箇所が変わります。
括弧や引用符の不備なら、出力の書式を直します。情報の不足なら、その種類のGoogle公式仕様を読み、本文にも存在する事実かを確かめます。エラーの単語だけを検索して、別の種類の修正例を貼り付けないようにします。
一つの項目のエラーを、ページ全体が検索から消えた意味には読み替えません。検索登録の状態は別に確認します。意図しない除外があればnoindexと除外表示の確認へ進めます。
警告がある項目
有効でも、追加できる情報などが指摘されることがあります。警告の名前と説明を読み、正確な情報を出せるかを確認してください。警告を消すために架空の価格や評価を入れてはいけません。
修正するかを決めたら、理由を残します。自社のページに当てはまらない情報なのか、担当部署へ確認中なのかを分ければ、後の担当者が再び空欄を推測で埋めずに済みます。
テストを通過しても、見落とすことはある？
Googleの構造化データのガイドラインは、正しいマークアップでも表示を保証しないと説明しています。テストで検出できない誤りや、利用者に見えない内容も問題です。
ここで人が照合するのは、会社名、記事の日付、パンくず、製品の条件などです。検査が通ったことと、その会社が実際に対応する仕事かどうかを確かめたことは別です。営業や技術の担当者へ、判断が必要な記述を渡します。
公式ヘルプには、道具だけを信じると見落とす仕様もあります。リッチリザルトテストはJSON-LD内のコメントを無視しますが、JSON-LDの標準ではサポートされないため、公開前に削除するよう案内しています。検証ツールが受け付けた記述を、すべて標準仕様として残せるわけではありません。
検査結果と本文は、別々に照合する
画面にない説明をデータだけへ足しても、読者の疑問は解消しません。検査のエラーを直した後、本文を開き、同じ事実が読めるかを確認します。
Search Consoleの拡張レポートでは、何を見る？
公開後は、Search Consoleの拡張機能にある種類ごとのレポートを確認します。商品関係はショッピングに表示されるものもあります。レポートの公式ヘルプで、現在の対象を確認してください。
レポートはすべての項目を網羅する一覧ではありません。数値もページ数ではなく項目数です。一つのページに複数の項目があれば、ページの数と一致しないことがあります。
レポートが無いときは、Googleが対応する種類か、検出されたかを調べます。すべてのschema.orgの型に専用レポートがあるわけではありません。対象URLをURL検査で確認し、公開直後のテスト結果とGoogleが取得した情報を分けます。
重大な構文の問題は、解析できない構造化データのレポートに出ることがあります。型の必須項目を調べる前に、データ自体を読み取れるかを確認する場面です。
修正した後は、どう反映を追う？
問題のURLだけでなく、同じテンプレートを使うページも確認します。パンくずの出力元を直したなら、階層の異なる製品と技術記事を開きます。共通修正で別の並びを壊していないかを見るためです。
公開URLを再テストし、画面と出力が一致したら、Search Consoleの該当する問題から修正の検証を進めます。検証の開始ボタンを押す操作そのものは、コードを修正しません。公開側を直してから進めてください。
制作担当との記録には、問題のURL、型、エラー名、修正した出力元、公開日、再テスト結果を残します。警告を残した項目は、その理由も添えます。「構造化データを対応済み」という一言だけでは、後から何を確かめたかを追えません。
構造化データ以外にも取得や本文の問題があれば、内部対策と外部対策の作業整理で担当を分けます。サイト設計の点検として、読める本文、正しい案内、それに一致するデータを一緒に確認してください。
仕様・出典の確認日：2026年10月22日。