Google ツールに頼らず構造化データを検証する方法

構造化データの検証は、いつの間にか Google 向けツールにかなり依存するようになりました。それは理解できます。多くのチームが JSON-LD を追加するのはリッチリザルトを得たいからであり、Google のテストツールはよく知られています。しかし、構造化データは Google の形式ではありません。通常は Schema.org 語彙を使った JSON-LD であり、HTML に埋め込まれ、多くの利用者によって解釈され、自社の公開ワークフローによって保守されるものです。

検索エンジンの視点だけで検証していると、基本的な問題を見落とすことがあります。無効な JSON、レンダリング後に消えるデータ、古い商品価格、矛盾する canonical URL、あるいは技術的には有効でも意味的には不自然なマークアップなどです。

よりよいワークフローは、標準を起点にすることです。まずデータをデータとして検証し、次に語彙を検証し、そのうえで本番環境に存在するページとして検証します。

何を実際に検証しているのか？

「構造化データ」はひとつのものではありません。多くのウェブサイトでは、次の 4 つの層があります。

1. JSON 構文 — コードはパース可能か？
2. JSON-LD モデル — 意味のあるリンクトデータとして展開されるか？
3. Schema.org 語彙 — 型とプロパティは妥当か？
4. ページレベルの事実 — マークアップはユーザーやクローラーに見える内容と一致しているか？

Google ツールは主に 4 番目の層と、Google 固有のリッチリザルト対象可否に焦点を当てています。有用ではあります。しかし、完全ではありません。

たとえば、次のものは有効な JSON-LD でありながら、構造化データとしては不十分な場合があります。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

ここに壊れている箇所はありません。しかし、表示されるページの見出しが異なり、著者表記がなく、最終更新日がマークアップと矛盾しているなら、それは構文の問題ではなく品質の問題です。

ステップ 1: SEO を考える前に JSON をパースする

まずは地味なチェックから始めます。JSON はパースできるでしょうか？

HTML に埋め込まれた JSON-LD は、小さなテンプレートのミスで壊れることがよくあります。

• 末尾のカンマ
• 商品名内のエスケープされていない引用符
• 文字列内の無効な改行
• 条件付きフィールドの後に不足している波括弧
• レイアウト継承による script ブロックの重複
• CMS プラグインが部分的なオブジェクトを出力すること

ローカルでの確認に SEO プラットフォームは必要ありません。開発スタックにすでにあるツールを使えば十分です。

JavaScript の場合:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

CI では、レンダリング後の HTML から script の内容を抽出し、JSON としてパースします。これにより、多くの問題を本番環境に到達する前に検出できます。

重要なのは、Schema.org の検証より前にこれを行うことです。データが有効な JSON でなければ、語彙バリデーターは役に立ちません。

ステップ 2: JSON 構文だけでなく JSON-LD の挙動を確認する

有効な JSON であることは、有効な JSON-LD であることを自動的には意味しません。JSON-LD は @context、@type、@id、グラフ関係といった概念を使います。これらが不正に構成されていると、パーサーは意図とは異なる形でデータを解釈する可能性があります。

少なくとも、次を確認してください。

• すべてのブロックに適切な @context がある
• 主要なエンティティに明確な @type 値がある
• 繰り返し登場するエンティティには、有用な場合に安定した @id 値が使われている
• ネストされたエンティティが論理的につながっている
• 複数の値があり得る場合に配列が使われている

大規模なサイトでは、安定した識別子が特に役立ちます。自社組織が Article、Product、BreadcrumbList、FAQPage のデータに登場する場合、同じ @id を使うことで、利用者はそれらが同じエンティティへの参照であり、同じ名前を持つ無関係な 4 つの組織ではないと理解しやすくなります。

典型的なパターンは次のようになります。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

ここで目指しているのは、バリデーターを感心させることではありません。データの曖昧さを減らすことです。

ステップ 3: Schema.org 語彙に照らして検証する

JSON と JSON-LD の構造が健全であることを確認したら、次に語彙を確認します。

Schema.org バリデーターは、特定の検索エンジンのリッチリザルト規則ではなく Schema.org の用語に照らしてテストするため有用です。プロパティが認識されているか、型が期待どおりに解釈されているか、ネスト構造が意味をなしているかを確認できます。

ここで検出できるミスには、次のようなものがあります。

• datePublished ではなく publishingDate を使っている
• image が期待される場所で imageUrl を使っている
• 商品ではないカテゴリ一覧に Product マークアップを付けている
• 意味のあるレビュー対象を持たない AggregateRating
• ブランドアカウントに Person を使っている

警告の扱いには注意が必要です。Schema.org は意図的に柔軟です。バリデーターが、あなたのユースケースには有用でないプロパティを許可することもあれば、任意のものについて警告することもあります。検証は証拠として扱い、判決として扱わないでください。

実務上のルールはこうです。あるプロパティがページを機械により正確に理解させる助けになるなら残します。誰かがスニペット生成ツールからコピーしたという理由だけで存在しているなら、疑うべきです。

ステップ 4: マークアップを表示コンテンツと比較する

検索エンジンやその他のデータ利用者は、ページと一致しないマークアップを信頼しにくい傾向があります。さらに重要なのは、ユーザーには一貫性があるべきだということです。

構造化データの種類ごとに、マークアップを表示されているページと比較します。

Article と BlogPosting

