JSON-LDとは？構造化データの書き方・実装・検証方法

JSON-LDとは、Webページの内容を検索エンジンに正確に伝えるための構造化データを、JSON形式で記述するマークアップ方式です。Googleが推奨する形式であり、HTMLの本文とは分離した<script>タグ内に記述できるため、実装と管理のしやすさに優れています。本記事では、構造化データ・schema.orgとの関係の整理から、コピペで使える記述例、WordPressなどでの実装方法、Search Consoleでのエラー修正までを、構造化マークアップ代行の実務経験をもとに解説します。

この記事でわかること

• JSON-LDの位置づけ： 構造化データ＝伝える情報、schema.org＝語彙、JSON-LD＝記述形式という3層の関係
• 書き方と実装： 基本構文から、Article・Organization・パンくずリストのコピペ可能なコード例、CMS別の実装方法まで
• 検証とエラー対処： リッチリザルトテストとSchema Markup Validatorの使い分け、Search Consoleでのエラー修正手順

JSON-LDとは？構造化データ・schema.orgとの違い

JSON-LD（ジェイソン・エルディー）は「JavaScript Object Notation for Linked Data」の略で、Webページ上の情報を機械が読み取りやすい形で記述するためのデータ形式です。まず、混同しやすい「構造化データ」「schema.org」との関係を整理します。

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

3つの用語は、役割がそれぞれ異なります。

• 構造化データ： 「このページは記事で、著者は誰で、いつ公開された」といった、検索エンジンに伝えたい情報そのもの
• schema.org： その情報を表現するための共通語彙（ボキャブラリ）。GoogleやMicrosoftなどが共同で策定した「単語帳」にあたります
• JSON-LD： 語彙を使って実際にページへ書き込むときの記述形式（シンタックス）のひとつ

つまり「schema.orgという語彙を、JSON-LDという形式で書いたものが、ページの構造化データになる」という関係です。この整理さえ押さえれば、後述の実装作業で迷うことはほとんどなくなります。

JSONとJSON-LDの違い

JSONは、キーと値のペアでデータを表現する汎用的なデータ交換形式です。JSON-LDはそのJSONの構文を使いながら、@contextや@typeといった特別なキーワードで「このデータが何を意味するか」を宣言できるように拡張したものです。JSONが「データの入れ物」だとすれば、JSON-LDは「意味のラベル付きの入れ物」といえます。

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

読み方は「ジェイソン・エルディー」です。「LD」はLinked Data（リンクト・データ）の頭文字で、Web上のデータ同士を意味的につなげるという設計思想を表しています。

JSON-LD・Microdata・RDFaの違い

構造化データをページに記述する形式は、JSON-LDのほかにMicrodata・RDFaの計3種類があり、Googleはいずれもサポートしています。3形式の違いを比較します。

表のとおり、JSON-LDは既存のHTMLを書き換えずに追加でき、構造化データが1カ所にまとまるため管理が容易です。

GoogleがJSON-LDを推奨する理由

Googleの公式ドキュメントは、サイト所有者にとって実装と管理が最も容易であることを理由に、JSON-LDの使用を推奨しています。一方で、3形式とも正しく実装されていれば扱いは同等であるとも明記されています。

既存のMicrodataをJSON-LDに移行する必要はあるか

すでにMicrodataやRDFaで正しく実装済みのページを、慌ててJSON-LDに書き換える必要はありません。正しく実装されている限りGoogleの評価は同等だからです。新規で実装する場合や、大規模サイトで管理を一元化したい場合にJSON-LDを選ぶ、という判断が現実的です。

JSON-LDのSEO効果とできないこと

JSON-LDを実装すると何が起き、何が起きないのか。過度な期待を避けるためにも、効果とできないことを分けて整理します。

検索エンジンがページ内容を理解する手掛かりになる

構造化データの本質的な役割は、ページの内容・種類・運営主体を機械可読な形で明示し、検索エンジンの理解を助けることです。文章の解釈に頼らせるより、誤解の余地が小さい形で情報を渡せます。

