JSON-LDとは？書き方・実装例・SEO効果【2026年版】

JSON-LD（ジェイソン・エルディー）とは、Webページの内容を検索エンジンに伝えるための構造化データを、JSON形式で記述する方式です。HTMLの本文とは分離した<script>タグの中に書けるため、既存のHTMLに手を入れずに追加でき、あとから直すのも1か所で済みます。この記事では、schema.orgとの関係の整理から、コピペで使える記述例、WordPressでの実装、検証とエラーの直し方、そして2026年に変わった仕様までを、構造化マークアップ代行の実務をもとに解説します。

この記事でわかること

• JSON-LDの位置づけ： 構造化データ＝伝える情報、schema.org＝語彙、JSON-LD＝記述形式という3層の関係です。
• 書き方と実装： 基本構文から、Article・Organization・パンくずリストのコピペ可能なコード例、CMSでの実装までを扱います。
• 入れる型と順番は先に決めない： テーマとプラグインがすでに何を出力しているかを調べてから決めます。足すことより重複させないことが先です。
• 2026年の変更： 8月21日のエスケープ仕様変更と、表示が終了した構造化データの型を、公式情報の範囲で整理します。

JSON-LDとは？

JSON-LDは、ページの内容を機械が読める形で書くための記述形式です。

正式名称は JavaScript Object Notation for Linked Data といいます。JSONというデータ形式に、@contextや@typeで「このデータが何を意味するか」を宣言する仕組みを加えたものです。検索エンジンは本文から内容を推測しますが、JSON-LDがあれば「これは記事で、著者はこの組織で、公開日はこの日だ」を推測なしで受け取れます。

JSON-LDの読み方と正式名称

JSON-LDは「ジェイソン・エルディー」と読みます。LDはLinked Data（リンクト・データ）の略です。

「ジェイソンエルディー」とカタカナで書かれたり、jsonldとハイフンを省いて書かれたりしますが、いずれも同じものです。正式な表記は JSON-LD で、W3C（Web技術の標準化団体）が仕様を策定しています。

JSONとJSON-LDの違い

JSONはデータの入れ物、JSON-LDは「意味のラベルが付いた入れ物」です。JSONの構文ルールはそのまま使います。

違いを生んでいるのが@contextです。@contextにhttps://schema.orgを指定すると、あとに書くnameやauthorが、schema.orgで定義された意味のURL（IRI）に結び付けられます。単なる文字列だった"name"が「schema.orgが定義する名前という語」として扱われる、ということです。この「語を共通の意味につなげる」仕組みがLinked Dataであり、LDにあたります。仕様はJSON-LD 1.1がW3Cの勧告です。

構造化データ・schema.org・JSON-LDの関係

構造化データ＝伝えたい情報、schema.org＝語彙、JSON-LD＝書き方の形式です。

「構造化データを入れる」と言われたときに実際に書くのは、schema.orgの語彙をJSON-LDの形式で並べたコードです。この整理さえ押さえておけば、実装で迷うことはほとんどありません。

JSON-LD・Microdata・RDFaの違い

3つはどれも構造化データの記述形式で、Googleはいずれもサポートしています。

Googleは3形式のどれかを優遇するとは言っておらず、実装しやすく維持しやすい形式を使えばよいという立場です。その条件で選ぶと多くの場合JSON-LDになります。すでにMicrodataで動いているサイトを、わざわざ書き換える必要はありません。

JSON-LDとリッチリザルトは同義ではない

JSON-LDを書けばリッチリザルトが出る、という関係ではありません。

schema.orgに存在する型のすべてが、Google検索の表示対象になっているわけではないからです。schema.orgは検索エンジン専用の仕様ではなく、Web全体で使われる語彙です。そのうちGoogleが検索結果の見た目に反映する型は限られています。schema.orgに載っている型を書いたのに何も表示されない、という相談の多くはこれが原因です。

<script type="application/ld+json"> の書き方

JSON-LDは<script type="application/ld+json">というタグの中に書きます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事タイトル",
  "datePublished": "2026-07-17"
}
</script>

この1行が「中身はJSON-LDです」という宣言です。typeの値はapplication/ld+jsonで固定です。ここをapplication/jsonやtext/javascriptと書くと、JSON-LDとして認識されません。設置場所はhead・bodyのどちらでもGoogleは処理できます。

基本構文（@context・@type・プロパティ）

最低限必要なのは@context・@type・プロパティの3つです。この3つが揃えば構造化データとして成立します。

@contextにはhttps://schema.orgを指定します。どの語彙を使うかの宣言です。@typeにはArticleやOrganizationなど、そのページが何であるかを表す型を書き、そのあとにheadlineやnameといったプロパティを並べます。どのプロパティが必須でどれが推奨かは型ごとにGoogleの公式ドキュメントで定義されているので、実装前に確認します。

