リンクされた構造化データをJSONで表す形式です。多くはscript要素に埋め込み、画面に見えるHTMLを変えずに、ページ内のエンティティとその関係を記述します。
判断のポイントと限界
JSON-LDは、リンクされたデータをJSONでシリアライズする方法です。Webページではscript要素に置き、Schema.orgの語彙と組み合わせて、読者が目にするエンティティ（記事、商品、組織、パンくず、イベントなど）を記述するのが一般的です。あくまで表現形式であり、リッチリザルトの表示を約束するものではありません。グラフの構文が正しく、画面に見える最新のページ情報と一致している必要があります。
確認する項目
ソースのテンプレートがそのままデプロイされたと決めつけず、レンダリング後のHTMLを取得します。JSON-LDをパースし、各ノードとその識別子を洗い出して、重要なプロパティを画面の内容と照合します。URLが解決できるか、参照が意図したエンティティを指しているか、日付・価格・在庫状況・著者・画像などの値が古くなっていないかを確認します。警告は文脈の中で判断します。バリデーターのメッセージは確認の手がかりであり、そのまま欠陥とは限りません。
実装の進め方
適切な範囲で最も小さいSchema.orgのタイプを選び、まず主たるエンティティを記述します。関連するエンティティは、ページ上でその事実が示されている場合にだけ追加します。値は、可能なら画面表示のテンプレートと同じ構造化データのソースから生成します。リリース後は代表的なレンダリング済みページを検証し、大量のページを生成するテンプレートにはリグレッションチェックを加えます。サイトマップ、canonical、robotsのチェックは、JSON-LDの検証とは別に行います。
よくある間違いと計測の限界
陥りやすいのは「スキーマ演出」です。検索機能を引き出したくて、ページが裏付けていない語彙を追加してしまうことを指します。隠した情報、でっち上げたプロパティ、矛盾するプロパティは、保守のリスクになり、グラフの信頼性も下げます。構造化データはまず画面に見えるページと照らして検証し、そのうえでグラフを確認します。直すのは語彙や参照の本当の誤りであり、チェッカーを黙らせるだけの修正ではありません。
実装例。編集記事なら、画面に見える情報から始めます。見出し、署名、公開日、リード画像、canonical URL、発行者の情報です。この記事を、ページを描画するのと同じコンテンツのフィールドからJSON-LDで記述します。記事には安定した識別子を1つ付けます。発行者と画像をリンクするのは、それらが実在し解決できる場合に限ります。著者・日付・画像が画面に表示されていないなら、バリデーターを通すためにグラフへ作り足してはいけません。
チェック基準。デプロイ後にレンダリング後のHTMLを取得し、JSON-LDのscriptをすべて抽出して、グラフごとにパースします。見出し、日付、画像、URL、著者の値を、人が見るページと照合します。識別子とURLが意図したリソースに解決されること、記事が別のテンプレートのエンティティを誤って記述していないことを確認します。関連する構造化データのテストも実行しますが、検出結果は分類します。パースエラー、語彙の不一致、任意の推奨項目の欠落、検索機能の対象になるかどうかのメモは、それぞれ別の扱いです。
よくある誤り。汎用的なスキーマのブロックを全ページに貼り付けたり、サービス・カテゴリー・商品を同じ主たるエンティティとしてマークアップしたりしないでください。ユーザーに見えない価格、評価、在庫、レビュー、著者を、JSON-LDで隠して伝えるのも避けます。リッチリザルトテストでは、canonical、robots、サイトマップ、内容の真実性は検証できません。これらもリリース時のチェックに含めます。JSON-LDはページの記述を助けるものであり、アクセスできないページや役に立たないページを補うことはできません。