Rich Results Test と Google Search Console：構造化データの異常をどのように調査するか？

Rich Results Test と Google Search Console：構造化データの異常をどう調査するか？

商品ページ、記事ページ、またはサービスページの構造化データに異常が発生すると、多くのチームは直接 Schema コードを修正し、「修正を検証」を繰り返しクリックします。問題は、構造化データのエラーが必ずしもマークアップ構文そのものに起因するとは限らないことです。ページレンダリング、テンプレート継承、クロールされたバージョン、インデックスの状態、さらにはコンテンツとマークアップの不一致が原因である可能性もあります。問題を正確に特定するには、rich results test - google search console は二者択一のツールではなく、2つの観測メカニズムです。前者は「Google が現時点で何を解析しているか」を確認し、後者は「Google がサイトレベルですでに何を検出しているか」を確認します。

技術評価担当者にとって最も重要なのは、すべての通知をゼロにすることではなく、まず3つの問いに答えることです。異常はリッチリザルトの対象資格に影響するのか。Google が取得したのは現在のページバージョンか。このマークアップは本当にそのページと業務コンテンツに適しているのか。順序を誤ると、その後の修正は無効な手戻りになりがちです。

まず区別する：テスト結果、Search Console のレポート、検索での表示は同じではない

Rich Results Test は、単一の URL またはコードの一部を確認するのに適しています。ページ内の条件を満たす構造化データを抽出し、問題をエラー、警告、認識可能な項目に分類します。公開前の検収、テンプレート改修後の抜き取り検査、JSON-LD が JavaScript によって正しく出力されているかの判断に特に適しています。

一方、Google Search Console のリッチリザルト レポートはサイトレベルのシグナルであり、Google が処理済みの複数 URL を反映します。レポートには遅延があり、削除済みページや旧テンプレートの過去の問題が残ることもあります。そのため、Search Console で引き続きエラーが報告されていても、現在公開中のコードが依然として誤っているとは限りません。逆に、Rich Results Test で合格と表示されても、Search Console が再クロール済みであることを意味せず、検索結果にリッチリザルト形式で必ず表示されることも意味しません。

実際の調査では、次のように理解できます。Rich Results Test は即時の「ページ健診」、Search Console は時間軸を持つ「サイトの診療記録」です。両者の結論が矛盾する場合は、まず URL 検査ツールでクロール日時、インデックス状態、Google が取得したページを確認し、その後に再インデックス登録をリクエストする必要があるかを判断します。

コードを一つずつ修正するより、異常の種類から原因を逆算する方が有効

構造化データの問題は、通常4種類に分けられます。第1は解析失敗です。たとえば JSON の引用符不足、カンマの位置ミス、スクリプトのテンプレートエスケープ、あるいは同じコードの二重連結などです。この種の問題はテストツールで直接「解析不能」と表示されることが多いため、CMS エディタ内の設定だけでなく、ページソースと最終的にレンダリングされた DOM を優先して確認してください。

第2は必須プロパティの欠落です。たとえば商品マークアップに価格がない、レビュー マークアップに必須フィールドがない、または記事ページに認識可能なメイン画像情報がない場合です。ここで起こりやすい誤りは、通知を消すためにすべてのページへ固定値を入力することです。Google はページ上の表示コンテンツとマークアップの整合性をより重視します。価格のない B2B 問い合わせページでは、Product リッチリザルトを適用するために offer を捏造すべきではありません。実際の評価ソースがないページにも、aggregateRating を記載すべきではありません。

第3はタイプの不適切な使用です。製造業の企業では、すべての詳細ページを Product とマークアップしがちですが、一部のページは本質的にはソリューション紹介、設備能力の説明、または業界用途ページであり、取引可能な商品ページに必要な情報を備えていない場合があります。同様に、FAQPage は、Q&A コンテンツが実際に表示され、ユーザーが閲覧でき、重複した内容の羅列でない場合にのみ使用する価値があります。マークアップの目的はページを説明することであり、ページに「検索演出のスイッチ」を追加することではありません。

第4は最も見つけにくいものです。コードは正しいものの、Google が取得したバージョンが、あなたが見ているバージョンではないケースです。フロントエンドの非同期レンダリング、多言語切り替え、地域リダイレクト、Cookie ポップアップによる表示の遮蔽、CDN キャッシュの未更新、またはサーバーが User-Agent に応じて異なるコンテンツを返す場合によく発生します。このとき、Rich Results Test の「クロールされたページ」とブラウザでローカル表示した結果が異なることがあります。特に SPA アーキテクチャを使用するサイトでは、構造化データがクライアント側 API の応答に依存している場合、API の遅延、スクリプトエラー、レンダリングのタイムアウトにより、Google が空のページしか取得できないことがあります。

