Wemiro
ログインお問い合わせする
目次を見る07

JSON-LDとMicrodataの違い｜どちらで書くかの判断基準

Wemiro編集部読了目安 11分
構造化データ技術SEOリッチリザルト

新しく書くならJSON-LD。既存のMicrodataは急いで消さなくてよい

構造化データを足そうとして、手が止まる。テーマはMicrodataを出している。解説記事はJSON-LDを勧めている。どちらに揃えるべきか分からない。

答えを先に書きます。これから新しく書く分はJSON-LDで書きます。すでに動いているMicrodataは、問題が出ていなければ残してかまいません。 判断を分けるのは形式の優劣ではありません。「誰が、どこで、その記述を保守するか」です。

Google 検索セントラルは、サポートする形式について次のように書いています。

一般的に、Google は実装と管理が最も容易な形式（ほとんどの場合は JSON-LD）を推奨します。

推奨の理由として挙がっているのは「実装と管理が容易」という点です。つまり勧められているのは、保守のしやすさです。

3つの形式は、何が違うのか

構造化データ（ページの内容を検索エンジンに機械が読める形で伝える記述）には、Google がサポートする書き方が3つあります。一般的なガイドラインの要約にも、サポートされる形式として JSON-LD、Microdata、RDFa が並んでいます。

違いは「どこに書くか」です。

形式書く場所保守の単位つまずきやすい点
JSON-LD<script type="application/ld+json"> の中にまとめて書く1ブロックJavaScriptで後から挿入すると、HTMLソースを見ても見つからない
Microdata表示中のHTMLタグに itemscope や itemprop の属性として埋め込む表示テンプレートと一体デザイン変更でタグを動かすと、構造化データも一緒に壊れる
RDFaHTMLタグに property などの属性として埋め込む表示テンプレートと一体実務で新規に選ぶ場面は少ない

同じパンくずリストを2つの形式で書くと、差がはっきりします。まずMicrodataです。

<ol itemscope itemtype="https://schema.org/BreadcrumbList">
  <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
    <a itemprop="item" href="https://example.com/shop/"><span itemprop="name">商品一覧</span></a>
    <meta itemprop="position" content="1">
  </li>
</ol>

次にJSON-LDです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [{
    "@type": "ListItem",
    "position": 1,
    "name": "商品一覧",
    "item": "https://example.com/shop/"
  }]
}
</script>

Microdataは、見た目のHTMLと構造化データが同じタグに同居しています。デザイナーがリストのマークアップを組み替えれば、属性も巻き込まれます。JSON-LDは表示と切り離されています。だから、どちらか片方だけを直せます。

公式が「管理が容易」と書く理由は、実装の現場ではこの分離のことだと読めます。

形式より先に見られるもの

形式を選んだあとも、それだけでは十分ではありません。一般的なガイドラインの要約は、リッチリザルト（検索結果に追加情報が表示される見た目）の対象になるための主な行動として、次を挙げています。

  • サポートされている形式（JSON-LD、Microdata、RDFa）を使う
  • データがページの内容を正確に表している
  • 完全で最新の情報を提供する
  • Googlebot のアクセスをブロックしない

この並びでは、形式の選択は条件の1つにすぎません。残りは、どの形式で書いても同じように問われます。

仕組みの概要ページも、同じ方向のことを書いています。

ガイドラインに準拠しない構造化データは、Google 検索でリッチリザルトとして表示されない場合があります。

さらに、プロパティの埋め方についても次のように述べています。

完全でないデータ、不正な形式のデータ、不正確なデータを含む多数の推奨プロパティを提供するより、少数であっても完全で正確な推奨プロパティを提供するほうが重要です。

形式をJSON-LDに移しても、中身が不正確なら意味がありません。逆に、正確なMicrodataを無理に書き換えても、得られるのは保守のしやすさです。形式を変えただけで表示や評価が良くなる、と期待するのは避けたほうが安全です。

よくある誤解：「混ざっていたら全部JSON-LDに揃えるべき」

テーマがパンくずをMicrodataで出している。そこに、記事情報をJSON-LDで足した。形式が混ざっていて気持ちが悪い——ここで一括移行に走る人は多いです。

ただ、Microdataの属性を一括で消すと、表示テンプレートに手を入れることになります。HTMLの崩れやテーマ更新時の上書きといった、SEOとは別の事故が起きることがあります。

本当に避けたいのは、形式の混在そのものより、同じ対象を2か所で書くことです。パンくずをMicrodataとJSON-LDの両方で書くと、管理する場所が2つになります。片方だけ更新されれば、2つの記述の内容が食い違います。ガイドラインが求めるのは「ページの内容を正確に表している」ことでした。食い違った2つの記述は、少なくとも一方がこの条件から外れやすくなります。

整理すると、次のように分けて考えられます。

  • 対象ごとに形式が分かれている（パンくず=Microdata、記事情報=JSON-LD）: 急いで直す理由は薄い
  • 同じ対象が2形式で重複している（パンくずが両方にある）: どちらか1つに寄せる