値の形式で間違えやすいところ

値の書き方で崩れやすいのは、日付形式・フィールドの重複・エスケープの3つです。

• 日付はISO 8601形式で書く： datePublishedやdateModifiedは2026-08-27のような形式で書きます。「2026年8月27日」と日本語で書くと読み取れません。
• 同じフィールドを2回書かない： 重複させても多くのパーサーはエラーを出さずに黙って通します。検証ツールで問題なしと出たのに値が意図と違う、という事故はここで起きます。
• エスケープを二重にかけない： 2026年8月21日の仕様変更で、二重エスケープされた値の読まれ方が変わりました（後述）。

複数の値は"image": ["URL1", "URL2"]のように配列で、別の型は"author": { "@type": "Organization", "name": "…" }のように入れ子で書きます。

コピペできるJSON-LDの実装例

まず入れるならArticle・Organization・BreadcrumbListの3つです。

コーポレートサイトやオウンドメディアの基本用途は、この3つで足ります。

Article（記事）の記述例

Articleは記事ページに使う型です。タイトル・画像・公開日・著者を機械可読にします。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "JSON-LDとは？構造化データの書き方",
  "image": ["https://example.co.jp/images/sample.webp"],
  "datePublished": "2026-08-27",
  "dateModified": "2026-08-27",
  "author": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "url": "https://example.co.jp/"
  }
}
</script>

WordPressのテーマによってはArticleを自動生成しています。手動で足す前に、すでに出力されていないかを確認してください。

Organization（組織）の記述例

Organizationは運営元を示す型です。トップページか会社概要ページに1つ置きます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.co.jp/#organization",
  "name": "株式会社サンプル",
  "url": "https://example.co.jp/",
  "logo": "https://example.co.jp/images/logo.png",
  "sameAs": [
    "https://x.com/sample_official",
    "https://www.youtube.com/@sample_official"
  ]
}
</script>

sameAsには公式SNSなど、同一の主体だと示せるURLだけを入れます。関係のないページを並べても意味はありません。

BreadcrumbList（パンくずリスト）の記述例

BreadcrumbListはページの階層を示す型です。検索結果のURL表示がパンくず形式になります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://example.co.jp/" },
    { "@type": "ListItem", "position": 2, "name": "ブログ", "item": "https://example.co.jp/blog/" },
    { "@type": "ListItem", "position": 3, "name": "記事タイトル" }
  ]
}
</script>

Googleはこのマークアップで階層を把握するため、実際のディレクトリ構造と一致していなくても処理されます。ただし画面上のパンくず表示とは揃えてください。最後の階層にitemは不要です。

コードを自サイト用に変更する箇所

コピペしたあと書き換えるのは値の部分だけです。構造とプロパティ名は触りません。

社名や商品名に「&」などの記号が入る場合は、後述する2026年8月のエスケープ仕様変更もあわせて確認してください。

JSON-LDをWebページに実装する方法

実装方法は、HTMLへの直接設置・CMSの機能・タグマネージャーの3つです。ただし、その前に確認すべき手順があります。

入れる型と順番は、テーマとプラグインの出力を見てから決める

入れる型と順番は先に決めません。テーマとプラグインがすでに何を自動出力しているかを調べてから決めます。

（アイダイム分析）解説記事の多くは「まずOrganization、次にBreadcrumbList」というように、入れる型と順番が最初から決まっているかのように書かれています。実際の案件では順番はサイトごとに変わります。すでにテーマが出しているものが多く、そこに手動実装を重ねると同じ型が二重に出るからです。作業の主眼は「足す」ことではなく「重複させない」ことにあり、その結果として型も順番もサイトごとに変わります。

この順番で進めると、手動で書くコードは想定よりかなり少なくなります。確認を飛ばして先にコードを足すと、あとから二重出力の切り分けに時間を取られます。

headまたはbodyに直接設置する

headとbodyのどちらに置いてもGoogleは処理できます。管理のしやすさで決めて構いません。

サイト全体で共通するもの（Organizationなど）はhead、記事単位で追加するものはbody（WordPressならカスタムHTMLブロック）に置くと管理しやすくなります。同じページに複数のJSON-LDを置いても問題ありません。

WordPress・CMSでの実装（テーマとプラグインの二重出力に注意）

WordPressでは、手動で書く前にテーマとプラグインの両方の自動出力を確認します。片方だけ見ても足りません。

（実務知見）構造化マークアップの代行で最も多いのが、この二重出力です。SEO系プラグインの出力だけを疑って設定を切ったのに、まだ同じ型が出ている——という場面がしばしばあります。原因はテーマ側の自動出力です。多くの解説は「プラグインの二重出力に注意」で止まっていますが、実際にはテーマが出しているケースがかなりの割合を占めます。プラグインを止めても消えないときは、テーマの機能を先に疑ってください。

