検索流入を伸ばしたいとき、構造化データはどうしても魅力的に映ります。検索結果の見え方が変わる可能性があり、真っ先に手を付けたくなるためです。ただ、現場で成果の差を分けるのは「JSON-LDの書き方」そのものではありません。差が出るのは、どのページに、どの型を、どの順番で載せるかです。ここが曖昧なまま生成ツールやCMS機能に頼ると、公開直後は問題なく見えても、30日後には崩れます。更新日だけが毎日動く、canonical と JSON-LD の URL がずれる、商品価格が画面と食い違う。こうした不一致は珍しくありません。
先に結論を示します。新規実装なら、最初に選ぶ形式は JSON-LD です。月間PVが10万未満のサイトなら、最初の対象は `Article`、`Product`、`BreadcrumbList` の三つに絞るべきでしょう。さらに、担当者の手書き運用で回そうとせず、テンプレートと入力項目を先に固める必要があります。Google の構造化データの概要、構造化データ ギャラリー、各型の公式ドキュメント、そして Schema.org を見比べると、実務ではこの順番がもっとも事故を減らします。以下、現場で迷いにくい判断基準として整理します。
新規実装でJSON-LDを最優先にすべき理由
新しく構造化データを入れるなら、JSON-LD を選ぶべきです。Microdata や RDFa まで並べて「どれも一長一短」とまとめる必要はありません。Google は 構造化データの概要 で複数形式を案内していますが、実装と保守のしやすさを考えると、実務で最初に採るべき形式は JSON-LD です。HTML の見た目と検索向けの記述を切り分けやすく、デザイン改修や本文更新の影響を受けにくいためです。
とくに、記事テンプレートを年に2回以上見直すサイト、更新担当が3名以上いるサイト、複数カテゴリにまたがって同じ型を配るサイトでは、この差がはっきり表れます。Microdata は画面側の HTML と密着するぶん、表示側の修正がそのまま構造化データの破損につながりやすい形式です。RDFa は既存資産との整合が必要な特別な事情がない限り、引き継ぎの負担が重くなります。新規導入なら、比較に時間をかけず JSON-LD に寄せるほうが現実的です。
形式 | 新規実装での推奨 | 向いている状況 | 避けたい状況 |
|---|---|---|---|
JSON-LD | 最優先で選ぶ | テンプレート運用、記事・商品・パンくずを横展開したい場合 | 画面にない情報まで書いてしまう運用 |
Microdata | 原則として新規採用は避ける | 既存HTMLに深く組み込まれており、数千ページが安定稼働している場合 | 更新担当が多い、UI改修が多い、複数テンプレートで使い回す場合 |
RDFa | 通常は選ばない | 外部仕様との厳密な整合が必要な限定ケース | 一般的な事業サイト、オウンドメディア、ECサイト |
例外はあります。すでに3,000ページ以上で Microdata が安定稼働し、年内にテンプレート刷新の予定がなく、開発余力も限られているなら、全面的な置き換えを急ぐ必要はありません。その場合は、主要テンプレートから段階的に JSON-LD へ移すほうが現実的です。ただし、新規カテゴリや新規ページまで旧形式で増やす判断は避けるべきです。保守方式が二重になり、半年後には確実に負債になります。
もう一つ大切なのは、Schema.org と Google の対応範囲を混同しないことです。Schema.org: Getting Started を見ると、Schema.org はあくまで共通語彙であり、JSON-LD はその表現形式の一つにすぎません。つまり、Schema.org に型があるから使うのではなく、Google が 構造化データ ギャラリー で扱う検索機能から逆算して選ぶべきです。語彙の豊富さより、検索で役立つ範囲に絞ること。これが最初の判断基準です。
ページ種別ごとに型の優先順位を実務で決める
JSON-LD の失敗は、書式ミスより型選びで起こります。現場では「載せられるものは全部載せたい」と考えがちですが、その発想は危険です。月間PV10万未満のサイトで、`FAQPage`、`Review`、`HowTo` を一気に広げるより、まず `Article`、`Product`、`BreadcrumbList` の整合を固めたほうが成果につながります。型を増やす前に、主要ページの基本情報を正しく出せているかを確認してください。
まず見るべき資料は 構造化データ ギャラリー です。そこで「このページはどの検索機能の対象になり得るか」を確認し、その後で Article 構造化データ、Product 構造化データ、パンくずリスト構造化データ、Organization 構造化データ の各要件を当てていく。この順番を逆にすると、型の数だけ増えて運用だけが重くなります。
実務での優先順位は、次の表で切り分けると迷いません。
ページの役割 | 最初に入れる型 | 推奨する条件 | 後回しにしてよい型 |
|---|---|---|---|
記事で集客するページ | `Article` または `BlogPosting` | 公開日、更新日、著者、画像をCMSで管理できる | FAQ、レビュー、HowTo |
商品詳細ページ | `Product` | 商品名、価格、在庫、画像、URL が画面と一致している | 集計評価、複数オファーの細分化 |
事業紹介やサービス案内のページ群 | `BreadcrumbList`、必要に応じて `Organization` | パンくずが実際に表示され、サイト構造が安定している | 関係の薄い型の重ね書き |
FAQ専用ページ | `FAQPage` | 1ページ内に3問以上の質問と回答が表示され、更新責任者が明確 | 記事ページへの安易な横展開 |
レビュー掲載ページ | `Review` またはレビュー系プロパティ | 画面上で実レビューを継続表示できる | 見せていない評価のマークアップ |
ここで強く勧めたいのは、最初の30日で「使う型を三つ以内に絞る」ことです。月間PV10万未満で記事中心のメディアなら `Article` と `BreadcrumbList` だけでも十分です。商品点数が300を超えるECなら、`Product` の主要項目に集中してください。FAQ やレビューは、実際に表示される情報を保守できる運用が整ってからでも遅くありません。FAQPage 構造化データ や レビュー スニペット は便利ですが、表示内容と一致しなければすぐに崩れます。
判断に迷ったら、「そのページの主役は何か」で切り分けるのが安全です。主役が記事なら `Article` を中心に組み、商品なら `Product` を中心に組む。複数の型を載せる場合も、補助役にとどめるのが無難です。たとえば記事ページに `Article` と `BreadcrumbList` を併記するのは自然ですが、そこへ無関係な `Product` や不完全な FAQ を重ねる必要はありません。1ページ1主役。この原則を崩さないほうが、あとで直しやすい設計になります。
Schema.org の語彙と Google の運用差分は、Schema.org と Google 対応のずれを整理した記事 でも触れています。型をきれいに並べることより、「検索結果で評価される導線に沿っているか」を優先すること。その視点を持つだけで、JSON-LD の実装はかなり進めやすくなります。
手書きより先にテンプレート設計を実務で固める
型が決まったら、次は「誰が何を更新したときに JSON-LD が動くか」を決めます。ここでの推奨は明快です。JSON-LD は手書きで頑張るより、テンプレート化して運用すべきです。担当者が記事編集画面に自由入力する方式は避けてください。最初は柔軟に見えても、更新担当が増えるほど表記ゆれと未入力が増え、半年以内に品質が揺らぎます。
先に決めるべき項目は多くありません。記事ページなら、少なくとも次の六つは入力元を固定したいところです。
- `headline` はページ見出しと同じ値を使うのか
- `datePublished` と `dateModified` はどの更新イベントで変わるのか
- `image` は OGP 画像と共通にするのか、記事専用画像を持つのか
- `author` は個人名なのか編集部名義なのか
- `mainEntityOfPage` と canonical URL は同じ生成関数から出すのか
- パンくずの名称と URL は画面表示と同じデータから出すのか
この六つが曖昧なまま実装を始めると、公開後の修正依頼が増えます。とくに `dateModified` は注意が必要です。CMS の保存時刻をそのまま使うと、本文が変わっていないのに日付だけ更新されます。軽微なレイアウト修正や内部設定の変更まで更新日として出る設計は避けるべきです。内容改訂と見なせる更新だけで動かすルールを先に決めてください。
実装方法の選び方も整理しておきます。
実装方法 | 推奨度 | 向いている場面 | 主な注意点 |
|---|---|---|---|
手書きで各ページに埋め込む | 低い | 10ページ未満の検証用ページ | 人が増えるとすぐに崩れる |
CMSプラグインだけで出す | 中程度 | 小規模サイトの初期導入 | 重複出力、柔軟性不足、画面との不一致に注意 |
アプリケーション側のテンプレートで出す | 高い | 継続運用する記事サイト、EC、事業サイト | 初期設計は必要だが、長期運用で最も安定する |
表示データと共通のデータ源から生成する | 最優先 | 主要テンプレートすべて | 実装コストはかかるが事故が最も少ない |
記事ページなら、Article 構造化データ の推奨項目を確認し、必要な項目を定義して、見える情報だけを出すのが基本です。商品ページなら Product 構造化データ を基準に、価格、在庫、画像、URL が画面と一致するかを先に見てください。パンくずは パンくずリスト構造化データ に沿って、表示用と同じ配列を使えば十分です。別のデータ源を持つ必要はありません。
たとえば記事ページの骨組みは、次の程度に留めるほうが安全です。
```html <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Article", "headline": "JSON-LDの書き方を実務で整理 実装で迷わない7つの判断基準", "datePublished": "2026-04-18", "dateModified": "2026-04-18", "author": { "@type": "Organization", "name": "JPSM SEO 編集事業部" }, "image": ["https://example.com/images/json-ld-guide.jpg"], "mainEntityOfPage": "https://example.com/seo/blog/json-ld-practical-guide" } </script> ```
ここで大事なのは、コードの長さではなく入力元の一貫性です。見出し、URL、画像、更新日を別々の管理画面や別々の担当者に持たせると、どこかで必ず食い違います。canonical の整理が曖昧なら、先に canonical タグの判断基準を整理した記事 を読み、URL の正本を一本化してください。JSON-LD は URL 設計が固まってから書くべきです。
公開前に必ず通す検証手順を実装前に固定する
JSON-LD は「書けたかどうか」より、「公開前に何を確認したか」で品質が決まります。ここは断言できます。生成ツールや CMS の補助機能は下書きとしては便利ですが、最終判断まで任せるべきではありません。構文を整えることはできても、画面表示との一致、canonical との整合、重複出力までは保証してくれないためです。
公開前の検証では、Google のリッチリザルト テスト と Schema.org Validator を必ず併用してください。役割が違うため、片方だけでは足りません。前者は Google 検索で扱う対象として読めるかを確認する道具です。後者は Schema.org の語彙として破綻していないかを見るのに向いています。二つを通して初めて、「Google 向けの解釈」と「語彙としての整合」の両方を確認できます。
検証サンプル数も、規模ごとに決め打ちしたほうが運用しやすくなります。
- 月間PV10万未満なら、型ごとに5 URLを確認する
- 月間PV10万以上100万未満なら、テンプレートごとに10〜20 URLを確認する
- 月間PV100万超なら、主要テンプレートごとに30〜50 URLを抽出する
- 商品点数1,000超のECなら、価格改定が入る商品を必ず含めて毎回20 URL以上確認する
公開前の実務チェックは、次の順番に固定しておくと迷いません。
- ページ上に表示されているタイトル、画像、著者、価格、パンくずを一覧化する
- `view-source` かレンダリング後 HTML で JSON-LD が一つだけ出ているか確認する
- リッチリザルト テスト で対象型として認識されるか確認する
- Schema.org Validator で語彙や階層の不整合がないか確認する
- canonical URL と JSON-LD 内の URL が一致しているか確認する
- 代表画像 URL がクロール可能で、実ページに紐づく画像か確認する
- パンくずの名称と URL が画面表示と一致しているか確認する
- 公開後3日、7日、14日の再確認予定を先に決める
ここで見落としがちな点は、「エラーがない」ことと「成果につながる」ことは別だということです。ツールを通っても、ページ内容が薄い、価格や在庫が古い、更新日が不自然、画像が本文と無関係なら、構造化データだけで評価は上がりません。リッチリザルトの可否だけを追うより、ページの主情報と JSON-LD がずれていないかを見るほうが重要です。
検証を編集フローに組み込むなら、リリース前チェックシートを1枚にまとめることを勧めます。JPSM SEO 編集事業部でも、構造化データの相談は実装そのものより「公開前の確認が属人化している」ことが原因になっているケースが多くあります。人が変わっても同じ順番で確認できる状態にしておくことが、結局いちばん安定します。
公開後に崩れやすい運用ミスを先回りで防ぐ
JSON-LD は公開日当日より、公開後2週間から2か月の間に崩れやすい施策です。理由は単純で、記事更新、商品更新、テンプレート改修、計測追加、URL 変更が別々に動くからです。したがって、JSON-LD を SEO 担当者だけの管理対象にしてはいけません。本文更新や商品更新の流れの中に組み込むべきです。
現場で頻発する失敗は、おおむね次の六つに集約されます。
- 画面に表示していない情報を JSON-LD にだけ書く
- `dateModified` が CMS 保存のたびに更新される
- パンくずの旧カテゴリ名が残る
- canonical URL と JSON-LD の URL が食い違う
- 著者と事業組織の役割が混ざる
- 複数のプラグインや機能が同じ型を重複出力する
この中でも最優先で防ぐべきなのは、画面と JSON-LD の不一致です。たとえば、商品ページでレビュー評価を画面から外したのに `aggregateRating` だけが残る、記事ページで編集部名義に変えたのに個人著者の JSON-LD が残る。こうした不整合はすぐに起きます。対策は単純です。表示と同じデータ源から JSON-LD を生成すること。別管理にしないこと。これができていれば、破損の大半は未然に防げます。
次に気を付けたいのが更新日の扱いです。更新日を毎日動かしても、読者にも検索エンジンにも信頼は積み上がりません。本文、見出し、画像、監修情報など、実質的な改訂があった場合にだけ変える運用へ寄せるべきです。記事本数が月20本未満のメディアなら、編集部の確認を入れた手動運用でも十分回せます。逆に月100本を超えるなら、改訂フラグ付きの自動更新にし、単なる保存では日付を動かさない設計が必要です。
EC はさらに厳密に見る必要があります。商品点数が1,000を超える場合、価格・在庫・画像のどれか一つでも日次更新があるなら、`Product` を深く書く前に更新連携を安定させてください。表示価格と JSON-LD の価格が1日ずれるだけで、信頼を損ないます。商品ページの考え方は EC サイトの商品ページ SEO を整理した記事 ともつながりますが、構造化データだけを先に広げるのは順番が逆です。まず商品情報そのものの鮮度を保つこと。その次に JSON-LD があります。
重複出力も見逃せません。とくに CMS で SEO 機能、FAQ 機能、EC 機能が別々に構造化データを吐く環境では、同じ `Product` や `BreadcrumbList` が二重三重に並ぶことがあります。この状態を放置すると、誰が正しいデータを出しているのか分からなくなります。出力責任は一つに寄せてください。記事なら記事テンプレート、商品なら商品テンプレート、事業組織情報なら共通レイアウト。責任の置き場が明確な設計ほど修正も早くなります。
規模別に変える実装体制と投資配分の決め方
同じ JSON-LD でも、月間PV、ページ種類、更新頻度で打ち手は変わります。ここが曖昧だと、小規模サイトで過剰投資になり、大規模サイトでは検証不足になります。実務では、少なくとも次の四つの場面に分けて考えるべきです。
記事中心で月間PV10万未満のサイトなら、型を絞るべきです。 この規模で優先すべきは `Article` と `BreadcrumbList`、商品があるなら `Product` の主要項目までです。FAQ やレビューを急いで増やす必要はありません。担当者が1〜2名なら、最初の目標は「5 URL を安定して通すこと」です。100点満点の設計より、毎月崩れない設計のほうが価値があります。
複数カテゴリを持ち、月間PV10万〜100万のサイトなら、入力ルールを先に固めるべきです。 この規模では、型の優先順位だけでは足りません。SEO、編集、開発の役割分担を明確にし、入力項目の定義書を作ってください。新しいテンプレートを追加するたびに検証を回し、月次で20 URL前後を抜き打ち確認する。この運用がないと、カテゴリ追加のたびに JSON-LD の質が落ちます。
商品点数1,000超のECなら、`Product` を深く書く前に更新連携へ投資すべきです。 価格、在庫、画像のどれかが日次で変わるなら、`aggregateRating` や複数オファーを先に増やすべきではありません。まず商品名、価格、在庫、URL、画像の五つを画面と一致させること。これが30日連続で崩れないと確認できてから、追加プロパティへ進んだほうが安全です。
月間PV100万超でテンプレートが20種類以上あるなら、JSON-LD を個別施策として扱うべきではありません。 この規模では、URL、タイトル、画像、価格、著者情報を共通データとして管理し、テンプレート単位で自動確認を入れる必要があります。人手の目視だけで回すのは現実的ではありません。検索向けの補助施策ではなく、データ設計の一部として扱うほうがうまくいきます。
この四つをまとめると、判断基準はシンプルです。小規模は型を絞る。中規模は入力ルールを固める。EC は更新連携を先に整える。大規模は共通データとして管理する。規模に合わない打ち手を避けるだけで、実装コストと事故率は大きく下がります。
最初の三十日で終える実行計画を現実的に組む
JSON-LD の導入は、長い計画書を作るより30日で骨格を作ったほうが前に進みます。最初の1か月でやるべきことは多くありません。優先順位を守れば十分です。
1週目は対象ページを絞ります。 記事、商品、事業紹介ページのどれを対象にするかを決め、使う型を三つ以内に限定してください。そのうえで 構造化データ ギャラリー を見て、どの検索機能に該当するかを確認します。この段階で「あとで使うかもしれない型」は、いったん捨てるべきです。
2週目は入力元を固定します。 タイトル、公開日、更新日、画像、URL、パンくず、著者の入力元を一覧にし、画面表示と同じデータ源から JSON-LD を出す設計にそろえます。テンプレートに落とし込めない項目があるなら、その型はまだ実装時期ではありません。運用で守れない型は、入れないほうが安全です。
3週目は検証を回します。 型ごとに5〜20 URLを抜き、リッチリザルト テスト と Schema.org Validator の両方で確認します。エラーを消すだけで終えず、画面と JSON-LD の一致、canonical の整合、画像の関連性まで見てください。ここを雑に通すと、公開後の修正が増えます。
4週目は運用へ組み込みます。 編集担当、商品担当、開発担当の誰が何を確認するかを一枚の手順書にまとめ、公開後7日と14日に再確認する予定を入れます。JPSM SEO 編集事業部へご相談いただく案件でも、この一枚がある現場ほど改善が定着しやすい印象があります。派手な追加型より、壊れない確認手順のほうが長く効きます。
最後に、今日やるべきことを三つに絞ります。
- 対象ページを三種類以内に絞る。
- `Article`、`Product`、`BreadcrumbList` のどれを先に入れるか決める。
- 5 URL を選び、公開前の検証手順を一度最後まで通す。
JSON-LD は量を書く施策ではなく、順番を外さない施策です。まずはこの三つを今週中に終え、増やすのはその後にしてください。