構造化データを確認する方法：JSON-LD のエラー、プロパティの欠落、期待できること

構造化データとは、ページに関する情報を機械が読み取れる形で記述したものです。この見出しとこの著者を持つ記事である、この価格の商品である、この住所にある店舗である、といった情報を、schema.org の語彙を使って書きます。検索エンジンはこれをコンテンツの理解に利用し、タイプによっては、商品の価格やパンくずリストといった拡張表示の検索結果を出すためにも使います。

Google が推奨しているのは JSON-LD です。これは JSON オブジェクトを収めた <script type="application/ld+json"> ブロックで、目に見える HTML とは切り離されています。追加もチェックも最も簡単な形式であり、このガイドでも JSON-LD を中心に扱います。

有効な JSON-LD の例

最小限の記事の例は、{"@context": "https://schema.org", "@type": "Article", "headline": "How to check structured data", "datePublished": "2026-09-26", "author": {"@type": "Organization", "name": "Example Team"}} です。すべてのオブジェクトに @type があります。入れ子になったもの（著者）は、それ自身のタイプを持つオブジェクトです。日付は ISO 8601 形式で、URLは絶対URLです。

構造化データを台無しにするエラー

1. 解析できない JSON

構文エラーが1つあるだけで、検索エンジンはブロック全体を無視します。よくある原因は、最後のプロパティのあとに付いた余分なカンマ、ワープロソフトから貼り付けられた「スマート」な曲線引用符、値の中にあるエスケープされていない二重引用符や改行、そして何も出力しなかったテンプレート変数です。最後のケースでは "name": , のような記述が残ります。JSON が CMS の入力欄から生成されている場合は、そこに紛れ込んだ HTML タグも同じ結果を招きます。

2. 重要なプロパティの欠落

検索機能ごとに、必須プロパティ（これがないと、ページはその機能の対象になりません）と推奨プロパティ（表示を充実させます）がドキュメントで定められています。name のない Organization、offers、review、aggregateRating のいずれもない Product、position のないパンくずリストの項目は、不完全です。Google の検索ギャラリーのドキュメントには、機能ごとの要件が記載されています。要件はときどき変更されるので、記憶に頼らずドキュメントを確認してください。

3. 無効なURL

url、logo、image には、実際にアクセスできる絶対URLを指定すべきです。テンプレートでは、相対パス、# のようなプレースホルダー、ステージング環境のホスト名がよく見つかります。

4. 重複したブロックや矛盾するブロック

テーマと SEO プラグインの両方が、名前やロゴの異なる Organization ブロックや WebSite ブロックを出力していると、控えめに言っても紛らわしい状態になります。各タイプは1回だけ生成してください。

5. ページの内容と一致しないマークアップ

構造化データは、訪問者が目にできる内容を記述したものでなければなりません。ページにないレビュー、表示価格と異なる価格、ページに表示されていない FAQ の回答は、Google のガイドラインに違反しており、手動による対策の対象になることがあります。この点は、どんな自動チェッカーも代わりに判断してはくれません。

Rudra の SEO チェッカーが確認する内容

無料 SEO チェッカーは、サーバーが送信する HTML に含まれるすべての JSON-LD ブロックを読み取ります（HTML コメントや CDATA で囲まれたブロック、type 属性に charset が付いたブロックも含みます）。報告するのは次の点です。

• 解析に失敗したブロック。パーサーのエラー内容も表示します（マークアップが使えない状態なので、減点を伴う警告です）
• 同じ @type が複数回宣言されているケース
• 有効な絶対URLになっていない url、logo、image の値
• 控えめに選んだ主要なタイプで欠けている重要なプロパティ。Organization と WebSite では name と url、Article、BlogPosting、NewsArticle では headline、datePublished、author、LocalBusiness では name と address、Product では name に加えて offers、review、aggregateRating のいずれか1つ、FAQPage では name を持つ質問と回答の text、BreadcrumbList では position と、name または item を持つ項目を確認します。

これらは妥当な最低ラインであって、各検索エンジンの要件をすべて写したものではありません。機能によっては Google がこれ以上を求めますし、Article については、Google はこれらのプロパティを必須ではなく推奨としています。また、チェッカーが読み取るのは JavaScript が実行される前の HTML だけなので、タグマネージャーで挿入された構造化データは検出されません。チェッカーの結果は最初の確認として扱い、そのうえで以下のツールで裏付けを取ってください。

あわせて使いたいツール

• Google のリッチリザルト テスト：ページが Google のどの機能の対象になるかと、それを妨げているエラーを表示します。JavaScript をレンダリングするので、挿入されたマークアップも確認できます。
• スキーマ マークアップ検証ツール（validator.schema.org）：Google の機能とは関係なく、あらゆる schema.org マークアップを語彙に照らして検証します。
• Search Console の拡張レポート：Google がクロールしたページ全体について、構造化データのタイプごとにエラーと警告を表示します。

構造化データでは約束できないこと

有効で内容のそろったマークアップがあれば、ページは拡張表示の対象になります。ただし、表示が保証されるわけではありません。表示するかどうかは検索エンジンが検索クエリごとに判断しますし、機能そのものも変わっていきます。たとえば Google は2023年に、FAQ のリッチリザルトをごく一部の権威ある政府機関や医療・健康関連のサイトに限定し、HowTo のリッチリザルトの表示も終了しました。また、構造化データは検索順位を上げる近道でもありません。その価値は、検索エンジンがコンテンツを正確に理解できるようにすることにあります。

シンプルな運用フロー

1. JSON-LD は、CMS やテンプレートで、ページを表示するのと同じデータから生成します。そうすれば両者がずれることはありません。
2. 各タイプは、1ページにつき1回だけ出力します。
3. テンプレートを変更するたびに、テンプレートごとに1ページを選び、SEO チェッカーとリッチリザルト テストで確認します。
4. デプロイのあとは、Search Console の拡張レポートに新しいエラーが出ていないか見ておきます。