移行するかどうかの判断ツリー

自社サイトに当てはめるときは、上から順に答えていきます。

  1. その対象（パンくず、商品、記事など）は、2つの形式で重複して書かれていますか。 はいなら、保守する側を1つ決めてもう片方を外します。いいえなら次へ。
  2. Microdataを出しているのは、自社で編集できないテーマやカートASPですか。 はいなら、そのまま残します。書き換えの工数に見合う利点は薄く、テーマ更新で元に戻ることもあります。いいえなら次へ。
  3. そのテンプレートは、近いうちにデザイン改修の予定がありますか。 はいなら、改修のついでにJSON-LDへ移すと、以後の表示変更で構造化データが壊れにくくなります。いいえなら次へ。
  4. いまのMicrodataで、Search Consoleにエラーが出ていますか。 はいなら、直すついでにJSON-LDで書き直す価値があります。いいえなら、現状維持で問題が出にくいと考えられます。
  5. これから新しく足す対象ですか。 はいなら、JSON-LDで書きます。

JavaScriptでの挿入も選択肢に入ります。JavaScript で構造化データを生成するページの要約には、Google タグマネージャー（GTM）やカスタム JavaScript を使う方法が挙がっています。テンプレートを触れない環境でも、JSON-LDを足す経路はあるわけです。

ワークスルー：カートASPの商品ページにパンくずを足す

具体例に1回通します。条件はこうです。

  • ネットショップの商品ページ。カートASPのテーマが、商品情報をMicrodataで出力している
  • テーマのHTMLは編集できない。<head> へのタグ追加とGTMは使える
  • パンくずリストの構造化データを新しく足したい

1. いまの形式をソースで確かめる

まず、サーバーが返すHTMLに何が含まれるかを数えます。

curl -sL https://example.com/items/123 | grep -o 'itemtype="https://schema.org/[A-Za-z]*"' | sort | uniq -c
curl -sL https://example.com/items/123 | grep -c 'application/ld+json'

1行目で Product と Offer が出て、BreadcrumbList は出ない。2行目は 0。これで「商品はMicrodata、パンくずは未実装、JSON-LDは無し」と分かります。

ここに落とし穴があります。GTMで挿入したJSON-LDは、このcurlの結果には出てきません。 GTMはブラウザでJavaScriptが動いてから書き込むからです。GTMを使っているサイトでは、ブラウザの開発者ツールで、読み込み後のDOMに application/ld+json があるかも確かめます。

2. 対象ごとに表へ書き出す

対象MicrodataJSON-LD判定
商品（Product）あり（テーマが出力）なし重複なし・編集不可 → 残す
パンくず（BreadcrumbList）なしなし新規 → JSON-LDで足す

ここで判断ツリーの2番が効きます。商品のMicrodataは、テーマが出していて編集できません。だから残します。パンくずは5番に当たります。

3. パンくずだけJSON-LDで足す

前述のJSON-LDを、実際のカテゴリ構造に合わせて書きます。ページに表示しているパンくずと、項目名もURLも一致させます。表示と違う階層を書けば、ガイドラインの「ページの内容を正確に表している」から外れます。

4. 公開後に重複と食い違いを点検する

公開したら、手順1のコマンドとブラウザでの確認をもう一度行います。見るのは2点です。BreadcrumbList が1つだけあるか。表示中のパンくずと中身が一致しているか。

テーマの更新でパンくずのMicrodataが後から追加されることもあります。そのときは、JSON-LDとの重複に気づいた時点でどちらかに寄せます。

このケースの結論は「商品=Microdata、パンくず=JSON-LD」の混在です。それで問題ありません。重複がないからです。

自己点検チェックリスト

自社サイトで、次を1つずつ確かめます。

  • 主要テンプレートごとに、構造化データの形式（JSON-LD / Microdata）を把握している
  • 同じ対象が2つの形式で重複していない
  • 構造化データの内容が、ページに表示している内容と一致している
  • GTMなどJavaScriptで挿入している場合、読み込み後のDOMで確認している
  • 新規に足す構造化データはJSON-LDで書く、と実装ルールに書いてある
  • 編集できないテーマ由来のMicrodataは、エラーが出ていない限り残す方針にしている

1つめと2つめが埋まれば、移行するかどうかの判断はほぼ終わっています。

Search Console にエラーや警告が出ていて、どれから直すか迷っているなら、構造化データのエラーと警告｜直す順番の決め方で優先順位を決められます。

出典

  1. Google 検索セントラル - 構造化データの仕組みについて
  2. Google 検索セントラル - 構造化データの一般的なガイドライン
  3. Google 検索セントラル - JavaScript を使用して構造化データを生成する

NEXT STEP

クライアントへの説明に使える実際の画面を見てみませんか

ご自身の目で、GA4・Search Consoleのデータがどう整理されるかを確認いただけます。

無料デモを見てみる
ブログ一覧に戻る