構造化データ:有効なJSON-LDとリッチリザルトを区別する

要点

JSON-LDは構造化語彙で情報を記述します。構文が有効でも、Google機能への適格性、リッチ表示、AIシステムによる引用は保証されません。

資料と地図を収めた無人の情報アーカイブ
この記事の内容

四つの検証段階

ページの実際の内容を表す型を選びます。Googleは対応形式の中でJSON-LDを推奨していますが、検索機能が文書化されている用途は一部です。混同しやすい検証を表で分けます。

段階検証する問い証明しないこと
JSON構文テキストを正しく解析できるか。事実の正確さ。
Schema.org語彙型とプロパティが適切か。Google検索機能での対応。
Google適格性対象の規則を満たすか。実際の検索表示。
実際の観測表示が確認されたか。常時表示や全クエリでの表示。

データをページと一致させる

  • 各プロパティを正確で可視かつ最新の情報に結び付けます。マークアップを埋めるためにレビュー、資格、価格を作りません。
  • 対象機能の必須プロパティと規則を確認します。Schema.orgに型が存在しても、Googleのリッチリザルト対応を自動的には意味しません。
  • エンティティ識別子をそろえ、複数コンポーネントの矛盾するブロックを防ぎます。言語版とURLも確認します。

表示を約束せず監視する

描画されたマークアップを検証し、Search Consoleの診断と実際の表示を追跡します。古い情報は可視コンテンツと一緒に更新します。テスト合格は順位、クリック、生成回答への採用を約束しません。

一次資料

データ変更後にJSON-LDを確認する

架空の例です。顧客や実際の観測結果を示すデータではありません。

表示価格は変わりましたが、別モジュールが作るJSON-LDには以前の価格が残っています。

  • 公開済みのページと各バリエーションを、表示価格および正当な業務データの出典と照合します。
  • 整合性を戻し、今後の変更も試験します。JSONの構文が正しくても、値が事実とは限りません。

一次資料:Google Search Central — General structured data guidelines. 関連する方法:実践ガイドを読む.