（実務知見）構造化マークアップ代行の案件でさまざまな中小企業サイトを見てきましたが、テーマやプラグインが古いままで構造化データが実質空っぽ、あるいは壊れたまま放置されているサイトは珍しくありません。本文の品質は高いのにページの種類すら正しく伝わっていない状態で、マークアップを整備するだけで検索結果の表示が安定するケースがあります。

リッチリザルトの対象になる可能性がある

対応する型のJSON-LDを実装すると、検索結果でパンくずリストや記事情報などのリッチリザルト表示の対象になります。ただし、実装しても表示はGoogle側の判断であり、保証はされません。

なお、リッチリザルトの対応型は年々整理されています。近年サポートが終了した主な型は次のとおりです。

このように、schema.orgに存在する型でも、Google検索でリッチリザルトになるとは限りません。実装前に、Google公式の「構造化データマークアップの一覧（検索ギャラリー）」で現在サポートされている型を確認するのが確実です。

JSON-LDだけで検索順位が上がるわけではない

構造化データは、それ自体が順位を引き上げるランキング要因だとGoogleが保証しているものではありません。役割はあくまでページ理解の補助と、リッチリザルトなど検索表示機能への適格性です。「JSON-LDを入れたのに順位が動かない」という声は珍しくありませんが、それは仕様どおりの挙動です。順位を動かすのはコンテンツそのものであり、JSON-LDはその内容を正しく伝えるための土台と考えるのが適切です。

AI検索・LLMOにおけるJSON-LDの役割

AI Overviews（AIによる概要）やChatGPTなどのAI検索が普及した現在、JSON-LDはLLMO（大規模言語モデル最適化）の文脈でも語られるようになりました。ここでは期待と現実を分けて整理します。

JSON-LDはAI検索にどのように役立つのか

JSON-LDは、ページの内容・種類・運営主体を機械可読な形で宣言する手段です。AIがWebを読む時代において、「誰が・何について・どんな種類のページを公開しているか」を曖昧さの少ない形で示せることは、検索システムや対応する機械にとって解釈の手掛かりになります。

エンティティを明確にするという考え方

（アイダイム分析）LLMO観点でJSON-LDに取り組むなら、リッチリザルト狙いの型を増やすことよりも、エンティティ（実体）の一貫性に価値があると考えています。Organizationで組織名・公式URL・ロゴを宣言し、@idで同一エンティティを参照し、sameAsで公式SNSなど信頼できるプロフィールへつなぐ。この一貫した宣言は、機械が「このサイトの運営主体はどの会社か」を識別する際の曖昧さを減らす手掛かりになり得ます。エンティティ設計の全体像は「LLMOにおけるエンティティ設計」で詳しく解説しています。

なお、sameAsには手当たり次第にURLを並べるのではなく、同一組織であることを示せる公式プロフィールに限定することが重要です。

JSON-LDを入れてもAI引用が増えるとは限らない

一方で、過度な期待は禁物です。Google公式は、AI OverviewsやAIモードへの掲載に特別な構造化データや追加の技術要件は不要と説明しています。また、JSON-LDを追加した約1,900ページを追跡した海外の調査では、AI検索での引用に大きな増加は確認できなかったと報告されています。「JSON-LDを入れればAIに引用される」という因果関係は、2026年7月時点で確立されていません。

LLMOを意識したJSON-LDの実装方針

（アイダイム分析）以上を踏まえると、LLMO文脈でのJSON-LDは「AI引用を直接増やす施策」ではなく、「ページ内容と運営主体の情報を機械可読な形で一貫して示す基盤」と位置づけるのが正確です。ページ内容に合う型を正しく実装し、表示コンテンツ・著者情報・サイト内の表記と一致させる。この堅実な実装が、従来のSEOとAI検索の双方に対して現時点で再現性の高い方針です。

ページに合うschemaタイプの選び方

