SiteOps
トップメディアダッシュボード更新履歴
記事一覧

Search Consoleで構造化データのエラーが急増したとき、最初の30分でやること

Search Consoleで構造化データのエラー（リッチリザルト対象の警告/エラー）が急に増えたときに、最初の30分で「対象URLの切り出し/URL検査/テストツール再現/直近変更の止血」を進める手順です。

著者: 川原更新: 2026-05-15検索改善RSS
Xで共有FacebookLinkedIn
料金相談

Search Consoleで 構造化データのエラー（リッチリザルト対象の警告/エラー）が急に増えたとき、最初の30分でやるべきことは「原因を当てる」より、(1) 対象URLが本当に壊れているのか、(2) 直近変更（テンプレ/配信/プラグイン）が壊したのか、(3) 計測や表示だけの揺れなのか を短時間で分けて、止血することです。

この記事は、最初の30分で「止血できる事故」を先に潰して、次の1時間で触る場所（テンプレ/生成/配信/インデックス）を固定するチェックリストです。

関連:

  • /media/search-console-indexing-drop-first-30-minutes
  • /media/search-console-duplicate-google-chose-different-canonical-first-30-minutes
  • /media/search-console-soft-404-first-30-minutes

0. まず結論（先にやる順番）

  1. エラー対象を「代表3URL」に絞る（全件は追わない）
  2. URL検査で「Googleが見たHTML」と「インデックス可否」を確定する
  3. 代表URLをテストツールで再現（Rich Results Test / Schema Markup Validator）
  4. 直近変更の差分で“壊した箇所”を当て、最小差分で止血する

1. まず確認: “増えた”のは本当か（3分）

Search Consoleの構造化データレポートは、集計タイミングや評価の揺れがあります。まず「止血が必要な事故」かどうかを判断します。

  • 直近のデプロイ/テンプレ変更/プラグイン更新があるか
  • 新規ページが急増していないか（生成/インポートで件数が増えただけの可能性）
  • “同じURL群”で突然増えたのか、“新しいURL群”が増えたのか

判断の目安:

  • 同じURL群で突然増えた → 実装・配信の事故を疑う（最優先）
  • 新しいURL群で増えた → 生成ロジックの不足/要件漏れを疑う

2. 代表URLを3つだけ選ぶ（2分）

次の3つを選びます。

  • 代表A: もっとも件数が多いエラーの典型URL
  • 代表B: 同じテンプレの“正常”URL（比較用）
  • 代表C: 収益に近い重要URL（守る対象）

ここで 代表URLが取れない（URLが特定できない）場合は、まず対象レポートの「例」や「影響を受けたページ」を出せる範囲で抜き出してから進めます。

3. URL検査で“Googleが見た状態”を確定（10分）

各代表URLでURL検査を開き、次を確認します。

  • クロールできているか（5xx/タイムアウトがないか）
  • インデックス可否（noindex / robots / canonical）
  • 取得したHTMLが“期待通り”か（本文が空、エラー画面、ログイン誘導になっていないか）
  • canonicalが意図通りか（別URLを正にしていないか）

構造化データ以前に、HTML自体が壊れていると「構造化データも壊れます」。まず ページが正しく返っているか を先に確定します。

4. ツールで再現して“本当に壊れているか”を確定（8分）

代表Aと代表Bを次のどちらか（または両方）で確認します。

  • Rich Results Test（リッチリザルト テスト）
  • Schema Markup Validator（スキーマ マークアップ検証）

見るポイント:

  • JSON-LDがHTMLに出ているか（SSR/静的生成の事故で消えていないか）
  • JSONとして壊れていないか（末尾カンマ、引用符、エスケープ、括弧）
  • 必須プロパティが欠けていないか（タイトル/画像/日付など）
  • 直近変更で @type や @context が変わっていないか

5. “直近変更で壊した”パターン（7分）

増え方が急なら、まず実装・運用変更が原因の事故を疑います。

典型:

  • JSON-LDを生成している関数の条件分岐が変わり、一部ページで空になる
  • テンプレの共通ヘッダー差し替えでJSON-LDの挿入場所が消える
  • 画像URLが相対パスになり、要件を満たさなくなる
  • publishedAt/modifiedAt が未設定/未来日/空文字になる

止血の最小差分:

  • 代表C（重要URL）から先に、必須フィールドを“必ず出す”ように戻す
  • 条件分岐は「出せないなら出さない」より「安全な最小値を出す」に寄せる
  • まずは エラー0件化 より 重要URLの復旧 を優先する

6. 収束後にやること（恒久対応の入口）

  • 生成ロジックを「必須/任意」に分け、欠けやすいフィールドを監視する
  • テンプレ更新に対して、構造化データのスモークテストを追加する（代表URLだけでOK）
  • 新規ページ生成時に、構造化データの要件チェックを組み込む（CIまたはバッチ）

参考にした一次情報

  • Google Search Central: 構造化データ（概念とガイド）
  • Google Search Central: リッチリザルト テスト
  • Schema.org: Schema Markup Validator
  • Search Console Help: URL Inspection tool

相談したい場合は お問い合わせ から状況を送ってください（最短で見る順番を一緒に整理できます）。

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

Search Consoleでクロール異常（Crawl anomaly）が増えたとき、最初の30分でやること検索改善更新: 2026-05-18Search ConsoleでAlternate page with proper canonical tagが増えたとき、最初の30分でやること検索改善更新: 2026-05-17Search Consoleで“Excluded by 'noindex' tag”が増えたとき、最初の30分でやること検索改善更新: 2026-05-16
前の記事Search ConsoleでSoft 404が増えたとき、最初の30分でやること次の記事Search Consoleに「セキュリティの問題」が出たとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