構造化データの確認方法｜エラー・本文との不一致・重複を検証

構造化データの検証画面とURL一覧、監査チェックシートを使ってサイト全体を確認する担当者の手元

リッチリザルトテストでエラーが出ないことを確認しただけでは、実装後の構造化データを監査したとは言えません。構文エラーがなくても、本文にない評価値を出していたり、同じOrganizationを複数の出力元が異なる値で生成していたりすれば、監査上は問題だからです。

そこで、サイト全体で実装済みのURLを集めて監査の対象とし、適用範囲・技術要件・内容整合・更新性・取得状態の5軸で確認します。重複JSON-LDやプラグイン競合は、主に技術要件・内容整合・更新性で見つかった異常の原因を探るための診断項目として、5軸を横断して扱います。

適用範囲を最初に確認するのは、Search Consoleでエラーが出ているURLだけを見ると、構造化データが最初から出力されていないURLや、Googleがまだ検出していないURLを見落とすためです。

本記事が扱うのは、すでに構造化データを実装しているサイトの監査です。どのページに何のschemaを新規実装するか、JSON-LDをどう設計・実装するかは主題にしません。実装方針やページ種別ごとのマークアップ選定を確認したい場合は、AIOの構造化データ実装ガイド｜何をマークアップし、どこを監査するかを参照してください。

本文は、適用範囲の把握、技術要件の検証、内容整合の確認、重複・競合の診断、取得状態の確認、修正の優先順位付け、更新性の確認（修正後の再検証を含む）の順に進みます。読み終えると、5軸それぞれの確認方法、異常の原因の切り分け方、修正順の決め方、最後に使えるチェックリストが手元に残ります。

まず押さえる結論｜構造化データ監査は5軸で確認する

実装後の監査は、次の5軸に分けて確認します。表は、各軸で何を見るか、よくある問題、確認に使う手段をまとめたものです。

監査軸	確認すること	代表的な問題	主な確認手段
適用範囲	期待されるURL・テンプレートに構造化データが出力されているか	一部テンプレートだけArticleがない	サイトマップ、CMS一覧、クロール
技術要件	構文・型・必須項目・Google固有要件を満たすか	JSON解析不能、必須プロパティ不足	Schema Markup Validator、リッチリザルトテスト
内容整合	可視本文と構造化データの対象・値・意味が一致するか	本文と価格・著者・日付が異なる	目視照合、レンダリング結果
更新性	ページやテンプレート、仕様変更に構造化データが追従するか	古い価格、更新日、在庫、旧出力が残る	更新前後差分、CMS・デプロイ履歴
取得状態	Googleが本番ページを取得・認識できるか	noindex、robots制限、クロール遅延、未検出	Search Console、URL検査、再クロール

取得状態の軸では、クロール（検索エンジンがページを巡回して内容を取得すること）の遅れや、robots.txt（クローラーのアクセスを制御するファイル）による制限、noindexの指定などで、Googleがページを取得・認識できているかを見ます。

もう一つ注意したいのは、監査の対象をSearch Consoleのリッチリザルトレポートだけにしないことです。Googleは、このレポートが検出項目の完全な一覧ではなく、品質評価のためのサンプルであると案内しています。

5軸は、実際の監査工程に落とすと、適用範囲、構文、Google適格性、内容品質、重複・競合、本番認識・継続性へ細かく分けられます。技術要件は構文とGoogle適格性に分け、更新性は内容品質と本番認識・継続性にまたがって確認します。次の図は、監査の工程を6つの層で示したものです。

実装範囲、構文、Google適格性、内容品質、本番認識、継続性からなる構造化データ監査の6層

適用範囲｜実装済みURL・テンプレートを監査母集団にする

この節では、監査の出発点として何を集めるかを決めます。最初の作業は、「どのページに何を実装するか」を決めることではありません。現在どのURL・テンプレートから何が出力されているかを集め、監査の対象となる母集団にすることです。

監査台帳に入れる項目

XMLサイトマップ、CMSの公開一覧、サイトを巡回して調べたクロール結果などからURLを集め、少なくとも次の項目を記録します。

URL
インデックス可否
canonical URL
ページ種類
使用テンプレート
実際に検出されたschema種別
JSON-LD等の出力形式
出力元の候補
構文エラー
Google適格性エラー・警告
可視本文との一致
重複の有無
Search Consoleでの検出状況
修正担当
修正日
再検証結果