書き方の前に、「どの型を実装するか」を決めます。実務では、この選定を飛ばしていきなりコード例をコピペすることが失敗のもとになります。

選び方の基準はシンプルで、「ページの主目的に対応する型を選ぶ」ことです。

• ブログ記事・コラム： Article（またはBlogPosting）
• 会社概要・運営者情報： Organization
• 店舗・地域ビジネスのページ： LocalBusiness（MEO対策との連携は「MEO対策における構造化マークアップ」を参照）
• 階層のあるサイト全般： BreadcrumbList（パンくずリスト）
• 商品ページ： Product、求人ページ：JobPosting など

注意すべきは、schema.orgに定義されている型とGoogleがリッチリザルト対象としてサポートする型は一致しないことです。実装前にGoogleの検索ギャラリーで対象型と必須プロパティを確認し、対象外の型は「ページ理解の補助」と割り切って実装するかどうかを判断します。

JSON-LDの書き方

型を決めたら、実際に記述します。基本の骨格は全型で共通です。

基本構文とscriptタグ

JSON-LDは、<script type="application/ld+json">タグの中にJSON形式で記述します。

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

• @context： 使用する語彙の宣言。基本はhttps://schema.orgで固定
• @type： このデータが表す型（Article、Organizationなど）
• 各プロパティは"キー": "値"のペアで記述し、末尾の要素以外はカンマで区切ります

配列・ネスト・値の形式

実際のマークアップでは、値が入れ子（ネスト）や配列になります。書き間違いが多いのは次のポイントです。

• 複数の値は配列[ ]で囲む（例："sameAs": ["URL1", "URL2"]）
• 著者や組織などのオブジェクトは{ }でネストし、その中にも@typeを書く
• URLは相対パスではなくhttps://から始まる絶対URLで書く
• 日付はISO 8601形式（例：2026-07-17）で書く
• 最後の要素の後ろにカンマを付けない（末尾カンマは構文エラーになります）

@idと@graphで複数の型を関連付ける（応用）

1ページにArticle・Organization・BreadcrumbListなど複数の型を入れる場合、@graphでまとめ、@idで相互参照する書き方があります。「この記事の発行者（publisher）は、このOrganizationである」という関係を機械可読に示せるため、エンティティの一貫性という点で整った書き方です。まずは単体の型を正しく書けるようになってからで問題ありません。

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

利用頻度の高い3つの型のコード例です。そのまま貼り付けた後、自サイトの値に書き換えて使ってください。

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-07-17",
  "dateModified": "2026-07-17",
  "author": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "url": "https://example.co.jp/"
  }
}
</script>

Organization（組織）の記述例

<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>

Organizationは全ページに機械的に貼るのではなく、サイトの代表ページ（トップや会社概要）を起点に、@id参照で一貫させる設計が整っています。

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

<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>

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

コピペ後に必ず書き換える箇所を一覧にまとめます。

書き換え漏れ（example.co.jpのまま公開など）は実務で頻出するミスです。貼り付けたら、次章の方法で必ず検証してください。

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

書いたJSON-LDをページに設置する方法は複数あります。環境別に整理します。

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

Googleは、JSON-LDを<head>内・<body>内のどちらに設置しても処理できると明記しています。テーマのheader編集やウィジェットでHTMLを追加できる環境なら、そのまま貼り付ければ完了です。

WordPress・CMSでの実装

WordPressの場合、実装経路は主に3つあります。

• SEOプラグイン・テーマの機能を使う： 多くのSEOプラグインやテーマ（SWELLなど）はArticle・パンくず等のJSON-LDを自動出力します。まず自サイトが何を自動出力しているかを確認するのが先です
• カスタムHTMLブロックに貼る： 記事単位で追加したい場合は、本文にカスタムHTMLブロックとしてscriptタグごと貼り付けます
• テーマファイルに追記する： サイト全体に共通の型（Organizationなど）は、子テーマのテンプレートに記述します

