JSON-LD vs Microdata、構造化データはどの形式で入れるべきでしょうか？
JSON-LDは別途scriptブロックに接続データを表現する形式であり、Microdataは表示されるHTML要素にitempropのような属性を付けてschema.org語彙を表現する形式です。
3行要約
JSON-LDとMicrodataは同じschema.orgの概念を異なる方法で表現するもので、Googleは対応する検索機能ではJSON-LDを推奨しています。
形式よりも、表示される本文とmarkupの内容が一致しているか、必須属性やページポリシーを守っているかが重要です。
既存サイトでは、安定して生成・検証できるどちらか一方の形式を基準にし、重複出力や古い値を削除すれば十分です。
JSON-LDとMicrodataは何が違いますか？
JSON-LDは別個のscriptブロックに関連データを表現する形式で、Microdataは表示されるHTML要素にitempropのような属性を付けてschema.orgの語彙を表現する形式です。名前が一緒に挙がっても目的と処理段階が異なるため、1つの設定や指標として置き換えて使うことはできません。
まず、どの検索機能とページタイプをサポートしたいのかを確認します。構造化データは多ければ多いほど良いわけではなく、Googleのドキュメントでサポートされていないタイプを入れても特別な表示は生まれません。
比較基準 | JSON-LD | Microdata |
|---|---|---|
挿入方法 | scriptブロックに関連データを表現 | HTML要素に属性を直接付与 |
本文との結合 | レイアウトと比較的分離 | 表示要素と強く結合 |
保守性 | テンプレート・データ層で管理しやすい | マークアップ修正時に合わせて変更 |
ネスト関係 | @idとオブジェクトで関係を表現 | DOMのネスト構造の影響を受ける |
主なリスク | 本文と異なる値を別途生成 | 属性の欠落・複雑なHTMLの結合 |
JSON-LDとMicrodataの違い
現在のページの本文の事実、JSON-LD、Microdataが互いに異なっていないかを確認します。以前のプラグインと新しいタグマネージャーが同じOrganization・Productを重複出力するケースはよくあります。
現在の状態は管理者のチェックボックスだけでは判定しません。JSON-LDとMicrodataが適用された実際のURLで保守とネスト関係を確認し、公開時点と外部反映時点を分けて記録しなければ、時間差をエラーと誤認しません。
実運用ではどう分けるのでしょうか？
JSON-LDはCMSのソースフィールドから生成し、@id、URL、名前、価格・在庫が表示本文と一致するように維持します。クライアント挿入であれば、レンダリング結果とエラー状況を確認します。
Microdataは実際に表示される要素と一緒に維持されますが、テンプレート改修時に属性が抜けることがあります。コンポーネントテストと検索機能別Rich Results Testをリリースに組み込みます。
比較基準 | JSON-LD | Microdata |
|---|---|---|
Organization | 公式の会社フィールドを1つのオブジェクトとして管理 | 会社本文要素に属性を付与 |
Product | 商品データの元データと連携 | 価格・在庫のDOMと直接連携 |
Article | CMSメタデータから一貫して生成 | タイトル・著者要素に表現 |
複雑な関係 | @idで再利用・連携しやすい | ネストされたDOMの管理が複雑になる場合がある |
誤って適用したときに生じる問題
JSON-LDが便利だからといって、ページに表示されないレビュー・価格を入れると、ポリシーと事実が食い違います。Microdataが本文に付いているからといって、自動的に正確とは限りません。
2つの形式を同時に維持すると、同じエンティティの値と識別子が分かれてしまう可能性があります。前の期間に並行運用する場合でも、基準となる原本と削除日を定めます。
既存のウェブサイトでは何から変更しますか？
上位テンプレートの構造化データを抽出し、タイプ、id、主要属性、重複を表にまとめます。本文と合わない値を先に削除し、実際の検索機能に必要なタイプだけを残します。
サイト移行をせず、現在のCMSまたはタグ階層で修正します。形式変更は、保守とQAがシンプルになった時点で進め、URL・本文・検索機能を変更する作業とは分けます。
JSON-LDとMicrodataを修正した後は、文言を読むだけで終わらせません。ネストされた関係と主要リスクが実際の公開URLと結び付いているかを確認し、canonical、内部リンク、sitemapのような代表URLを決めるシグナルが、別々のページを指していないかも確認します。
成果確認の基準
有効性エラー、本文不一致、重複オブジェクト、テンプレートcoverageを確認します。Search Consoleの検索表示レポートは、適格性と実際の表示を分けて読みます。
正しいmarkupでも、検索機能の表示や順位を決めるものではありません。配信成功、Google処理、実際の検索表示を別々の状態として記録します。
一度うまく表示された画面は、JSON-LDやMicrodataの成果証拠としては不十分です。保守とネスト関係、確認日を保管したうえで、同じ条件で再現されるかを見て、はじめて実際の改善と判断できます。
公開前後には何を記録しますか？
公開前には、JSON-LDとMicrodataの比較根拠、主要リスクと挿入方法、確認日と担当者を残します。出典が示す範囲と本文の主張が一致しているかを読み、モバイル画面で表と内部リンクが切れていないかも確認します。
公開後には、JSON-LDとMicrodataが公開された事実と、検索・AIシステムに反映された事実を分けて記録します。挿入方法と本文結合の確認日を別々に残し、失敗した場合はページを増やす前に同じURLで原因を絞り込みます。
JSON-LDとMicrodataの並行運用における実際の判断
JSON-LDとMicrodataのどちらかを先に選ぶより、挿入方法、本文結合、保守項目の基準値を作ります。この値がなければ、変更前後を比較できず、担当者が変わるたびに同じ診断を繰り返します。影響の大きいURLと質問を少数選び、誰がどの値をいつ修正したかを残します。
JSON-LDとMicrodataのネスト関係の項目も、全体平均だけでは見ません。新しく修正したページ、変更しないページ、季節性の影響を受けるページを分けてこそ、差が見えてきます。結果が予想と異なる場合は、新しいページを増やす前に、原文不足、技術的ブロック、外部情報、測定の空白を確認します。
参考資料
検索結果の構成をさらに確認するには
この運用方式では、どのように継続して運用しますか？
SEO記録には、JSON-LDとMicrodataの保守が表示・クリックに与えた影響を記録します。GEO記録には、主なリスクがAI回答での言及・引用と結びついた場面を別途残し、2つの結果を無理に統合しません。
現在のWebサイトの上にこの運用方式を接続すると、JSON-LDとMicrodataの本文結合と保守を同じ質問群で追跡できます。サイト移転なしで基準URLと公開結果を照合し、コンテンツ・技術・外部情報のうち原因のある層だけを修正します。
JSON-LDとMicrodataの再検証には、最初と同じ質問・URLを使います。保守と重複関係の変化が再現されるまではサイト構造を大きく変えず、現在の環境で次の小さな修正を続けます。
JSON-LDとMicrodata比較後のSearch OS運用
Search OSを適用してJSON-LDとMicrodataの比較を始めても、Webサイトを新しく作る必要はありません。既存のドメインとCMSを維持したまま、保守・重複関係項目を検索結果、AI回答と引用URLにつなげ、実際のボトルネックだけを修正します。
Search OS内部の成果集計では、導入クライアント企業のSEOとAI検索露出が平均88%以上増加しました。JSON-LDとMicrodata関連URLも同じ質問で繰り返し測定し、改善幅が縮小したり新しいエラーが発生した区間を見つけます。一度きりの診断で終わらせず、現在のサイトが生み出せる最良の検索・AI露出状態を維持できるよう運用します。