ここでのschema種別は、新規実装を選ぶためではなく、現状出力と期待状態を照合するための記録項目です。

ページ種別の参照表は、期待値の確認にだけ使う

監査では、「このテンプレートでは何が出る想定か」という期待値が必要です。次の表は、ページ群ごとの代表的な出力と照合点をまとめたものです。本記事ではschemaの選定そのものを深掘りしません。

ページ群	監査時に確認する代表的な出力	主な照合点
記事系	Article / BlogPosting / BreadcrumbList 等	著者、公開日、更新日、画像
商品系	Product 等	商品名、価格、在庫、評価の実在性
店舗系	LocalBusiness系等	名称、住所、営業時間、電話番号
求人系	JobPosting 等	勤務地、雇用形態、期限、給与条件

JobPosting固有の監査では、給与・勤務地・雇用形態・掲載期限に加え、募集終了や再募集時の更新運用まで求人単位で確認します。詳しくは、JobPosting構造化データの監査方法｜求人情報・給与・勤務地・期限の不一致を確認を参照してください。

期待値は固定ではない点にも注意します。監査日ごとにGoogle Search Centralの現在のサポート対象・必須要件を確認し、過去に実装理由があったschemaでも、現在の検索機能やページ役割に対して適用理由が残っているかを確認します。

適用範囲｜テンプレート単位で実装漏れ・出力差分を見つける

この節では、欠落や出力の差を、テンプレート単位で見つける方法を説明します。構造化データの欠落は、個別URLを一つずつ確認するより、同じテンプレートに属するURL同士を比較した方が見つけやすくなります。

代表URLと全体クロールを組み合わせる

まずテンプレートごとに代表URLを選び、次に同じテンプレートのURL群へ広げます。その途中で次の状態が見つかったら、実装後の不具合を疑います。

同じ記事テンプレートなのに一部URLだけArticleがない
新テンプレートでは出るが旧テンプレートでは出ない
CMSの特定入力欄が空の場合だけJSON-LD全体が消える
JavaScript実行前とレンダリング後で出力が変わる
同一テンプレートなのに@typeや必須値が一部URLだけ異なる
Search Consoleで有効項目数が急減した

特定URLだけの問題か、テンプレート全体の問題かを先に切り分けると、修正箇所を誤りにくくなります。

意図的な未出力と障害を分ける

構造化データがないURLを、すべて「実装漏れ」と判定してはいけません。監査台帳では、未検出を次の3区分に分けます。

期待状態では出力されるはずだが欠落している
仕様上、意図的に出力していない
期待状態を確認しないと判断できない

3つ目は、実装方針の確認が必要な状態です。実装担当または実装ガイド側へ確認を戻します。

技術要件｜構文エラーとGoogleの適格性を別々に検証する

構文が正しいことと、Google検索の機能に対応できていることは同じではありません。監査では、この2種類の検証を分け、構文から先に確認します。

Schema Markup Validatorで構文を確認する

Schema Markup Validatorでは、JSON-LD、Microdata、RDFaを含む構造化データの構文とschema.org語彙を確認します。主な確認項目は次のとおりです。

JSONとして解析できるか
@contextと@typeを解釈できるか
プロパティ名に誤記がないか
値の型が破綻していないか
URL参照が切れていないか
複数ノードの関連付けが壊れていないか

解析不能な状態では、Google適格性の確認や本文との照合より先に、構文を修正します。

リッチリザルトテストでGoogle固有要件を確認する

リッチリザルトテストでは、Googleが対応する検索機能について、検出項目、重大な問題、警告、レンダリング後の状態を確認します。次の表は、結果ごとの監査上の扱いと、次に確認することです。

結果	監査上の扱い	次の確認
解析不能	最優先	JSON・語彙・出力破損を確認
無効	高優先度	必須項目や値の型を確認
有効・警告あり	影響評価	推奨項目と実データを確認
有効	機械検証は通過	本文一致・重複・本番認識へ進む
未検出	障害候補	出力、レンダリング、取得、対象種別を確認

「解析不能」と「無効」は先に直します。

Schema Markup Validator、リッチリザルトテスト、URL検査、Search Consoleを目的別に使い分ける監査フロー

「有効」は、監査の完了を意味しません。機械検証を通過した後に、可視本文との一致と重複出力を確認します。

