はじめに
Google Search Consoleを運用していると、「構造化データに問題があります」「無効なアイテムが検出されました」といった通知を目にすることがあります。
構造化データは、Webページの内容を検索エンジンが理解しやすい形式で伝える仕組みです。
商品、イベント、FAQ、パンくずリスト、記事、求人、組織情報などを一定の形式で記述することで、Googleがページの意味や構造を把握しやすくなります。
しかし、構造化データにエラーが発生すると、検索結果で利用できるリッチリザルトの対象から外れる可能性があります。
さらに実務では、単純な記述ミスだけでなく、
- WordPressテーマ
- SEOプラグイン
- 独自プラグイン
- JavaScript
- Googleタグマネージャー
- CDN
- WAF
- キャッシュ
- テンプレート
など複数の要素が絡み合っているケースも珍しくありません。
そのため、構造化データの対応で重要なのは「エラーが出たページをその都度直すこと」ではありません。
原因を特定し、影響範囲を把握し、修正し、Googleから見た状態を検証し、再発を防ぐ運用体制まで構築することが重要です。
本記事では、Google Search Consoleを中心に、構造化データエラーを改善するための実務的な考え方と高度な運用保守について解説します。
構造化データエラーはSEO順位のエラーとは限らない
最初に理解しておきたいのが、構造化データと検索順位の関係です。
構造化データを正しく設定したからといって、検索順位が直接上昇することが保証されているわけではありません。
構造化データの重要な役割は、検索エンジンにページの情報を機械可読な形で伝え、対応する検索機能やリッチリザルトへの適格性を高めることです。
たとえば、
- 商品価格
- 在庫状況
- レビュー
- イベント開催日
- パンくずリスト
- 組織情報
- 記事情報
などが検索エンジンに適切に理解される可能性が高まります。
つまり構造化データ対応では、
「エラーが出た＝検索順位が落ちる」
と単純に判断するのではなく、
どの検索機能に影響するエラーなのか
を確認する必要があります。
Search Consoleの構造化データ問題を3段階で考える
構造化データの問題は、実務上おおむね次の3段階で整理すると対応しやすくなります。
無効
必須プロパティの欠落や重大な記述ミスなどによって、Googleがその構造化データを適切に利用できない状態です。
基本的には優先して対応します。
特に多数のページで同じエラーが発生している場合、個別ページではなくテンプレートやCMS側に問題がある可能性があります。
警告
推奨プロパティが不足しているなど、構造化データそのものは利用できるものの、情報が十分ではない状態です。
必ずしもリッチリザルトの対象外になるわけではありませんが、情報の充実度や将来的な仕様変更を考えれば、可能な範囲で改善しておくことが望ましいでしょう。
有効
Googleが構造化データを正常に認識している状態です。
ただし「有効」だからといって、必ず検索結果にリッチリザルトが表示されるわけではありません。
検索結果への表示は、検索クエリ、ページ内容、デバイス、品質評価など複数の条件によって決定されます。
最初に確認するべきなのは「エラー件数」ではなく「原因の単位」
Search Consoleで数百ページのエラーが表示されると、数百ページを修正しなければならないように感じるかもしれません。
しかし実際には、
1つのテンプレートの不具合によって数百ページに同じエラーが発生している
ケースがあります。
したがって、
「何ページエラーになっているか」
だけを見るのではなく、
「何種類の原因が存在するか」
を見ることが重要です。
たとえば100ページで同じProductのエラーが発生していたとしても、原因が商品ページテンプレート1か所であれば、修正箇所は1か所で済む可能性があります。
これが構造化データ対応を効率化する最も重要なポイントの一つです。
構造化データエラーで多い原因
代表的な原因を整理してみましょう。
| 原因 | 具体例 |
|---|---|
| JSON-LDの構文エラー | カンマ、括弧、引用符の不足 |
| 必須項目不足 | name、image、datePublishedなど |
| データ型の誤り | 日付、URL、数値形式の誤り |
| Schemaタイプの誤り | Articleページに不適切なSchemaを設定 |
| 二重出力 | テーマとSEOプラグインの双方からSchemaを出力 |
| プラグイン競合 | 複数のSEO・構造化データプラグインが干渉 |
| テンプレート不具合 | 全商品ページ・全記事ページで同じエラー |
| JavaScript | 実行後にSchemaが書き換わる |
| キャッシュ | 修正前のコードが配信され続けている |
| クロール制御 | robots.txtやnoindexなどによってGoogleが確認できない |
重要なのは、Search Consoleに表示されたメッセージだけで原因を断定しないことです。
画面上のエラーはあくまで「Googleが検出した結果」です。
本当の原因はCMSやテンプレート、プラグイン側に存在することがあります。
「解析できない構造化データ」は優先度が高い
特に注意したいのが、Search Consoleの「解析できない構造化データ」です。
これは単なる推奨項目不足ではありません。
JSON-LDなどに重大な構文エラーがあり、Googleがその構造化データが何を意味しているのか判別できない状態です。
たとえば、
}が足りない,の位置が間違っている- 文字列の引用符が閉じていない
- JSONの途中に不正な文字が入っている
- 複数のJSON-LDが壊れた状態で連結されている
といったケースがあります。
解析そのものができないため、まず構文を正常な状態に戻す必要があります。
また注意したいのは、構文エラーを修正した後です。
それまでGoogleがSchema自体を解析できなかったため、修正後になって初めて、
「必須プロパティがない」
「推奨項目が不足している」
といった別の問題が表示される場合があります。
したがって、
エラーが別のエラーに変わったから修正失敗
とは限りません。
解析できる段階まで改善した結果、新しい問題が見えるようになった可能性があります。
Rich Results TestとSchema Markup Validatorを使い分ける
構造化データを確認するときは、目的によって検証ツールを使い分けます。
Rich Results Test
Google検索のリッチリザルト対象として構造化データが利用可能か確認するためのツールです。
実務では最初に使用することが多いツールです。
Googleが対応している検索機能について、
- 検出された構造化データ
- エラー
- 警告
などを確認できます。
Schema Markup Validator
Schema.orgの仕様に沿って構造化データを検証するときに使用します。
Google検索独自の対応状況だけではなく、Schema.orgとして構造が正しいかを確認する用途に向いています。
つまり、
Google検索で使えるか → Rich Results Test
Schema.orgとして正しいか → Schema Markup Validator
という使い分けが実務的です。
URL検査で「Googleが実際に見ているページ」を確認する
構造化データ修正で非常に重要なのがSearch ConsoleのURL検査です。
開発者がブラウザで見ているページと、Googlebotが認識しているページが必ず同じとは限りません。
たとえば、
- JavaScript実行
- CDN
- キャッシュ
- WAF
- Cookie
- JavaScript遅延読み込み
- アクセス制御
などによって差が生まれる場合があります。
そのため、
「HTMLを直したから問題ない」
だけでは不十分です。
修正後はURL検査を行い、Googleがアクセス可能な状態になっているか確認します。
WordPressでは「構造化データを誰が出力しているか」を把握する
WordPressで特に多いのが、構造化データの二重出力です。
たとえば、
- WordPressテーマ
- Rank Math
- Yoast SEO
- 構造化データ専用プラグイン
- WooCommerce
- 独自PHP
- Googleタグマネージャー
など複数の仕組みがSchemaを生成していることがあります。
その結果、
同じArticle
同じOrganization
同じBreadcrumbList
などが重複して出力される場合があります。
構造化データエラーが発生した場合は、いきなりコードを書き換えるのではなく、
どのシステムがそのSchemaを生成しているのか
を特定することが重要です。
プラグインを一つずつ止める切り分けも有効
原因が分からない場合は、ステージング環境などでプラグインを一つずつ停止して確認する方法もあります。
たとえば、
- 現在のHTMLを保存
- SEOプラグインを停止
- Schemaを再確認
- キャッシュを削除
- Rich Results Testを実行
- 次のプラグインを確認
という流れです。
ただし、本番サイトでいきなりプラグインを停止すると、SEO設定や表示に影響する可能性があります。
できる限りステージング環境で検証することが重要です。
構造化データ修正の標準ワークフロー
実務では次の流れを標準化しておくと効率的です。
1．Search Consoleで問題を確認する
対象となるリッチリザルトレポートを開きます。
確認するのは、
- エラー内容
- 対象URL
- 件数
- 発生開始時期
- 共通テンプレート
です。
2．代表URLを決める
同じエラーが多数発生している場合、すべてのURLを最初から確認する必要はありません。
代表的な数URLを抽出します。
3．Rich Results Testを行う
代表URLをテストし、現在Googleがどの構造化データを検出しているか確認します。
4．出力元を特定する
テーマ、プラグイン、テンプレート、JavaScriptなど、どこからSchemaが生成されているか調査します。
5．上流原因を修正する
100ページを個別修正するのではなく、可能な限りテンプレートや共通処理など上流側を修正します。
6．修正後のページを再テストする
Rich Results Testなどでエラーが解消したことを確認します。
7．URL検査を行う
Googleがページにアクセスでき、修正後の状態を確認可能であることをチェックします。
8．Search Consoleで「修正を検証」を実行する
対象となる問題がすべて修正されていることを確認したうえで検証を開始します。
「修正を検証」を何度も押さない
Search Consoleでは、問題を修正した後に「修正を検証」を開始できます。
しかし、検証中にボタンを何度も操作する必要はありません。
Googleは対象URLを再クロールしながら確認するため、完了まで時間がかかります。
重要なのは、
検証ボタンを押すことではなく、検証前に同じ問題を持つURLをできるだけ修正しておくこと
です。
一部のURLだけ修正して検証を開始すると、残ったエラーによって検証が失敗する可能性があります。
検証には数日から数週間かかることがある
構造化データを修正しても、Search Consoleの表示が即座に変わるとは限りません。
Googleによる再クロール、再処理、検証が必要だからです。
修正した直後に、
「まだエラーになっている」
と判断してコードを再び変更すると、原因分析がさらに難しくなることがあります。
実務では、
「修正日」
「検証開始日」
「検証完了日」
を記録しておくとよいでしょう。
構造化データエラーを再発させない運用体制
構造化データ対応を毎回のトラブル対応で終わらせてはいけません。
中長期的には運用保守の仕組みを作ります。
Schema一覧を作成する
サイト内で使用しているSchemaを整理します。
例：
| ページ | Schema |
|---|---|
| トップページ | Organization、WebSite |
| 記事 | Article、BreadcrumbList |
| 商品 | Product、Offer |
| イベント | Event |
| 会社概要 | Organization |
| FAQ | FAQPage※利用条件確認 |
どのページで何を出力しているか分からない状態をなくすことが目的です。
出力元を記録する
Schemaごとに、
- WordPressテーマ
- SEOプラグイン
- PHP
- JavaScript
- CMS
- 外部ツール
のどれが出力しているのか記録します。
更新履歴を残す
テーマやプラグインを更新した日とSearch Console上のエラー発生日を比較できるようにします。
「プラグイン更新翌日からエラー急増」
と分かれば原因特定が非常に速くなります。
定期監視するべきKPI
構造化データ運用では、単にエラー件数をゼロにするだけでは不十分です。
最低限、次の指標を継続的に確認します。
- 有効アイテム数
- 無効アイテム数
- 警告数
- 対象URL数
- エラー発生日
- 修正完了までの日数
- 検証成功率
- 検索表示回数
- CTR
- リッチリザルト対象ページ数
ただし、CTRや検索表示回数が変化した場合でも、
「構造化データを修正したから増えた」
と即断してはいけません。
順位変動、検索需要、タイトル変更、競合状況など別の要因も考慮する必要があります。
Core Web Vitalsと合わせて監視する
高度なサイト運用では、構造化データだけを独立して管理するのではなく、
- Core Web Vitals
- インデックス状況
- クロール状況
- 構造化データ
- 検索パフォーマンス
を合わせて確認することが重要です。
なぜなら、Webサイトの変更は一つの領域だけに影響するとは限らないからです。
たとえばプラグイン変更によって、
構造化データは改善したものの、
JavaScriptが増えて表示速度が低下する
といったことも考えられます。
サイト全体の品質という視点で評価する必要があります。
構造化データは「実装」から「ガバナンス」へ
サイト規模が大きくなるほど重要になるのが構造化データのガバナンスです。
具体的には、
- 誰がSchemaを管理するのか
- 誰が変更を承認するのか
- どのページで利用するのか
- どのプラグインが生成するのか
- 更新時に誰が確認するのか
- エラー発生時に誰が対応するのか
を明確にします。
構造化データはSEO担当者だけの問題ではありません。
Web制作会社、エンジニア、マーケティング担当者、コンテンツ担当者が共通ルールを持つことが、長期的な安定運用につながります。
AI検索時代にも構造化データの品質管理は重要
検索は現在、従来型のリンク一覧だけでなく、AIによる要約や回答生成などへ広がっています。
そのためWebサイト側でも、
「人が読める文章」
だけでなく、
「機械が意味を正しく解釈しやすい情報構造」
という視点が重要になっています。
ただし、構造化データを追加すればAI検索で必ず引用されるというものではありません。
構造化データはあくまで、
- ページの意味
- エンティティ
- 属性
- 関係性
などを明確に伝えるための技術的基盤の一つです。
本文の品質、一次情報、専門性、著者情報、更新性、内部リンクなどと組み合わせて運用する必要があります。
まとめ
Google Search Consoleの構造化データエラー対応で重要なのは、エラーを一つずつ消していくことではありません。
重要なのは、
検知 → 原因特定 → 影響範囲把握 → 修正 → テスト → Google側で確認 → 修正を検証 → 継続監視
という一連の運用プロセスを確立することです。
特にWordPressや大規模CMSでは、テンプレートやプラグインの1か所の問題が数百、数千ページへ広がる可能性があります。
そのため、
「どのページが壊れているか」
だけでなく、
「何が構造化データを生成しているのか」
まで把握することが重要です。
構造化データは一度実装して終わるSEO施策ではありません。
検索エンジンの仕様変更、CMS更新、プラグイン更新、サイト改修に合わせて継続的に検証し続ける運用対象です。
Search Consoleを単なるエラー確認ツールではなく、Webサイトの技術品質を継続的に監視する仕組みとして活用することが、これからのSEO・AEO運用においてますます重要になるでしょう。
コメント