本記事が扱うのは、すでに構造化データを実装しているサイトの監査です。どのページに何のschemaを新規実装するか、JSON-LDをどう設計・実装するかは主題にしません。
実装方針やページ種別ごとのマークアップ選定を確認したい場合は、AIOの構造化データ実装ガイド｜何をマークアップし、どこを監査するかを参照してください。
実装後の監査では、リッチリザルト テストでエラーが出ないことだけを確認しても不十分です。サイト横断で実装済みURLを母集団化し、構文、Google固有要件、本文との一致、重複出力、本番での認識、更新後の欠落まで分けて確認します。
監査の流れは、母集団作成→機械検証→目視照合→テンプレート・重複診断→本番認識確認→優先順位付け→修正後再検証です。
構造化データ監査で最初に確認すべき結論
実装後監査では、次の6層を分けて確認します。
- 実装済みURL・テンプレートを監査母集団として把握できているか
- JSON-LDなどのコードを機械的に解析できるか
- Googleが求める必須要件を満たしているか
- 構造化データと可視本文が一致しているか
- テーマ・プラグイン・独自実装が重複出力していないか
- Googleが本番ページから継続的に検出できているか
構文エラーがなくても、本文にない評価値を出していたり、同じOrganizationを複数の出力元が異なる値で生成していたりすれば、監査上は問題です。
また、Search Consoleのリッチリザルトレポートだけを監査母集団にしてはいけません。Googleは、このレポートが検出項目の完全な一覧ではなく、品質評価のためのサンプルであると案内しています。
| 監査層 | 確認すること | 主な確認手段 |
|---|---|---|
| 母集団 | 実装済みURL・テンプレートを把握できているか | サイトマップ、CMS一覧、クロール |
| 構文 | JSON-LD等を解析できるか | Schema Markup Validator |
| Google適格性 | 対応する検索機能の要件を満たすか | リッチリザルト テスト |
| 内容整合 | 可視本文と値が一致するか | 目視照合 |
| 重複・競合 | 同一対象を複数出力していないか | HTML・レンダリング結果・出力元確認 |
| 本番認識・継続性 | Googleが検出し続けているか | Search Console、URL検査、再クロール |
実装済みURL・テンプレートを監査母集団にする
最初の作業は「どのページに何を実装するか」を決めることではありません。現在どのURL・テンプレートから何が出力されているかを母集団化することです。
Search Consoleでエラーが出ているURLだけを見ると、構造化データが最初から出力されていないURLや、Googleがまだ検出していないURLを見落とします。
監査台帳に入れる項目
XMLサイトマップ、CMSの公開一覧、クロール結果などからURLを集め、少なくとも次を記録します。
- URL
- インデックス可否
- canonical URL
- ページ種類
- 使用テンプレート
- 実際に検出されたschema種別
- JSON-LD等の出力形式
- 出力元の候補
- 構文エラー
- Google適格性エラー・警告
- 可視本文との一致
- 重複の有無
- Search Consoleでの検出状況
- 修正担当
- 修正日
- 再検証結果
ここでのschema種別は、新規実装を選ぶためではなく、現状出力と期待状態を照合するための記録項目です。
ページ種別の参照表は期待値確認に限定する
監査時には「このテンプレートでは何が出る想定か」という期待値が必要です。ただし、本記事ではschema選定そのものを深掘りしません。
| ページ群 | 監査時に確認する代表的な出力 | 主な照合点 |
|---|---|---|
| 記事系 | Article / BlogPosting / BreadcrumbList 等 | 著者、公開日、更新日、画像 |
| 商品系 | Product 等 | 商品名、価格、在庫、評価の実在性 |
| 店舗系 | LocalBusiness系 等 | 名称、住所、営業時間、電話番号 |
| 求人系 | JobPosting 等 | 勤務地、雇用形態、期限、給与条件 |
何を新規実装すべきか判断する必要が生じた場合は、実装ガイド側へ切り分けます。監査担当者は「期待値」と「実出力」の差を記録することに集中します。
テンプレート単位で実装漏れ・出力差分を見つける
構造化データの欠落は、個別URLを一つずつ確認するより、同じテンプレートに属するURL同士を比較した方が見つけやすくなります。
代表URLと全体クロールを組み合わせる
まずテンプレートごとに代表URLを選び、次に同じテンプレートのURL群へ広げます。
次の状態は、実装後の不具合を疑うサインです。
- 同じ記事テンプレートなのに一部URLだけArticleがない
- 新テンプレートでは出るが旧テンプレートでは出ない
- CMSの特定入力欄が空の場合だけJSON-LD全体が消える
- JavaScript実行前とレンダリング後で出力が変わる
- 同一テンプレートなのに`@type`や必須値が一部URLだけ異なる
- Search Consoleで有効項目数が急減した
特定URLだけの問題か、テンプレート全体の問題かを先に切り分けると、修正箇所を誤りにくくなります。
意図的な未出力と障害を分ける
構造化データがないURLを、すべて「実装漏れ」と判定してはいけません。監査台帳では、未検出を次の3区分にします。
- 期待状態では出力されるはずだが欠落している
- 仕様上、意図的に出力していない
- 期待状態を確認しないと判断できない
3つ目は、実装方針の確認が必要な状態です。本記事内で新たなschema選定をせず、実装担当または実装ガイド側へ確認を戻します。
構文エラーとGoogleの適格性を別々に検証する
構文の妥当性と、Google検索機能への適格性は同じではありません。監査では2種類の検証を分けます。
Schema Markup Validatorで構文を確認する
Schema Markup Validatorでは、JSON-LD、Microdata、RDFaを含む構造化データの構文とschema.org語彙を確認します。
主な確認項目は次のとおりです。
- JSONとして解析できるか
- `@context`と`@type`を解釈できるか
- プロパティ名に誤記がないか
- 値の型が破綻していないか
- URL参照が切れていないか
- 複数ノードの関連付けが壊れていないか
解析不能な状態では、その後のGoogle適格性や本文照合より先に構文を修正します。
リッチリザルト テストでGoogle固有要件を確認する
リッチリザルト テストでは、Googleが対応する検索機能について、検出項目、重大な問題、警告、レンダリング後の状態を確認します。
| 結果 | 監査上の扱い | 次の確認 |
|---|---|---|
| 解析不能 | 最優先 | JSON・語彙・出力破損を確認 |
| 無効 | 高優先度 | 必須項目や値の型を確認 |
| 有効・警告あり | 影響評価 | 推奨項目と実データを確認 |
| 有効 | 機械検証は通過 | 本文一致・重複・本番認識へ進む |
| 未検出 | 障害候補 | 出力、レンダリング、取得、対象種別を確認 |
「有効」は、監査完了を意味しません。機械検証を通過した後に、可視本文との一致と重複出力を確認します。
可視本文と構造化データの不一致を確認する
構造化データは、ページに実際に表示されている内容と整合している必要があります。自動テストだけでは、値の意味的な不一致まで完全には確認できません。
主要項目を画面表示と照合する
| 構造化データ | 照合する画面要素 |
|---|---|
| `headline` / `name` | H1、商品名、求人名 |
| `description` | 本文、概要 |
| `author` | 著者表示、監修者情報 |
| `datePublished` | 公開日 |
| `dateModified` | 実際の更新日 |
| `image` | ページに関連する画像 |
| `offers` | 価格、在庫、通貨 |
| `review` / `aggregateRating` | 実在する口コミ、評価 |
| `address` | 店舗・企業の住所 |
| `openingHours` | 営業時間 |
| `jobLocation` | 勤務地 |
| `validThrough` | 求人・イベント等の期限 |
一字一句同じである必要はありませんが、対象、意味、数値、日付が矛盾してはいけません。
構文上は正しくても監査NGになる例
- 本文にないFAQを構造化データだけに入れている
- 独自評価を第三者口コミの評価のように出している
- 古い価格や在庫情報が残っている
- 更新していない記事の`dateModified`だけが毎日変わる
- 店舗ページに別店舗の住所が混入している
- 表示本文と構造化データで求人期限が異なる
重複JSON-LDとプラグイン競合を診断する
実装後監査では、同じ対象を複数の仕組みが出力していないかを確認します。CMSテーマ、SEOプラグイン、ECプラグイン、独自コードなどの併用は、二重出力の原因になります。
出力元を特定する
重複が見つかった場合は、次の出力元を順に確認します。
- CMSテーマ
- SEOプラグイン
- EC・求人等の専用プラグイン
- Googleタグマネージャー
- フロントエンドJavaScript
- サーバー側テンプレート
- 記事本文へ直接記述したコード
複数の構造化データがあること自体を即NGにするのではなく、同じ対象について識別子や値が競合していないかを確認します。
二重出力で特に確認する項目
- 同一Organizationで名称・URL・ロゴが一致しているか
- Articleの`publisher`が別のOrganizationを参照していないか
- 同じProductが異なる価格を持っていないか
- 同じページでプラグイン版と独自JSON-LDが重複していないか
- `@id`が毎回変化していないか
- ページ更新時に古いJSON-LDが残存していないか
二重出力を削除するときは、個別ページだけでなくテンプレート全体への影響を確認します。
Search Consoleの件数急減を切り分ける
Search Consoleで有効項目数が急減しても、直ちに「構造化データが消えた」とは断定できません。
Googleの案内では、レポートが全ページの完全な一覧ではないことに加え、未インデックス、解析不能、クロール遅延、アクセス制限なども欠落や減少の原因になり得ます。
急減時の確認順
- 減少した構造化データ種別と発生日を確認する
- 同時期のCMS・テーマ・プラグイン・デプロイ履歴を確認する
- 影響URLをテンプレート別に分ける
- URL検査でインデックス状況と最終クロールを確認する
- ライブURLを取得し、現在のHTMLとレンダリング結果を確認する
- リッチリザルト テストで現在の検出状態を確認する
- クロール障害、noindex、robots.txt、認証等を確認する
- 実装障害かGoogle側の検出・クロール差かを切り分ける
Search Consoleの数値は「ページ数」ではなく構造化データの「項目数」である点にも注意します。
修正優先順位を付ける
修正順は「エラー」「警告」というラベルだけで決めません。ユーザーへの誤認、影響URL数、検索機能への影響、事業重要度、テンプレート波及範囲を合わせて判断します。
| 優先度 | 主な状態 | 対応 |
|---|---|---|
| 緊急 | 虚偽・誤認につながる値、重大な品質違反 | 表示停止を含め即時対応 |
| 高 | 解析不能、必須要件不備、主要テンプレート全体の欠落 | 最優先で修正 |
| 中 | 推奨項目の欠落、重要ページの部分的な不整合 | 影響と工数で判断 |
| 低 | 検索対象外ページの軽微な警告 | 保留または監視 |
影響度を4軸で評価する
- 検索機能への影響
- ユーザーへの誤認リスク
- 影響URL数
- 対象ページの事業重要度
同じ問題が多数URLへ広がっている場合は、個別URLではなくテンプレートやプラグイン設定を修正します。価格、住所、著者など元データが誤っている場合は、出力コードではなくCMSやデータベース側を直します。
デプロイ前後で回帰テストを行う
構造化データ監査は、コードを直した時点では完了しません。修正で別テンプレートを壊していないかまで確認します。
デプロイ前の確認
- 修正対象テンプレートの代表URLを固定する
- 変更前の検出schemaと主要値を記録する
- 変更対象外テンプレートの代表URLもテスト対象に入れる
- ステージングでレンダリング後HTMLを確認する
- プラグインの二重出力が増えていないか確認する
本番反映後の再検証
- 本番の代表URLを再クロールする
- Schema Markup Validatorで構文を再確認する
- リッチリザルト テストでGoogle適格性を再確認する
- 可視本文との一致を再確認する
- 対象外テンプレートで新しい欠落が出ていないか確認する
- Search Consoleで修正検証を開始する
- Google再クロール後の推移を確認する
- 監査台帳へ結果と確認日を記録する
更新後に一部URLだけ欠落するケース
特に注意したいのは、テンプレート修正後に「大半は正常だが一部URLだけ消える」ケースです。
例として、次の原因があります。
- CMSの任意項目が空だとJSON-LD全体を出力しない条件分岐
- 旧テンプレートだけ修正が反映されていない
- キャッシュにより旧コードが残っている
- JavaScriptの実行条件がページごとに異なる
- プラグイン更新後に特定投稿タイプだけフックが変わった
全件監査が難しい場合でも、テンプレート別・条件別に代表URLを持ち、更新前後の差分を定期的に比較します。
構造化データ監査チェックリスト
- [ ] 実装済みURL・テンプレートを監査母集団にした
- [ ] Search Consoleだけを母集団にしていない
- [ ] テンプレートごとに代表URLを選んだ
- [ ] 実出力のschema種別を記録した
- [ ] JSON-LD、Microdata、RDFaの構文を確認した
- [ ] Google固有の重大・非重大な問題を確認した
- [ ] 可視本文と主要値を照合した
- [ ] 読者に見えない情報や古い値がない
- [ ] 重複JSON-LDと出力元を確認した
- [ ] 同一対象の`@id`や値が競合していない
- [ ] Search Consoleの件数変化をテンプレート・デプロイ履歴と照合した
- [ ] 問題をテンプレート・プラグイン・データ・個別URLに切り分けた
- [ ] 影響度に基づいて修正順を決めた
- [ ] デプロイ前に変更対象外テンプレートも確認した
- [ ] 本番反映後に再テストした
- [ ] Google再クロール後の状態を確認した
- [ ] 監査日、修正日、再検証日を記録した
まとめ
構造化データのSEO監査で確認すべきなのは、「何を実装するか」ではなく、実装済み状態のどこが壊れているかです。
このテーマの全体像や前提を確認したい場合は、「テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト」もあわせて確認してください。
実装済みURL・テンプレートを母集団化し、構文、Google適格性、可視本文との一致、重複出力、本番認識を切り分けます。そのうえで、テンプレート波及範囲と事業影響から優先順位を決め、デプロイ後に回帰監査を行います。
新規schemaの選定やJSON-LDの設計・実装方法は、AIOの構造化データ実装ガイド｜何をマークアップし、どこを監査するかに委譲します。本記事は、実装後のサイト横断監査・障害診断・再検証に回答範囲を限定します。
参考文献・データ元
- 構造化データの概要｜Google Search Central｜構造化データの基本と公開後の検証
- 構造化データに関する一般的なガイドライン｜Google Search Central｜品質・関連性・可視性に関する要件
- リッチリザルト レポートの概要｜Google Search Consoleヘルプ｜有効・無効項目、サンプリング、修正検証
- 構造化データの問題を修正・検証する｜Google Search Consoleヘルプ｜問題の修正、ライブテスト、検証
- 構造化データの欠落や項目数減少のデバッグ｜Google Search Consoleヘルプ｜未検出、件数減少、クロール・インデックス要因の切り分け
- 解析不能な構造化データ レポート｜Google Search Consoleヘルプ｜重大な構文エラーとテンプレート起因の確認
- Schema Markup Validator｜Schema.org｜構文と語彙の検証