内容整合｜可視本文と構造化データの不一致を確認する

構造化データは、ページに実際に表示されている内容と整合している必要があります。自動テストだけでは、値の意味の不一致まで完全には確認できないため、画面表示との照合が欠かせません。

主要項目を画面表示と照合する

次の表は、構造化データの主なプロパティと、照合する画面上の要素の対応です。

構造化データ	照合する画面要素
`headline` / `name`	H1、商品名、求人名
`description`	本文、概要
`author`	著者表示、監修者情報
`datePublished`	公開日
`dateModified`	実際の更新日
`image`	ページに関連する画像
`offers`	価格、在庫、通貨
`review` / `aggregateRating`	実在する口コミ、評価
`address`	店舗・企業の住所
`openingHours`	営業時間
`jobLocation`	勤務地
`validThrough`	求人・イベント等の期限

一字一句同じである必要はありませんが、対象、意味、数値、日付が矛盾してはいけません。

構文上は正しくても監査NGになる例

構文エラーがなくても、次のような状態は監査で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が残存していないか

二重出力を削除するときは、個別ページだけでなく、テンプレート全体への影響を確認します。

取得状態｜Googleが本番ページを取得・認識できるか確認する

構造化データが技術的に正しくても、Googleがページを取得できなければ、Search Console上で認識されません。取得状態では、少なくとも次の3点を切り分けます。

URLがインデックス対象か
構造化データ自体が有効か
robots.txt・noindex・認証などで取得が妨げられていないか

Search Consoleで有効項目数が急減しても、直ちに「構造化データが消えた」とは断定できません。Googleの案内では、レポートが全ページの完全な一覧ではないことに加え、未インデックス、解析不能、クロール遅延、アクセス制限なども欠落や減少の原因になり得ます。

構造化データの監査と、インデックス・robots・canonicalの監査は、対象領域が異なります。ただし、異常を見つけた後の原因の切り分けでは、両方を合わせて確認します。

急減時の確認順

有効項目数の急減に気づいたら、次の順で確認します。

減少した構造化データ種別と発生日を確認する
同時期のCMS・テーマ・プラグイン・デプロイ履歴を確認する
影響URLをテンプレート別に分ける
URL検査でインデックス状況と最終クロールを確認する
ライブURLを取得し、現在のHTMLとレンダリング結果を確認する
リッチリザルトテストで現在の検出状態を確認する
クロール障害、noindex、robots.txt、認証等を確認する
実装障害かGoogle側の検出・クロール差かを切り分ける

Search Consoleの数値は「ページ数」ではなく、構造化データの「項目数」です。急減を読むときは、この違いにも注意します。

修正優先順位を付ける

修正順は、「エラー」「警告」というラベルだけで決めません。ユーザーへの誤認、影響URL数、検索機能への影響、事業重要度、テンプレート波及範囲を合わせて判断します。このうち最初の4つは、次の見出しで影響度の4軸として評価します。次の表は、優先度ごとの主な状態と対応です。

優先度	主な状態	対応
緊急	虚偽・誤認につながる値、重大な品質違反	表示停止を含め即時対応
高	解析不能、必須要件不備、主要テンプレート全体の欠落	最優先で修正
中	推奨項目の欠落、重要ページの部分的な不整合	影響と工数で判断
低	検索対象外ページの軽微な警告	保留または監視

影響度を4軸で評価する

優先度を決めるときの影響度は、次の4軸で評価します。

検索機能への影響
ユーザーへの誤認リスク
影響URL数
対象ページの事業重要度

検索機能への影響、誤認リスク、影響URL数、事業重要度の4軸で構造化データの修正優先度を決める図

同じ問題が多数のURLへ広がっている場合は、個別のURLではなく、テンプレートやプラグインの設定を修正します。価格、住所、著者など元データが誤っている場合は、出力コードではなく、CMSやデータベース側を直します。

更新性｜ページ変更・テンプレート変更後も正しい状態を保てるか確認する

更新性では、「今の値が正しいか」だけでなく、ページ更新、CMS・テーマ・プラグインの変更、URL移行、Google側のサポート仕様の変更の後にも、構造化データが追従するかを確認します。構造化データ監査は、コードを直した時点では完了しません。修正で別テンプレートを壊していないかまで確認します。

デプロイ前の確認

修正を本番へ反映する前に、次の点を確認します。

