構造化データチェックツールの使い方|テスト・確認方法とエラー対処を解説

実装した構造化データマークアップがGoogleに正しく認識されるか不安に感じたり、リッチリザルトが検索結果に表示されず原因を探していたりしませんか。
この記事で紹介する公式ツールを使ったテストと正しい確認方法を実践すれば、自サイトの構造化データのエラーをゼロにし、Googleの検索結果でリッチリザルトが正しく表示される準備が整った状態になります。
わかりやすく解説する各ツールと手順に沿って、構造化データの問題を解消しましょう。
構造化データチェックに推奨される公式検証ツールの使い分け
構造化データのチェックには、Googleが公式に提供する「リッチリザルトテスト」と「スキーママークアップ検証ツール」の2つを使用します。
それぞれのツールは検証の目的が異なるため、特徴を理解して使い分けることが重要です。
リッチリザルトテストはGoogle検索結果でのリッチリザルト表示の可否を判定する目的で使い、スキーママークアップ検証ツールは構造化データの一般的な構文エラーを検知する目的で使用します。
まずはこの2つのツールの違いを理解し、目的に応じて適切なツールを選択することから始めましょう。
Google検索のリッチリザルト表示を判定するリッチリザルトテスト
リッチリザルトテストは、実装した構造化データがGoogle検索のリッチリザルトとして表示される資格があるかどうかをテストするためのツールです。
このツールにURLまたはコードを入力して実行すると、Googleがそのページをどのように認識し、どのリッチリザルトが生成可能かを判定します。
パンくずリスト、商品情報、FAQ、レビューなど、Googleがサポートしているリッチリザルトに対応しているかを確認する際に使用します。
エラーや警告が表示された場合は、リッチリザルトの要件を満たしていないことを意味するため、修正が必要です。
文法エラーを包括的に検知するスキーママークアップ検証ツール
スキーママークアップ検証ツールは、schema.orgが定める語彙に基づいた構造化データの構文が正しいかを確認するためのツールです。
リッチリザルトテストがGoogleの機能に特化しているのに対し、このツールはより広範なschema.orgの文法チェックを目的とします。
Googleのリッチリザルトとしては利用されないプロパティであっても、構文エラーがあれば検知できます。
マークアップの一般的な妥当性を確認したい場合や、リッチリザルトテストで原因不明のエラーが出た際の切り分けに役立ちます。
旧構造化データテストツールの移管先に関する注意点
以前はGoogleの公式ツールとして「構造化データテストツール」が広く利用されていましたが、このツールは2020年に提供が終了し、主な機能は「スキーママークアップ検証ツール」に移管されました。
したがって、古い情報源で紹介されている旧ツールのブックマークなどは更新が必要です。
Googleのリッチリザルトに関するテスト機能は「リッチリザルトテスト」が担う形に分担されています。
構造化データマークアップの検証を行う際は、目的に応じてこの2つの後継ツールを使い分けるようにしてください。
3ステップでエラーを解消して検証を完了する構造化データチェックの手順
構造化データのチェックは、ツールに検証対象を入力し、テストを実行して結果を確認、エラーがあれば修正するという3つのステップで完了します。
この手順をわかりやすく解説するため、Googleが主に推奨する「リッチリザルトテスト」の画面を例に説明します。
このシンプルな確認方法をマスターすれば、誰でも迅速に構造化データの問題点を発見し、修正作業に取り掛かることができます。
まずは最初のステップとして、検証したい対象をツールに読み込ませましょう。
ステップ1:検証するURLかHTMLコードを入力画面に貼り付ける
リッチリザルトテストの画面を開き、検証方法を選択します。
公開済みのWebページをテストする場合は、「URL」タブを選択し、対象ページのURLを入力します。
まだ公開していないページや、HTMLの一部だけをテストしたい場合は、「コード」タブに切り替え、対象のHTMLコードを直接貼り付けます。
どちらか一方を入力したら、「テストを実行」ボタンをクリックします。
これにより、Googleがページをレンダリングし、構造化データを解析するプロセスが開始されます。
ステップ2:テストを実行して検出された項目を確認する
テストを実行すると、検証結果画面が表示されます。
まず、「ページはリッチリザルトに対応しています」または「ページはリッチリザルトに対応していません」という総合評価を確認します。
次に、「検出された構造化データ」のリストに、ページ内で見つかった構造化データのタイプが表示されるので、意図したものが認識されているか確認してください。
各項目には「有効」「警告」「不合格」のステータスが付与され、問題の有無が一目でわかります。
ステップ3:構文エラーが発生した対象箇所を修正する
エラーや警告がある項目をクリックすると、詳細が表示されます。
どのプロパティが不足しているか、あるいはどの値が不適切かといった具体的な問題点が指摘されます。
例えば、必須プロパティである「name」が欠けている、といったエラーが確認できます。
さらに、エラーメッセージの横にあるコード箇所をクリックすると、入力したHTMLコード内の該当部分がハイライト表示されるため、修正すべき箇所を正確に特定可能です。
指摘内容に従って元のHTMLやJSON-LDを修正し、再度テストにかけてエラーが解消されたかを確認します。
構造化データの検証結果でエラーが出た場合の具体的な原因
構造化データマークアップのテストでエラーが検出される主な原因は、「必須プロパティの記述漏れ」「JSON-LDなどの構文ミス」「Googleのガイドライン違反」の3つに大別されます。
これらの原因を理解することで、エラーメッセージが表示されても冷静に対処し、迅速に修正できるようになります。
検証結果を確認し、どの原因に該当するのかを切り分けることが、問題解決の第一歩です。
次のセクションでは、テスト合格後もリッチリザルトが表示されない要因について解説します。
必須プロパティの記述漏れによるエラー
各リッチリザルトのタイプには、Googleが表示に必要とする「必須プロパティ」が定められています。
この必須プロパティが一つでも欠けているとエラーとなり、リッチリザルトは表示されません。
例えば、商品レビューの構造化データでは、レビュー対象の「name」や評価を示す「reviewRating」などが必須です。
リッチリザルトテストの結果リストで「不合格」と表示された項目を確認し、エラー詳細に記載されている不足プロパティをコードに追加することで、この問題は解決できます。
JSON-LDの構文ミスによる解析エラー
構造化データが正しく解析されない原因として、JSON-LDやMicrodataなどの記述形式における単純な構文ミスが挙げられます。
特にJSON-LDでは、プロパティの区切りを示すカンマ(,)の付け忘れや余分な記述、波括弧({})や角括弧([])の閉じ忘れなどが頻繁に起こります。
これらのミスがあると、ツールは構造化データを正しく認識できません。
スキーママークアップ検証ツールはより厳密に構文をチェックするため、この種の基本的なエラーの確認・テストに有効です。
Googleのガイドライン違反による警告
構文は正しいものの、Googleが定める品質に関するガイドラインに違反している場合、「エラー」ではなく「警告」として表示されることがあります。
例えば、ユーザーに見えないコンテンツをマークアップしたり、ページの内容と無関係な構造化データを記述したりするケースが該当します。
警告は直ちにリッチリザルトの表示を妨げるものではありませんが、Googleのペナルティ対象となる可能性があるため、ガイドラインを確認し、検索ユーザーにとって有益なマークアップへと修正することが推奨されます。
テストに合格してもリッチリザルトが表示されない主な要因
リッチリザルトテストに合格し、「ページはリッチリザルトに対応しています」と表示されたとしても、必ずしもGoogleの検索結果にリッチリザルトが反映されるとは限りません。
テストの合格は、あくまで技術的な要件を満たしていることを示す第一関門です。
実際に表示されるかどうかは、Googleの品質評価や検索結果の仕様など、他の複数の要因に左右されます。
この点を理解しておくことで、表示がすぐに反映されなくても慌てず、次の打ち手を検討できます。
Googleによる品質評価による影響
Googleは、検索ユーザーに最適な体験を提供するため、構造化データの内容だけでなく、Webサイト全体の品質も評価しています。
サイトの信頼性、専門性、権威性(E-E-A-T)、コンテンツの独自性、ユーザーの検索意図との関連性などが低いと判断された場合、テストに合格していてもリッチリザルトが表示されないことがあります。
構造化データの実装と並行して、サイト全体の品質を高める取り組みが、リッチリザルトの反映においても重要です。
表示は即時には行われず、Googleのクロールと評価を経てから反映されます。
FAQなど一部のリッチリザルトにおける表示対象の制限
技術的な問題や品質の問題がなくても、Googleの仕様変更によってリッチリザルトが表示されなくなるケースがあります。
代表的な例がFAQリッチリザルトで、2023年9月以降、その表示は政府機関や保健医療機関など、特に権威性と信頼性の高いサイトに限定されるようになりました。
そのため、一般的なビジネスサイトでは、ツールで有効と判定されても検索結果に表示されることはほとんどありません。
このように、そもそも表示対象から外れていないか、Google検索セントラルの最新情報をリストで確認することも重要です。
公開後の構造化データをGoogleサーチコンソールで継続監視する方法

