JSON-LDとは？入れても順位もAI引用も上がらない。それでも書く理由と正しい書き方

JSON-LD（ジェイソン・エルディー）とは、Webページの内容を検索エンジンに伝えるための構造化データを、JSON形式で記述する方式です。先に結論を書くと、JSON-LDを入れても検索順位は上がらず、AIに引用されやすくなるという裏付けもありません。Googleは「AI機能のために特別なschema.orgの構造化データを追加する必要はない」と明記しており、Ahrefsが1,885ページで行った実験でもAI引用は増えませんでした。それでも書くのは、リッチリザルトの対象になる条件を満たすためと、運営元・著者・住所といった事実を推測ではなく宣言で渡すためです。

この記事では、JSON-LDの位置づけと書き方、コピペで使える記述例（求人票のJobPostingを含む）、WordPressでの実装、テストは通るのに表示されないときの確認手順、値を本文やGoogleビジネスプロフィールと一致させる点検、2026年8〜9月の公式の変更までを、構造化マークアップ代行の実務をもとに解説します。

この記事でわかること

• 入れても上がらない理由と、それでも書く理由： Googleの公式ドキュメントと1,885ページの実験から、JSON-LDにできることとできないことを分けます。
• 書き方と実装： 基本構文から、Article・Organization・パンくずリスト・求人票（JobPosting）のコピペ可能なコード例、CMSでの実装までを扱います。
• テストは通るのに表示されないとき： インデックス登録・Googlebotが取得したHTML・拡張レポートの順に確かめます。
• 値を本文・ビジネスプロフィールと一致させる： 社名・住所・電話番号の表記のずれを洗い出す点検の手順です。
• 2026年の変更： 8〜9月の公式の変更と、表示が終了した構造化データの型を、公式情報の範囲で整理します。

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の形式で並べたコードです。実装で迷ったときは、いま書いているのが3層のどれなのかに戻ると整理できます。

JSON-LD・Microdata・RDFaの違い

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

Googleは3形式ともサポートしたうえで、JSON-LDを「実装と管理を最も容易に行うことができる（つまり、ユーザーエラーの発生する可能性が低い）」形式としてすすめています。すでにMicrodataで動いているサイトを、わざわざ書き換える必要はありません。

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

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

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

<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は不要です。

JobPosting（求人票）の記述例

JobPostingは求人ページに使う型で、Googleしごと検索に載るための条件です。必須プロパティは5つあります。

Googleの求人情報の構造化データのドキュメントで必須とされているのは、datePosted（掲載日）・description（仕事内容）・hiringOrganization（採用する組織）・jobLocation（勤務地）・title（職種名）の5つです。例外が1つあり、完全リモートの求人でapplicantLocationRequirements（応募できる地域）を指定する場合は、jobLocationは必須ではなくなります。

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "JobPosting",
  "title": "Webマーケティング担当（正社員）",
  "description": "自社サイトのSEO改善と広告運用を担当していただきます。",
  "datePosted": "2026-10-01",
  "validThrough": "2026-12-31T23:59",
  "employmentType": "FULL_TIME",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "sameAs": "https://example.co.jp/",
    "logo": "https://example.co.jp/images/logo.png"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "サンプル町1-2-3",
      "addressLocality": "千代田区",
      "addressRegion": "東京都",
      "postalCode": "100-0000",
      "addressCountry": "JP"
    }
  }
}
</script>

descriptionには、ページに表示している仕事内容をそのまま入れます。置き場所は1件の求人を説明する個別ページで、求人の一覧ページやトップページにまとめて置くのはGoogleのガイドラインに反します。募集を締め切ったら、validThroughを過去の日時にするか、ページかマークアップを外します。給与（baseSalary）や雇用形態（employmentType）は推奨プロパティで、埋められるものは埋めます。求人票のマークアップ全体と、しごと検索に出すまでの手順は「Googleお仕事検索のマークアップ完全ガイド」で解説しています。

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

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