見出し、著者、公開日、更新日、画像、発行者が表示されているか、または合理的に推測できるかを確認します。AI 支援コンテンツを公開している場合、不明確な著者性を覆い隠すために構造化データを使うべきではありません。小規模サイトにおける誠実な AI 開示については別に書いていますが、同じ原則がここにも当てはまります。メタデータは明確にするためのものであり、曖昧にするためのものではありません。

Product

名前、価格、在庫状況、通貨、バリエーション、評価、レビュー数を確認します。商品構造化データは、価格や在庫状況が CMS の外で変わるため、特に古くなりやすい領域です。

LocalBusiness

名前、住所、電話番号、営業時間、サービス提供エリアを確認します。フッターがある内容を示し、JSON-LD が別の内容を示しているなら、JSON-LD のほうが「優れている」わけではありません。矛盾しているのです。

BreadcrumbList

パンくずの位置が表示されているパンくずリストと一致しているか、URL が canonical で、クロール可能で、不必要にリダイレクトされていないかを確認します。

これは華やかな作業ではありません。同時に、多くの構造化データの問題が見つかる場所でもあります。

ステップ 5: テンプレートではなく、レンダリング後のページを検証する

多くのサイトでは、JavaScript、タグマネージャー、パーソナライゼーション層、コンポーネントのハイドレーションを通じて JSON-LD が生成されます。つまり、テンプレートファイルはクローラーやブラウザーが実際に見るものを表していない場合があります。

少なくとも次の 3 つの状態で、レンダリング後の HTML を検証してください。

• ローカル開発ビルド
• ステージングまたはプレビュー URL
• 本番 URL

ブラウザーの DevTools を使って最終的な DOM を確認します。application/ld+json を検索し、レンダリング後に実際に存在する正確な script 内容をコピーします。サーバーレンダリングされたマークアップとハイドレーション後のマークアップが異なる場合、利用者に読んでほしいのがどちらのバージョンなのかを決めてください。

構造化データが重複していないかも確認します。CMS プラグインとカスタムコンポーネントの両方が schema を出力すると、Article や Product ブロックの重複はよく起こります。重複が常に致命的というわけではありませんが、矛盾する重複は問題です。2 つの価格、2 人の著者、2 つの公開日、2 つの canonical URL などです。

これは、パフォーマンスや診断レポートを読む作業に似ています。最初にすべきことは慌てることではなく、シグナルとノイズを分けることです。Lighthouse レポートを慌てずに読むときにも同じ習慣が役立ちます。ただし、構造化データ自体を単一のスコアに還元すべきではありません。

ステップ 6: 本番環境の配信詳細を確認する

構造化データはソース内では完璧でも、ページが想定どおりにアクセス可能でないために本番環境で失敗することがあります。

確認する項目は次のとおりです。

• 最終ステータスコードがソフト 404 ではなく 200 である
• canonical URL が検証しているページと一致している
• リダイレクトが意図的で安定している
• インデックスを期待する場所で robots ディレクティブがインデックスを妨げていない
• 一部のユーザーエージェントに対して HTML がエラーページに置き換わっていない
• キャッシュされたページが古い JSON-LD を配信していない

ここでは HTTP の調査が重要です。商品ページが canonical な到達先にたどり着く前に 3 つの URL を経由してリダイレクトするなら、CMS からコピーした最初の URL ではなく、最終ページを検証してください。生の仕組みについては、本番環境でリダイレクトと HTTP ヘッダーをデバッグするための小さなツールキットが参考になります。

構造化データは真空の中に存在しているわけではありません。ヘッダー、リダイレクト、キャッシュ、canonical タグ、robots ディレクティブとともに移動します。

ステップ 7: リリースプロセスに構造化データのテストを追加する

手動検証は 1 ページなら問題ありません。しかし、数百、数千の URL にはスケールしません。

シンプルな自動テストスイートで、最もコストの高いミスを検出できます。

• 各テンプレート種別から代表的な URL を取得する
• すべての JSON-LD ブロックを抽出する
• JSON.parse でパースする
• 各ページ種別の必須フィールドをアサートする
• 日付が有効な ISO 8601 文字列であることを確認する
• URL が絶対 URL であり canonical であることを確認する
• 商品ページに価格と在庫状況が存在することを確認する
• 重複エンティティが矛盾していないことを確認する

これはテンプレート向けに CI で実行でき、本番 URL 向けにはスケジュール実行できます。目的は、すべてのリッチリザルト機能が表示されると証明することではありません。検索エンジンの外部にいる人がそれを約束することはできません。目的は、自社のデータを正確で、パース可能で、一貫した状態に保つことです。

<!-- tool-cta:start -->

💡 お試しください: スキーマロジックを検証する前に、JSON-LD を JSON Formatter に通して、後続のすべてのチェックを壊してしまう構文エラーを見つけましょう。

<!-- tool-cta:end -->

標準を起点にした検証チェックリスト

検索エンジンがそのページを好むかどうかを尋ねる前に、この短いチェックリストを使ってください。

• すべての JSON-LD ブロックは有効な JSON か？
• 各ブロックに正しい @context と @type が含まれているか？
• Schema.org プロパティのスペルは正しいか？
• マークアップは表示コンテンツと一致しているか？
• 日付、価格、評価、在庫状況は最新か？
• URL は絶対 URL で、canonical で、到達可能か？
• レンダリング後の本番ページは、テストしたページと同じか？
• 重複エンティティは意図的で、矛盾していないか？

これらの質問に「はい」と答えられるなら、構造化データ作業のうち持続性のある部分は完了しています。検索固有のテストは後でなお有用ですが、それは検証プロセスの土台ではなく、最後の互換性チェックであるべきです。