確認は、対象ページのソースを表示してapplication/ld+jsonで検索し、いくつ出力されているかを数えるのが確実です。テーマとSEO系プラグインの設定画面を開き、どちらがどの型を出しているかを突き合わせます。

Googleタグマネージャー・JavaScriptでの動的挿入

Googleタグマネージャーでも設置できますが、CMS側で直接出力する方法より優先度は下がります。

JavaScriptで挿入した内容は、レンダリング後に読み取られるためです。CMS側で直接出力できるならそちらを選び、タグマネージャーはテーマやテンプレートを触れない場合の代替手段と考えるのが安全です。設置後はレンダリング後のHTMLで実際に出力されているかを確認します。

JSON-LDの検証方法・エラー・実装時の注意点

検証ツールは2つあり、リッチリザルトテストとSchema Markup Validatorでは見ているものが違います。

リッチリザルトテストはGoogleでの表示適格性を、Schema Markup Validatorは構文の正しさを見ます。

実装直後はリッチリザルトテスト、公開後の運用はSearch Console、という使い分けが基本になります。

Search Consoleでの確認と、エラー・警告の違い

エラーは必須プロパティの欠落、警告は推奨プロパティの欠落です。エラーが出ている型はリッチリザルトの対象になりません。

警告は表示自体を妨げませんが、情報が不足しているという指摘なので、埋められるものは埋めます。修正後は次の手順で再確認します。

1. 修正した内容を本番ページに反映する
2. リッチリザルトテストに公開URLを入れ、エラーが消えているかを確認する
3. Search ConsoleのURL検査で対象URLを開き、インデックス登録をリクエストする
4. Search Consoleの拡張レポートで「検証」を実行し、エラーが解消されたか追跡する

再クロールから拡張レポートへの反映までは数日から数週間の幅があります。反映されないからといって、短期間に何度も申請する必要はありません。

現場で多いエラー3つ

現場で繰り返し出るのは、必須項目の欠落・「名前のないアイテム」・フィールドの重複です。

• 必須項目の欠落： 検証ツールでエラーが出ないのにリッチリザルトが表示されない、という形で現れます。型ごとの必須プロパティを公式ドキュメントで確認してください。
• 名前のないアイテム： nameが入っていないときに出ます。パンくずやFAQの項目で起きやすい警告です。
• 同じフィールドの重複： 同じプロパティを2回書いていても、多くのパーサーは黙って通します。自分の検証では問題なしと出るのに、Search Consoleから指摘が来るのはこのパターンです。

実装時の注意点

実装で守るべき原則は、表示されている内容と一致させることです。ユーザーに見えない情報をマークアップだけで足してはいけません。

• 表示コンテンツと一致させる： Googleの構造化データガイドラインの基本原則です。存在しないレビューや、ページにない情報を書かないでください。
• 必須・推奨プロパティを公式ドキュメントで確認する： 必須の欠落はエラー、推奨の欠落は警告になります。
• テーマとプラグインの二重出力を避ける： 自動出力の有無を確認してから手動実装します。
• 廃止済みの型をコピペしない： 2023年以前の解説記事のコード例には、サポートが終了した型が含まれていることがあります。
• リッチリザルトの表示は保証されない： 適格性を満たしても、表示するかは検索エンジン側の判断です。

2026年のJSON-LDで変わったこと

2026年に変わったのは「表示」と「読み取り方」であって、書き方の基本ではありません。基本構文はそのままです。

変更は2つです。8月のJSON-LDの読み取り仕様の変更と、検索結果に表示される型の縮小です。

表示される型がいまいくつあるのか、なぜ実装しても出ないことがあるのかは「リッチリザルトとは？対応25機能と表示されない5つの原因」に分けてまとめています。

GoogleがHTMLのエスケープ解除を1回だけに変更した（2026年8月21日）

2026年8月21日、Googleは「JSON-LDのエスケープ解除を1回だけ行う」と告知しました。

二重エスケープされた値の読まれ方が変わります。

Googleが示した対処は、二重エスケープに頼らず、標準のJSONエスケープかUnicodeの16進エスケープ（アンパサンドなら&）を使うことです。順位のペナルティではありません。値が意図と違う文字列として読まれ、リッチリザルトの適格性を失ったり、誤った社名が機械側に伝わったりする、という壊れ方をします。

この告知はGoogle検索セントラルの公式アカウントによるもので、公式ドキュメントの更新履歴には現時点で掲載されていません（2026年8月27日時点）。

自分のサイトが影響を受けるか確かめる手順

手書きで書いたJSON-LDでは、まず起きません。危ないのは自動出力です。

二重エスケープは、テンプレートエンジンが「HTMLに出力するから」ともう一度エスケープをかけてしまうときに起きます。確認すべきなのは、テーマの自動出力・SEO系プラグインの出力・自作のスキーマ生成器です。前章のチェック順で洗い出した出力元を、そのまま点検対象にできます。