社名や商品名に「&」などの記号が入る場合は、後述する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つ

見落としやすいのは、必須項目の欠落・「名前のないアイテム」・フィールドの重複の3つです。

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

リッチリザルトテストは通るのに検索結果に表示されないとき

テストに通るのは「表示の対象になれる」という意味で、表示の約束ではありません。

まずページがインデックスに登録されているかを確かめます。リッチリザルトテストは、入れたURLやコードの構造化データが仕様を満たしているかを見るツールです。そのページが検索に登録されているか、Googleが表示を選ぶかまでは判定しません。確認は次の順で進めます。

1. Search ConsoleのURL検査で、対象URLが「URLはGoogleに登録されています」になっているかを見る。登録されていなければ、構造化データより前の問題です
2. URL検査の「公開URLをテスト」から「テスト済みのページを表示」を開き、Googlebotが取得したHTMLにJSON-LDが入っているかを見る。JavaScriptで挿入している場合は、ここで欠けていることがあります
3. Search Consoleの拡張レポート（パンくずリスト・求人情報など）で、そのページが有効なアイテムとして数えられているかを見る
4. それでも出ない場合は、Googleが表示するかを選んでいる段階です。検索の機能は国や地域によって違うため、日本で提供されている機能かどうかも確かめます。Googleは2026年9月8日に、検索体験の地域差を説明するドキュメントを追加しました

求人票は経路がもう1つあります。Googleは「求人情報の URL では、サイトマップではなく Indexing API を使用することをおすすめします」としており、掲載が遅い、締め切った求人が残る、という場合はここから見直します。型ごとの表示されない原因は「リッチリザルトとは？対応25機能と表示されない5つの原因」で整理しています。

実装時の注意点

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

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

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

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

まず2026年8〜9月の公式の変更を一覧にします。JSON-LDの書き方に関わるのは、8月21日の読み取り仕様の変更と、9月24日の動画（VideoObject）のプロパティ追加の2つです。

10月1日の更新は生成AIコンテンツのガイドで、構造化データの変更は含まれていません（2026年10月3日時点）。このあとは、読み取り仕様の変更と、検索結果に表示される型の縮小を順に見ます。

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

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

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

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

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

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

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

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

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

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

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

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

なお、Q&A（QAPage）は現在も公式ドキュメントが公開されています。Dataset（データセット）は、Googleが2025年11月に「Dataset Searchでのみ使い、Google検索では使わない」と更新履歴で明記しました。データセット検索に載せる目的なら引き続き使えますが、Google検索の表示を狙う型ではありません。サイトリンク検索ボックスは廃止済みですが、時期は2024年11月です。

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

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

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

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

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

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

Article・Breadcrumb・Event・JobPosting・Organization・Product・Q&A・Review・Videoなどが該当します。Videoは2026年9月24日に、制作者を示すcreatorプロパティが推奨プロパティとして加わりました。

優先度が高いのはパンくずリスト・組織情報・著者情報の3つです。どのページにも共通して当てはまり、機械側がサイトの主体と構造を把握する土台になるためです。ECサイトならProductとReview、採用ページがあればJobPostingを加えます。記述例は前述の「JobPosting（求人票）の記述例」にあります。

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

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

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

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

Googleが言っていること

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

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

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

Ahrefsの実験では、JSON-LDを追加してもAI引用は有意には増えませんでした。追加による効果は確認されていません。

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

ただし読み方には限界があります。対象はもともとAI Overviewsに100回以上引用されていたページで、すでに認識されているページに足しても新しい情報にはならなかった、と読むのが正確です。一方、同じAhrefsの記事（2026年6月9日公開）は、600万URLを分析した段階で、AIに引用されたページは引用されていないページよりJSON-LDを持つ確率が3倍近く高かった、とも報告しています。相関はあるが追加による因果は確認できていない、というのが現時点の状況です。

