JSON-LDの書き方｜どの型を使い、どう検証するか
三橋竜彰・
JSON-LDを書くときに最初に決めるのは、どの型（スキーマ）を使うかです。書式そのものは難しくありません。つまずくのは型の選択と、書いたあとに壊れていないかを確かめる工程のほうです。
運営者はSEO検定1級・ウェブ解析士として、AIでサイト設計から記事作成・公開・分析までを自動化する仕組みを自作し、複数の自社サイトで運用しています。本サイトの構造化データもその仕組みで出力しているので、実装側の視点で整理します。
JSON-LDとは何を書くものですか？
ページの内容を、機械が読める形で説明したものです。人が読む本文とは別に、<script type="application/ld+json"> の中へJSON形式で置きます。
目的はリッチリザルトを出すことではなく、機械可読性です。検索結果に装飾が出るかどうかは検索エンジン側の判断で変わりますが、機械が内容を正しく解釈できる状態にしておくこと自体には、それとは別の意味があります。AIが本文を参照する場面が増えている現在はなおさらです。
どの型を使えばいいですか？
ページの種類で決まります。迷いやすい4つを挙げます。
| 型 | 使う場面 | 補足 |
|---|---|---|
| Article / BlogPosting | 記事ページ | 著者・公開日・更新日を持たせる |
| BreadcrumbList | 階層のあるページ | カテゴリ→記事の経路を示す |
| FAQPage | 本文に質問と回答があるページ | 本文に見えている内容と一致させる |
| Organization | サイト全体 | 通常はトップまたは共通レイアウトに1つ |
原則は、そのページに実際にあるものだけを書くことです。本文に無いFAQをFAQPageに書く、存在しない著者をArticleに書く、といった実装は、機械可読性を上げるどころか信頼を損ないます。
FAQPageは、可視のQ&Aと構造化データの文言を逐語で一致させてください。片方だけ直して食い違ったまま残る事故が、実際によく起きます。
なお HowTo型は使っていません。Googleが手順のリッチリザルトを2023年に廃止しており、実装のリターンが見込めないためです。手順は見出しと番号付きリストという可視の形で表現しています。
どこに置きますか？
<head> でも <body> でも動作します。重要なのは置き場所より、1ページに同じ型を重複させないことです。
- Organization はサイト共通のレイアウトに1つ
- Article と BreadcrumbList は各ページに1つずつ
- FAQPage はQ&Aを持つページにだけ、1つ
同じ型が2つあると、どちらが正なのか機械に判断させることになります。テンプレートとプラグインの両方が出力していて二重になっている、というのはよくある構成ミスです。
書いたあと、どう検証しますか？
書きっぱなしにしないことが最も重要です。 検証は3段階で行っています。
- JSONとして壊れていないか：末尾のカンマや全角引用符が混ざると、その1ページ分がまるごと無効になります
- 語彙として正しいか：型名やプロパティ名の綴り、必須項目の有無を確認します
- 本番のHTMLに実際に出ているか：ローカルで書けていても、ビルドや配信の途中で欠けることがあります
3つ目が抜けやすいところです。本サイトでは、公開後に本番のHTMLを取得して構造化データが含まれているかを機械で確認する工程を持っています。ローカルで正しいことと、本番に出ていることは別の事実です。
更新のときに壊れやすい場所
一度書いた構造化データは、本文を直したときに置き去りになります。とくに次の2つです。
- FAQPage：本文のQ&Aを書き換えたのに、構造化データが旧文言のまま残る
- dateModified：本文を更新したのに日付が公開時のまま
どちらも「本文を直したら構造化データも直す」を工程として決めておかないと、時間とともにずれていきます。本サイトでは記事の元データから両方を生成しているため、原理的にずれない形にしています。
著者や組織を機械に伝える書き方
Person や Organization を使って「誰が書いたのか」「どの組織なのか」を示す実装は、同じ人物・組織であることを機械に認識させる話につながります。識別子の揃え方と sameAs の使い方はエンティティSEOとは｜AIに「同じ人・同じ組織」と認識させる実装で、本サイトの実際の記述を出して扱っています。
AI向けの対応として構造化データをどう位置づけるかはLLMO対策のやり方【実測データ付き】に、機械向けの別の入口である llms.txt についてはllms.txtとは？書き方と設置方法にまとめました。
よくある質問
JSON-LDはheadとbodyのどちらに置くべきですか？
どちらでも動作します。置き場所より、1ページに同じ型を重複させないことのほうが重要です。テンプレートとプラグインの両方が出力して二重になっている構成ミスは珍しくありません。Organizationはサイト共通のレイアウトに1つ、ArticleとBreadcrumbListは各ページに1つずつが基本です。
どの型を使えばいいか分かりません。
ページの種類で決まります。記事ページはArticleまたはBlogPosting、階層のあるページはBreadcrumbList、本文に質問と回答があるページはFAQPage、サイト全体の情報はOrganizationです。原則は、そのページに実際にあるものだけを書くことです。本文に無いFAQを書くような実装は避けてください。
JSON-LDを書けば検索結果に装飾が出ますか？
出るとは限りません。リッチリザルトの表示は検索エンジン側の判断で変わり、型によっては表示自体が廃止されています。実装の目的は装飾ではなく機械可読性です。AIが本文を参照する場面が増えている現在は、正しく解釈できる状態にしておくこと自体に意味があります。
書いたJSON-LDが正しいかどうかはどう確かめますか？
3段階で確認します。JSONとして壊れていないか（末尾のカンマや全角引用符に注意）、型名やプロパティの綴りが語彙として正しいか、そして本番のHTMLに実際に出ているかです。3つ目が抜けやすく、ローカルで書けていてもビルドや配信の途中で欠けることがあります。
本文を更新したとき構造化データも直す必要がありますか？
あります。とくにFAQPageの文言と、更新日を示すdateModifiedが置き去りになりがちです。本文のQ&Aを書き換えたのに構造化データが旧文言のまま残ると、可視の内容と食い違います。本文と構造化データを同じ元データから生成する形にすると、原理的にずれなくなります。
まとめ
JSON-LDで難しいのは書式ではなく、型の選択と検証です。ページの種類に応じてArticle・BreadcrumbList・FAQPage・Organizationを選び、そのページに実際にあるものだけを書きます。
書いたあとは、JSONとして壊れていないか・語彙として正しいか・本番のHTMLに出ているかの3つを確認してください。3つ目が抜けると、書けているつもりのまま何も出ていない状態が続きます。