確認方法は、リッチリザルトテストかSchema Markup Validatorでレンダリング後のスキーマを開き、値に実体参照の文字列が残っていないかを見るだけです。社名や商品名に「&」やアポストロフィが含まれるサイトは優先して確認してください。正しく実装できていれば対応は不要です。

2025年から2026年に表示が終了した型

検索結果に表示される型は、この2年で縮小しています。すでに実装したものを外す必要はありません。

なお、Dataset・Q&A（QAPage）は現在も公式ドキュメントが公開されており、廃止されていません。「これらも2026年1月に廃止された」と書く解説を見かけますが、Google公式では確認できません。サイトリンク検索ボックスは廃止済みですが、時期は2024年11月です。

FAQ構造化データは外すべきか

外す必要はありません。Googleは、使われていない構造化データが検索に悪影響を与えることはないとしています。

FAQPageはschema.orgの型としては引き続き有効で、残しておいても問題は起きません。新規ページでリッチリザルト目的に実装する意味はなくなりましたが、すでに入っているものを削除する作業に工数を割く理由はない、という整理です。ページ上に表示されているFAQのコンテンツ自体は、引き続き有効です。

運用上の注意が1つあります。FAQリッチリザルトのSearch Console APIのサポートは2026年8月に終了します。APIで取得したデータをダッシュボードやBigQueryに流している場合は、その部分の見直しが必要です。

現在もGoogle検索でサポートされている主な型

いま実装する価値があるのは、Googleがリッチリザルトの対象として現在もサポートしている型です。

Article・Breadcrumb・Dataset・Event・JobPosting・Organization・Product・Q&A・Review・Videoなどが該当します。

優先度が高いのはパンくずリスト・組織情報・著者情報の3つです。どのページにも共通して当てはまり、機械側がサイトの主体と構造を把握する土台になるためです。ECサイトならProductとReview、採用ページがあればJobPostingを加えます。求人票のマークアップは「Googleお仕事検索のマークアップ完全ガイド」で解説しています。

判断に迷う場合は、まず現状のスキーマを一覧にするところから始めるのが確実です。

JSON-LDのSEO効果とAI検索での役割

JSON-LDを入れても検索順位は上がりません。役割はページ理解の補助と、検索の表示機能に対する適格性です。

期待と実態がずれやすいところなので、Googleが何と言っているか、実験で何が確かめられているかを順に見ます。

Googleが言っていること

Googleは、AI機能に表示されるために特別な構造化データを追加する必要はないと明記しています。

GoogleのAI機能とウェブサイトについての公式ドキュメントには、AI機能で表示されるために新たに機械可読なファイルやマークアップを作る必要はなく、特別なschema.orgの構造化データを追加する必要もない、と書かれています。順位についても、実装が順位を上げるとは保証していません。役割はページ理解の補助と、検索表示機能への適格性です。

1,885ページの実験でAI引用は増えなかった

Ahrefsの実験では、JSON-LDを追加してもAI引用はほとんど動きませんでした。追加による効果は確認されていません。

2025年8月から2026年3月にかけてJSON-LDを追加した1,885ページを、約4,000ページの対照群と比較した調査です。結果はAIモードが+2.4%、ChatGPTが+2.2%で、いずれもノイズと区別できない範囲でした。AI Overviewsは−4.6%と、小さいながら有意な減少が出ています。

ただし読み方には限界があります。対象はもともとAI Overviewsに100回以上引用されていたページで、すでに認識されているページに足しても新しい情報にはならなかった、と読むのが正確です。一方、600万URLの相関分析では、AIに引用されるページはJSON-LDを持つ確率が約3倍高いという結果も出ています。相関はあるが追加による因果は確認できていない、というのが現時点の状況です。

それでもJSON-LDを書く理由

表示のためではなく、機械にとっての「奥付」として書く、という位置づけになります。

構造化データは、誰が運営していて、この情報がどのページのどの部分にあたるのかを、推測ではなく宣言で伝えます。宣言があると、同名の企業や似た商品と取り違えられにくくなります。エンティティの考え方は「LLMOとは」「エンティティ設計」でも扱っています。順位やAI引用を直接動かす施策ではなく、中身が評価される前提を整える作業だと考えるのが実態に合っています。

構造化データを増やす方向にコストをかける前に、本文で答えを出せているかを確認してください。

JSON-LDのよくある質問

JSON-LDについて検索されることの多い疑問をまとめます。

参考情報

• 構造化データマークアップの仕組みについて｜Google検索セントラル
• Google検索でサポートされている構造化データマークアップ（検索ギャラリー）
• Google の AI 機能とウェブサイト｜Google検索セントラル
• リッチリザルトテスト
• Schema Markup Validator