JSON-LDの値は本文・ビジネスプロフィールと一致させる

JSON-LDに書く社名や住所は、ページの本文やGoogleビジネスプロフィールの表記と揃えます。

電話番号・営業時間も同じです。Googleは「構造化データをページに表示されるテキストと一致させます」と書いています。

この一文はGoogleのAI機能とウェブサイトのドキュメントにあり、構造化データの一般的なガイドライン（ページに無い情報をマークアップしない）と同じ考え方です。ただし、一致させると引用や順位がどれだけ動くかの数字は、Googleも示していません。

海外では、Search Engine JournalのLoren Baker氏が2026年9月1日の記事で、ページ本文・スキーマ・記録の場（Googleビジネスプロフィールなど）・第三者の裏付けの4つが一致すると、AIにとって1つの確かな参照点になる、と主張しています。根拠として挙がっているのはクライアント2件の観察で、比較実験ではありません。この記事では、ずれを残さないための点検の理由として扱い、効果の証拠としては扱いません。

点検は次の順で進めます。

1. 正しい表記を1つに決める：社名（「株式会社」の位置・通称との使い分け）、住所（番地を「1丁目2番3号」と書くか「1-2-3」と書くか、建物名の有無）、電話番号の書き方を、それぞれ1行で決めておく
2. ずれを洗い出す：決めた1行と、JSON-LDの値（レンダリング後）・会社概要ページの本文・フッター・Googleビジネスプロフィール・掲載しているポータルサイトを並べて比べる。Baker氏の記事には、サイトでは「Suite」、マークアップでは略記の「Ste」と書いていた例が出てきます
3. 1ページで直して確かめてから広げる：まず会社概要ページ1枚でJSON-LDと本文を揃え、リッチリザルトテストで値が意図どおりに読めることを確かめてから、テーマやプラグインの設定を直してサイト全体に広げる

表記をサイトの外の情報源まで含めてどう揃えるかの全体設計は「AI検索のエンティティ設計」、Googleビジネスプロフィールと構造化マークアップの関係は「構造化マークアップはMEOに効くのか」で扱っています。

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

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

書く理由は3つに絞れます。

• リッチリザルトの対象になる： パンくずリスト・求人情報・商品・動画などは、構造化データが表示の条件です。JSON-LDが無ければ、そもそも候補に入りません。
• 事実を推測ではなく宣言で渡す： 誰が運営していて、著者は誰で、いつ公開したのかを宣言で伝えます。宣言があると、同名の企業や似た商品と取り違えられにくくなります。
• 壊れたときに気づける： どの型をどこが出しているかを把握していれば、8月21日の変更のように読み取りの仕様が変わったときも、誤った値が出ていないかをすぐ点検できます。自動出力に任せきりのサイトほど、ずれに気づくのが遅れます。

エンティティの考え方は「LLMOとは」でも扱っています。順位やAI引用を直接動かす施策ではなく、中身が評価される前提を整える作業だと考えるのが実態に合っています。

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

JSON-LDのよくある質問

読み方・表記・FAQPageの扱い・順位への効果・求人票など、本文で扱いきれなかった疑問に答えます。

参考情報

この記事で根拠にした公式ドキュメントと報道です（2026年10月3日時点で確認）。

• 構造化データマークアップの仕組みについて｜Google検索セントラル
• Google検索でサポートされている構造化データマークアップ（検索ギャラリー）
• Google の AI 機能とウェブサイト｜Google検索セントラル
• 求人情報（JobPosting）の構造化データ｜Google検索セントラル
• 動画（VideoObject）の構造化データ｜Google検索セントラル
• Google検索セントラルのドキュメント更新履歴
• Google Changes JSON-LD Extraction For Googlebot｜Search Engine Roundtable
• We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved.｜Ahrefs
• Search Engine Journal：Loren Baker（2026年9月1日）
• リッチリザルトテスト
• Schema Markup Validator