JSON-LD構造化データ バリデーター
HTMLソースやJSON-LDを貼り付けるだけでFAQPage・BreadcrumbList・Articleなどの構造化データを検証。必須プロパティの過不足やGoogleリッチリザルトで見逃しがちなミスを一覧表示し、公開前のセルフチェックに役立ちます。
Tips
- FAQPageのacceptedAnswerは必ずtextプロパティに文字列を直接入れてください。オブジェクトや配列を入れるとGoogleのリッチリザルトが認識できません。
- BreadcrumbListのpositionは1から始まる連番にしてください。欠番や重複があると正しいパンくずリストとして認識されません。
- Articleのheadlineは、Googleの表示上110文字程度までが目安です。長すぎると検索結果で末尾が切り詰められる場合があります。
- HTMLソースをそのまま貼り付けても、<script type="application/ld+json">の中身だけを自動抽出して検証します。JSON部分だけを貼り付けても構いません。
- 複数の構造化データを1ページに設置する場合は、それぞれ別の<script>タグに分けて記述すると管理しやすくなります。
よくある質問
余談ですが ― JSON-LDがMicrodata・RDFaを置き換えた理由
JSON-LD（JSON for Linking Data）は、もともと2010年代前半にW3Cのコミュニティグループが策定したLinked Data用のフォーマットです。HTML要素の属性に直接埋め込む従来の構造化データ記法（Microdata・RDFa）と異なり、JSON-LDは<script>タグの中に独立したJSONとして記述できるため、既存のHTMLレイアウトを一切崩さずに構造化データを追加・削除できるのが最大の利点です。Googleは2015年前後からJSON-LDを推奨形式として位置づけ、現在ではリッチリザルトのドキュメントもJSON-LDの記法を前提に書かれています。
このサイト自身のFAQセクションも、ページ側でFAQの質問と回答を1件ずつ書くだけで、内部的にFAQPage形式のJSON-LDが自動生成される仕組みになっています。人間が見る通常のHTML（アコーディオン表示）と、検索エンジンが読み取るJSON-LDを二重に手打ちする必要がなく、片方を修正すればもう一方も自動的に追従するため、表示内容とスキーマの食い違いが起きにくいのが実務上のメリットです。
構造化データは文法的に正しいJSONであっても、Schema.orgの必須プロパティが欠けていたり、Googleが定める推奨プロパティが無かったりすると、リッチリザルト（検索結果でのFAQ表示・パンくずリスト表示など）が反映されないことがあります。特にacceptedAnswer.textのようなネストの深いプロパティは、実装時に構造を誤りやすい典型例です。公開前にこうしたツールで機械的にチェックしておくことで、Search Consoleの「拡張」レポートで後からエラーに気づくよりも早い段階で不備を発見できます。