より確実な調査手順

Search Console のレポートを見た直後に一括修正するのではなく、まず影響を受けた URL を1件選び、次の順序で処理することを推奨します。

• URL が正常な 200 ステータスを返し、robots.txt、noindex、ログイン制限、または地域ポリシーによってブロックされていないことを確認する。
• ローカルにコピーしたコードだけをテストするのではなく、Rich Results Test で公開中の URL をテストし、認識されたタイプ、フィールド、具体的なエラーを記録する。
• ページソースとブラウザの開発者ツールを開き、JSON-LD が初期 HTML に存在するのか、それとも後続スクリプトによる挿入に依存しているのかを確認する。
• Search Console の URL 検査で、最終クロール日時、正規ページ、インデックス登録の許可、およびページのクロール状況を確認する。
• ページ上の表示コンテンツに戻り、名称、画像、価格、在庫、公開日、著者などのフィールドが実在し、一貫しているかを項目ごとに照合する。
• 修正後は、まず代表的な URL を再テストし、その後 Search Console で該当の問題について検証を開始する。単一ページの結果をサイト全体の復旧と誤判定しないようにする。

ここには実務上の注意点があります。テンプレート由来の問題では、異なる言語、異なる端末、異なるコンテンツ状態のページを抜き取り確認する必要があります。英語の商品ページが合格しても、ドイツ語ページ、画像のないページ、販売終了ページまで問題がないとは限りません。多言語の独立サイトでは、翻訳フィールドが空であることや hreflang のリダイレクトロジックがレンダリングに影響することで、特定言語だけが継続的にエラーとなることがよくあります。canonical が別言語バージョンを指している場合、構造化データ レポートの帰属も想定と異なる可能性があります。

警告を修正すべきかどうかは、ページの商業的用途によって決まる

すべての警告を直ちに開発スケジュールに入れる必要はありません。レビュー機能のない B2B 工業サイトでは、評価関連の推奨フィールド不足を架空のデータで補うべきではありません。一方、オーガニックトラフィックを長期的に運用する越境 EC モールでは、価格、送料、在庫などの動的フィールドを公開プロセスに組み込むべきです。これらは商品状態の変化に伴い、不正確になりやすいためです。優先順位は、URL がすでにインデックスされているか、そのページが主要なトラフィックまたはコンバージョンの役割を担っているか、フィールドを実際の業務システムから安定的に提供できるか、という3つの観点で判断できます。

これは、Webサイト構築とマーケティングサービスの連携が必要となる点でもあります。構造化データは純粋なフロントエンド業務ではありません。商品情報を誰が管理するのか、広告ランディングページが頻繁に差し替えられるのか、翻訳コンテンツが同期されているのか、コンテンツチームが規定フィールドを入力できるのかといった点が、マークアップを長期的に利用できるかを左右します。易营宝では、貿易企業、多言語公式サイト、越境 EC モール向けのサイト構築実践において、Search Console で大規模な異常が発生してからページごとに対処するのではなく、Schema フィールドをテンプレートとコンテンツ公開ルールに組み込む方が適しています。

同じ考え方は、その他のビッグデータ業務にも当てはまります。データフィールドに統一された基準がなければ、バックエンドのレポートもフロントエンドの表示も不正確になります。この種のガバナンス関係を理解する際は、ビッグデータ駆動の視点に基づく道路維持管理企業の財務分析最適化に関する研究で展開されているデータ分析と管理最適化に関する議論を参考にできます。Webサイトプロジェクトに置き換えると、まずデータソースと責任者を明確にし、その後にどのフィールドを構造化マークアップへ含めるかを決定することです。

「有効」を「必ずリッチリザルト表示を得られる」と誤解しない

rich results test - google search console の検査に合格しても、そのページが認識・検討されるための基本条件を満たしていることしか示しません。検索結果での最終的な表示は、クエリ、デバイス、ページ品質、コンテンツの関連性、その他のシステムシグナルに基づいて Google が決定します。技術チームは、構造化データをページ情報を正確に伝達するためのプロトコルと捉えるべきであり、順位やクリック率を保証するものとして扱うべきではありません。

本当に構築すべきなのは、追跡可能な一連のプロセスです。テンプレート公開前にテストし、改修後はページタイプごとに抜き取り検査を行い、Search Console で定期的に傾向を観察し、異常発生時にはクロール日時とページバージョンの記録を残します。そうすれば、次に赤いエラーが発生した際、チームは「とりあえずコードを修正してみる」ことから始めるのではなく、それがマークアップの問題なのか、クロールの問題なのか、あるいはインデックスがまだ更新されていない問題なのかを迅速に判断できます。