修正対象テンプレートの代表URLを固定する
変更前の検出schemaと主要値を記録する
変更対象外テンプレートの代表URLもテスト対象に入れる
ステージングでレンダリング後HTMLを確認する
プラグインの二重出力が増えていないか確認する

本番反映後の再検証

本番へ反映した後は、次の順で再検証します。

本番の代表URLを再クロールする
Schema Markup Validatorで構文を再確認する
リッチリザルトテストでGoogle適格性を再確認する
可視本文との一致を再確認する
対象外テンプレートで新しい欠落が出ていないか確認する
Search Consoleで修正検証を開始する
Google再クロール後の推移を確認する
監査台帳へ結果と確認日を記録する

開発環境、本番公開直後、Google再クロール後の3段階で構造化データを検証する手順

コンテンツ更新時の構造化データ更新漏れを確認する

テンプレートの改修だけでなく、ページ内容そのものを更新したときに構造化データも追従するかを監査します。特に次の変更は、表示内容とJSON-LDの不一致が起きやすい確認のタイミングです。

商品価格・在庫状態の変更
記事本文、公開日・更新日の変更
著者・監修者の変更
店舗情報や求人条件の変更
URL移行
CMSテーマやSEOプラグインの変更
Google側のサポート仕様の変更

監査台帳では、「現在の値が正しいか」だけでなく、更新時に構造化データも自動更新される設計かを確認します。本文とJSON-LDを別々に手入力している場合は、更新漏れが起こりやすくなります。可能であれば、タイトル、価格、在庫、日付、著者などを同じCMSデータから生成する設計にします。

更新後に一部URLだけ欠落するケース

特に注意したいのは、テンプレート修正後に「大半は正常だが一部のURLだけ消える」ケースです。原因としては、次のものがあります。

CMSの任意項目が空だとJSON-LD全体を出力しない条件分岐
旧テンプレートだけ修正が反映されていない
キャッシュにより旧コードが残っている
JavaScriptの実行条件がページごとに異なる
プラグイン更新後に特定投稿タイプだけフックが変わった

全件監査が難しい場合でも、テンプレート別・条件別に代表URLを持ち、更新前後の差分を定期的に比較します。

構造化データ監査チェックリスト

監査の最後に、次の項目を確認します。最初の5項目は5軸それぞれの確認、残りは各軸の作業の確認です。

適用範囲：期待されるURL・テンプレートに構造化データがある
技術要件：構文・型・必須項目・Google固有要件を確認した
内容整合：可視本文と対象・値・意味が一致している
更新性：ページ・テンプレート・仕様変更後も値が追従する
取得状態：Googleが本番URLを取得・認識できる状態にある
実装済みURL・テンプレートを監査母集団にした
Search Consoleだけを母集団にしていない
テンプレートごとに代表URLを選んだ
実出力のschema種別を記録した
JSON-LD、Microdata、RDFaの構文を確認した
Google固有の重大・非重大な問題を確認した
可視本文と主要値を照合した
読者に見えない情報や古い値がない
重複JSON-LDと出力元を確認した
同一対象の@idや値が競合していない
Search Consoleの件数変化をテンプレート・デプロイ履歴と照合した
問題をテンプレート・プラグイン・データ・個別URLに切り分けた
影響度に基づいて修正順を決めた
デプロイ前に変更対象外テンプレートも確認した
本番反映後に再テストした
Google再クロール後の状態を確認した
監査日、修正日、再検証日を記録した

まとめ

構造化データのSEO監査で確認するのは、「何を実装するか」ではなく、実装済みの状態のどこが壊れているかです。

実装済みURL・テンプレートを母集団にして、適用範囲・技術要件・内容整合・更新性・取得状態の5軸で切り分けます。重複JSON-LDやプラグイン競合は、横断的な原因診断として確認します。修正は、テンプレートへの波及範囲と事業への影響から順番を決め、更新やデプロイの後には、修正で別のテンプレートを壊していないかを再確認します。

最初の一歩は、実装済みURLをテンプレート別に集め、代表URLを選んで監査台帳を作ることです。

このテーマの全体像や前提を確認したい場合は、「テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト」もあわせて確認してください。

新規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｜構文と語彙の検証

‹ 親記事: テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト

構造化データの確認方法｜エラー・本文との不一致・重複を検証

まず押さえる結論｜構造化データ監査は5軸で確認する