構造化データを公開した後は、Googleサーチコンソールを使って継続的に監視することが重要です。
サーチコンソールのメニュー内にある「拡張」セクションを確認することで、Googleがサイト全体でどの構造化データを認識し、インデックスしているかを把握できます。
このレポートには、有効なアイテム数、警告があるアイテム数、そしてエラーがあるアイテム数が時系列グラフで表示されます。
エラーが新たに発生した場合は通知も届くため、問題の早期発見と修正対応が可能です。
この確認方法を定常的に行うことで、リッチリザルト表示の安定化と、変更が反映されたかどうかの追跡ができます。
AI検索エンジンによる正確な情報理解を促す構造化データの価値
構造化データマークアップは、従来の検索エンジンだけでなく、ChatGPTやGeminiのようなAI検索エンジンがコンテンツの意味を正確に理解する上でも極めて重要な役割を果たします。
構造化データは、単なるテキストの羅列から、製品の価格、企業の住所、イベントの日時といった明確な意味を持つ情報へと変換する特徴があります。
これにより、AIがユーザーの質問に対して回答を生成する際、信頼できる情報源として自社サイトのコンテンツを引用しやすくなります。
AIの回答内で自社情報が正しく扱われることは、これからのデジタルマーケティングにおいて不可欠です。
AIOとSEOの違いについては「AIOとSEOの違い」で詳しく紹介しています。
構造化データチェックに関してよく寄せられる質問
ここでは、構造化データのチェックやテストに関して、Web担当者からよく寄せられる質問とその回答をまとめました。
ツールの使い方やリッチリザルトの仕様について、多くの人が抱く疑問点を解消します。
これから構造化データの確認作業を行う際の参考にしてください。
公開前のテスト環境にあるページでも構造化データチェックはできますか?
はい、可能です。
リッチリザルトテストやスキーママークアップ検証ツールの「コード」タブに、ページのHTMLソースコードを直接貼り付けてテストすることで、未公開のページでもテストできます。
Basic認証などでアクセス制限されたテスト環境のURLは直接検証できないため、ソースコードをコピーして確認する方法が有効です。
エラーがゼロになれば必ず検索結果にリッチリザルトが反映されますか?
いいえ、必ず反映されるわけではありません。
エラーがゼロであることは技術的な前提条件に過ぎず、最終的な表示はGoogleのアルゴリズムがサイトの品質や信頼性、検索クエリとの関連性などを総合的に判断して決定します。
したがって、テスト合格後も表示されない場合は、コンテンツの質やサイト全体の評価を見直す必要があります。
URL入力かソースコード直接貼り付けのどちらで検証すべきですか?
公開済みのページはURL入力、未公開のページや動的に生成される特定の部分だけをテストしたい場合はソースコード直接貼り付けが推奨されます。
URL入力はGooglebotが実際にレンダリングした状態をテストできる特徴があり、ページ全体の最終的な状態を確認するのに適しています。
コード貼り付けは開発段階での迅速なテストに便利です。
まとめ
本記事では、構造化データマークアップのチェックに用いる公式ツールの使い方から、エラーの確認方法、具体的な修正手順までをわかりやすく解説しました。
リッチリザルトテストとスキーママークアップ検証ツールを正しく使い分け、定期的にGoogleサーチコンソールで監視することが重要です。
また、構造化データはAI検索エンジンが情報を正確に理解するためにも価値を高めています。
AIに自社の強みを正しく伝えるためのAIO対策はオノフへ
AIの回答に自社名が出ていても、強みやサービスの特徴まで正しく伝わっているでしょうか。AIO対策では、言及の有無だけでなく、どのような質問で紹介され、何を根拠に推薦されているかを確認することが大切です。
オノフのAIO支援は、リサーチによる顧客・市場理解を起点に、独自の一次情報づくりからコンテンツ制作、Webサイトへの実装・運用まで一気通貫でサポート。自社の強みが伝わる情報発信を支援します。
「AIに自社がどう紹介されているか知りたい」「対策の優先順位が分からない」とお悩みの方は、ぜひご相談ください。現状を整理し、自社に合った取り組みを一緒に考えます。