（実務知見）代行案件で最も多いトラブルが、このCMS・プラグイン絡みです。テーマとSEOプラグインが同じ型のJSON-LDを二重に出力していたり、プラグインの自動出力と手動で貼ったコードが矛盾した値を宣言していたりするケースが目立ちます。手動実装の前に、既存の出力を検証ツールで確認し、重複する型はどちらか一方に寄せることが先決です。

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

GoogleはJavaScriptで動的に挿入されたJSON-LDも処理できるとしています。Googleタグマネージャー（GTM）経由の実装も可能です。ただしレンダリングに依存するため、確実性ではHTMLへの静的出力が基本形です。GTM実装は「HTMLを直接触れないがタグは入れられる」場合の次善策と位置づけ、価格・在庫など更新頻度の高い情報の動的生成は特に慎重に扱ってください。

JSON-LDの検証方法とエラーの直し方

実装後は必ず検証します。ツールの使い分けと、エラーが出たときの直し方をまとめます。

リッチリザルトテストとSchema Markup Validatorの違い

検証ツールは2つあり、見ているものが異なります。

• リッチリザルトテスト（Google）： そのページがGoogleのリッチリザルト対象として適格かを判定。Google検索での表示可否を見るならこちら
• Schema Markup Validator（schema.org）： schema.orgの語彙・構文として正しいかを検証。リッチリザルト対象外の型のチェックはこちら

片方で問題なしでも、もう片方では警告が出ることがあります。「Googleのリッチリザルトを狙う型はリッチリザルトテスト、それ以外の型はValidator」と使い分けてください。

（実務知見）当社が構造化データの実装や修正に入るときは、チェックリストを目視でなぞるより先に、まずテストページにJSON-LDを入れて検証ツールと実際の反映を確認します。環境（テーマ・プラグイン・キャッシュ）による挙動の違いは机上では読み切れないため、小さく実地で試すほうが結果的に速いからです。

Search Consoleで確認する方法

サイト全体の構造化データの健全性は、Search Consoleの「拡張」レポート（パンくずリスト等の型別レポート）で確認できます。新しく実装したページは、URL検査ツールで個別に検証し、必要に応じてインデックス登録をリクエストします。

エラーと警告の違い

Search Consoleや検証ツールの指摘は、深刻度が2段階に分かれます。

• エラー（必須プロパティの欠落・構文不正）： リッチリザルト表示の対象外になるため、修正が必要
• 警告（推奨プロパティの欠落）： 表示自体は可能。値を用意できるなら追加が望ましいという位置づけ

警告が残っているだけで「SEOに悪影響がある」わけではありません。まずエラーをゼロにすることを優先してください。

よくあるエラーと直し方

実務で遭遇頻度の高いエラーは次の5つです。

• 表示内容との不一致： ページに見えていない情報をJSON-LDだけに書いている。構文が正しくてもガイドライン違反になるため、本文と一致させる
• 重複マークアップ： テーマ・プラグイン・手動コードが同じ型を多重出力している。出力元をひとつに統一する
• 構文エラー： 末尾カンマ、括弧の閉じ忘れ、全角引用符の混入。Validatorで行番号を特定して修正する
• 相対URL・日付形式の不備： itemやimageは絶対URL、日付はISO 8601形式に修正する
• 廃止済みの型の実装： 古い解説記事のFAQPageやHowToのテンプレートをコピペしている。現在の検索ギャラリーで対象型を確認する

修正後に再クロール・検証する手順

エラーを修正したら、公開URLで再度検証ツールを通し、Search ConsoleのURL検査からインデックス登録をリクエストします。型別レポートにエラーが出ていた場合は、レポート内の「修正を検証」を押すとGoogleが再確認を開始します。反映までの期間は再クロールのタイミングに左右されるため、固定の日数は見込まず、数日〜数週間の幅で待つのが現実的です。

JSON-LD実装時の注意点

最後に、実装・運用で押さえるべき注意点をまとめます。

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

JSON-LDのよくある質問

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

参考情報

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