構造化データのテストとデバッグ：Rich Results テストとエラー調査
1. 2つのテストツールの役割分担
Schema をページに書けば終わりだと考えているチームは多く、その結果 GSC が赤だらけになります。構造化データのデバッグには2つのツールを使い、それぞれ役割が異なります。
Rich Results Test は単一ページのテストに使います。URL かコードスニペットを貼り付け、そのページがリッチリザルトを生成できるか確認します。Schema Markup Validator は JSON-LD 自体が正しいか検証します。
| ツール | テスト内容 | 使用タイミング | 限界 |
|---|---|---|---|
| リッチリザルトテスト | 単一ページのリッチリザルト資格 | 公開前に1ページずつテスト | 貼り付けたページのみテスト |
| スキーマバリデータ | JSON-LD の構文の正当性 | コーディング時にローカルで確認 | Google が実際に表示するとは限らない |
| GSC リッチリザルト レポート | サイト全体の検証済みページ | 公開後に毎週確認 | データに2〜3日の遅延 |
Schema の型の選び方やフィールド一覧は構造化データSchemaと構造化データ Schema 完全リストをご覧ください。本記事では書いた後のテスト方法とエラーの直し方を解説します。
3つのツールでレポートの基準が異なるのは正常です。ローカルテストが通っても、GSC に反映されるまで2〜3日かかることがあります。ローカルで通ったからと早合点しないでください。
2. エラーと警告：どちらを先に直すか
デバッグレポートの各項目は優先度別に対応します。警告をエラーと同様に1つずつ直すと、数日を無駄にします。
| レベル | 意味 | リッチリザルトへの影響 | 対応の優先度 |
|---|---|---|---|
| エラー Error | 必須フィールドの欠落または型の誤り | あり、リッチリザルトが失われる | すぐに修正 |
| 警告 Warning | 推奨フィールドの欠落 | なし、表示は可能 | 計画的に補完 |
| 情報 Info | 任意フィールドの提案 | 不要 | 余裕があれば補完 |
直感に反する判断：レポートの80%は警告です。Google は著者や日付などの推奨フィールドの欠落を黄色で示しますが、ページはリッチリザルトの資格を保ちます。
本当にリッチリザルトが消えるのはエラー項目です。たとえば Article 型を使いながら headline がない、日付を ISO 形式ではなく文字列で書いているなどです。この2種類は最優先で修正します。
事例：あるブログサイトで GSC が120ページの問題を報告し、最初は全滅かと思われました。優先度別に分けると、110ページは image 欠落の警告で、datePublished の形式エラーは10ページだけでした。まず10ページのハードエラーを直すと、1週間後にリッチリザルトが80%回復し、警告のページも通常どおり結果が出ました。
CMSテンプレートを使っているチームでは、ある種のエラーが一括で発生します。テンプレート内のフィールドを1つ直せば、次回のクロール後に全ページが自動で復旧し、ページごとに修正する必要はありません。だからこそエラー修正を優先すべきなのです。テンプレート1か所の変更が、手作業で数十ページを直すのと同じ効果を持ちます。
逆に、警告系の問題は通常、個別ページの内容に関係します。著者やメイン画像の欠落はページ単位なので、スケジュールを組んで少しずつ補うしかありません。
3・4番目に多いエラーの調査方法
B2Bサイトで最もよく見られる構造化データのエラーは4種類に集中しています。発生頻度の高い順に以下のとおりです。
| 誤りのタイプ | 典型的な症状 | 調査方法 | 修正 |
|---|---|---|---|
| フィールド型の誤り | 日付が2026/10/08と記載 | ISO 8601か確認 | 2026-10-08に修正 |
| ネスト階層の誤り | ReviewがProductから分離 | @graph構造を確認 | ReviewをProductにネスト |
| 必須フィールドの欠落 | Articleにheadlineがない | 公式フィールド表と照合 | 必須フィールドを追加 |
| 複数URLの重複 | ページネーションの各ページにArticleを付与 | canonicalの参照先を確認 | メイン記事のみに付与 |
日付形式が最も頻度の高いエラーです。GoogleはISO 8601、つまり2026-10-08を要求しており、10/08/2026でもOct 8, 2026でもありません。スラッシュ区切りの書き方ひとつで、全ページがリッチリザルトから外れてしまいます。
もうひとつの見つけにくいエラーはページネーションです。連載記事の2ページ目、3ページ目にもArticleを付与していると、Googleは重複と判定し、canonicalの1記事だけを保持します。残りのページはマークアップを外すか、CollectionPageに変更してください。
リッチリザルトの取得と維持についてはリッチリザルト最適化、エンティティマークアップについてはナレッジグラフのエンティティマークアップ。
4. 公開後に本当に反映されたか確認する方法
ローカルテストの成功は、本番環境での反映を意味しません。構造化データには検証サイクルがあり、正しい方法で待つ必要があります。
| フェーズ | 時間 | 確認できること | アクション |
|---|---|---|---|
| 修正を送信 | 0日目 | GSCで検証をリクエスト | 繰り返し変更しない |
| 再クロール | 1〜7日目 | レポートのステータスは「修正中」のまま | 待つ |
| 評価完了 | 1〜4週目 | エラー数が減少 | SERPでリッチリザルトを確認 |
| 長期的なモニタリング | 毎月 | 新規ページが自動で認識されるか | テクニカル監査に組み込む |
検証をリクエストしたら、コードを何度も変更しないでください。変更するたびにGoogleの評価ウィンドウがリセットされ、本来2週間で完了する検証が6週間まで長引きます。
検証完了後、Googleでターゲットキーワードを検索し、SERPに星評価、FAQの折りたたみ、パンくずリストが実際に表示されるか目視で確認してください。GSCが有効と判定しても、ユーザーに見えるとは限りません。特定のクエリでのみ表示されるタイプもあります。
GSCで有効と表示されているのにSERPでリッチリザルトが見えない場合は、まずそのクエリ自体がリッチリザルトをトリガーするか確認してください。ナビゲーショナル系や情報系のクエリでのみ表示され、トランザクション系のクエリでは表示されないタイプもあります。関連する別のキーワードで再度検索してみてください。
長期的なモニタリングも必要です。新しいページを公開したら、1週間後にGSCで自動認識されているか確認してください。認識されていない場合は、URL検査ツールで手動でリクエストを送信します。
テンプレート型のサイト構築を使っているなら、公開フローにチェック工程を1つ追加することをおすすめします。新しいページを公開する前に Rich Results Test で一度テストし、合格したら公開を許可する運用です。この工程はわずか1分で、公開後のまとめて手戻りする事態を防げます。
リッチリザルトは目的ではなく、ページを SERP 上で目立たせるための手段にすぎません。順位を決めるのはあくまでコンテンツと被リンクであり、構造化データはすでに良好なページのクリック率を10%から20%ほど押し上げるだけです。
ですから順序を間違えないでください。まずコンテンツを上位20位以内に入れるレベルまで作り込み、そのうえで構造化データを追加してリッチリザルトの枠を狙います。コンテンツ自体が上位に入らなければ、マークアップをどれだけ正確にしても表示されることはありません。
技術SEO監査の完全なチェックリストはテクニカル SEO 監査チェックリストをご覧ください。構造化データはそのうちの1項目です。公開前の事前チェックは独立サイト公開チェックリスト。
五、落とし穴の回避：デバッグ段階で最も多い3つの誤った行動
構造化データのデバッグには3つの落とし穴があり、踏むと効果が出ないばかりか手動によるペナルティを受ける恐れもあります。
| 誤った行動 | 結果 | 正しい方法 |
|---|---|---|
| 星評価のためにサクラレビューを投稿する | 構造化データポリシーに違反 | 実際のレビューだけをマークアップする |
| 警告をすべてエラーとして修正する | 数日を無駄にし、順位の利益もなし | まずエラーを修正し、警告は後回しに |
| ローカルで通ったら毎日のように修正する | 検証ウィンドウをリセット | 送信後は1〜4週間待つ |
最も深刻なのはサクラの星評価です。Google は自己申告の評価や虚偽のレビューに対して手動ペナルティを課しており、一度該当するとサイト全体のリッチリザルトが取り消され、回復には数か月かかります。ページ上に実際に表示されているレビューだけをマークアップしてください。
構造化データは AI のクロールにも役立ちます。詳しくはGEO 技術最適化をご覧ください。あの星のためではなく、検索エンジンと AI の両方にページのエンティティを正しく理解してもらうためのものです。
FAQ よくある質問
Rich Results Test に合格したのに、検索結果にリッチリザルトが表示されないのはなぜですか？
GSC のリッチリザルトレポートでエラーと警告はどう違いますか？
構造化データで最もよくある致命的なエラーは何ですか？
構造化データのエラーを直したら、効果が出るまでどれくらいかかりますか？
星の評価を出すために、良いレビューを自分でいくつか書いてもいいですか？
JSON-LD は head と body のどちらに書いても影響はありますか？
最後に
構造化データのデバッグで問われるのは Schema を書く力ではなく、忍耐です。レポートが真っ赤なときはまず優先度を分けましょう。80% は急がなくていい警告です。修正を送信したら1〜4週間待ち、毎日コードを書き換えないこと。
実践は3ステップです。単一ページは Rich Results Test で通す。サイト全体は GSC のリッチリザルトレポートでまずエラー項目だけを直す。直したら「修正を検証」を押し、あとは Google の再評価を待つ。途中でやり直さないこと。
覚えておきたい一言。構造化データはテストに通っただけでは入場券にすぎません。GSC で検証を押し、4週間待ち、検索結果でリッチリザルトを実際に確認する。この3ステップを終えて初めて本当に効果が出たと言えます。