構造化データとは？JSON-LDの書き方とリッチリザルト検証

構造化データとは、ページの内容を検索エンジンが機械的に理解できるよう、決められた語彙（主に schema.org）で書き添える情報のことです。Google が推奨する書き方は JSON-LD で、HTML の <script type="application/ld+json"> の中に JSON を置くだけで実装できます。

ただし、構造化データを正しく書いても検索結果の見た目が必ず変わるわけではありません。さらに FAQ のリッチリザルトは、Google 検索セントラルの更新情報によると 2026 年 5 月 7 日以降 Google 検索に表示されなくなりました。「とりあえず FAQPage を入れる」という定番施策は、現在は効果が見込めません。

この記事では、Article・BreadcrumbList・Organization・FAQPage の JSON-LD の具体例、リッチリザルトの現状、Rich Results Test と Search Console での検証手順、OGP・X（旧 Twitter）カードとの違い、よくあるエラーまでを順に整理します。情報は 2026 年 10 月 6 日時点で Google 検索セントラルなどの一次情報を確認したものです。

構造化データとは？検索エンジンに意味を伝える仕組み

人間はページを見れば「これは記事で、著者は誰で、いつ公開された」と分かりますが、検索エンジンは HTML から推測するしかありません。構造化データは、その推測を減らすために「このページは Article です」「この文字列は公開日です」と明示する注釈です。

Google は構造化データの形式として JSON-LD、Microdata、RDFa の 3 つに対応しています。そのうち JSON-LD が推奨されています。理由は、本文の HTML に属性を埋め込む Microdata や RDFa と違い、1 か所にまとめて書けるため実装と保守が容易だからです。

構造化データでできること・できないこと

• できること: ページの種類や属性を正確に伝える。条件を満たせば、検索結果にパンくずや評価などの装飾（リッチリザルト）が出る対象（eligible）になる
• できないこと: 順位の押し上げの保証。Google は、正しいマークアップでもリッチリザルトの表示を保証しないと明記しています
• やってはいけないこと: ページに見えていない内容のマークアップ。ガイドラインは「ユーザーに見えないコンテンツをマークアップしない」と定めており、違反するとリッチリザルトが表示されなくなる手動対策の対象になり得ます

つまり構造化データは「表示を約束する装置」ではなく、「正確さを担保したうえで、表示の資格を得るための土台」です。まずはページ自体の品質とメタ情報の整備が先で、そのうえで該当する種類だけを追加するのが現実的な順序です。

図1　HTML・構造化データ・検索結果の関係

JSON-LD の書き方と基本ルール

JSON-LD は、HTML の <head> または <body> 内に <script type="application/ld+json"> を置き、その中に JSON を書きます。最小の骨格は次のとおりです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "ページのタイトル"
}
</script>

• @context は語彙の場所。通常は https://schema.org 固定です
• @type は種類（Article、BreadcrumbList など）。大文字小文字を区別するので、article ではなく Article と書きます
• 文字列は必ずダブルクォートで囲みます。JSON ではシングルクォートも末尾カンマも使えません
• 日付は ISO 8601（例: 2026-10-06T09:00:00+09:00）で書きます
• URL は https:// から始まる絶対 URL にします

実装の手順

手書きするより、まず本記事のような雛形をコピーして自サイトの値に置き換えるのが確実です。WordPress などの CMS では、SEO プラグインが Article や BreadcrumbList を自動出力していることが多いので、手動で重複して追加しないよう、先に現状のソースを確認してください。同じ種類が二重に出力されると、後述のエラーや警告の原因になります。

図2　構造化データ実装の流れ

【コピペ可】Article・BreadcrumbList・Organization・FAQPage の JSON-LD 例

以下は Google 検索セントラルの各ドキュメントに沿った書き方です。ドメインや名称は自サイトのものに置き換えてください。

Article（記事）

Article には必須プロパティがなく、該当するものを追加する方針です。推奨されているのは author、datePublished、dateModified、headline、image です。image は縦横比の違う複数の画像（16:9、4:3、1:1）を渡すのが望ましいとされています。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "構造化データの書き方",
  "image": [
    "https://example.com/images/article-16x9.jpg",
    "https://example.com/images/article-4x3.jpg",
    "https://example.com/images/article-1x1.jpg"
  ],
  "datePublished": "2026-10-06T09:00:00+09:00",
  "dateModified": "2026-10-06T09:00:00+09:00",
  "author": [{
    "@type": "Person",
    "name": "山田 太郎",
    "url": "https://example.com/profile/yamada"
  }]
}

BreadcrumbList（パンくずリスト）

ページ上のパンくずと同じ階層を書きます。position は 1 から始まる連番で、最後の項目は item（URL）を省略できます。省略した場合、Google は現在のページの URL を使います。

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [{
    "@type": "ListItem",
    "position": 1,
    "name": "ホーム",
    "item": "https://example.com/"
  },{
    "@type": "ListItem",
    "position": 2,
    "name": "SEO",
    "item": "https://example.com/seo/"
  },{
    "@type": "ListItem",
    "position": 3,
    "name": "構造化データの書き方"
  }]
}

Organization（組織情報）

こちらも必須プロパティはなく、関連するものをできるだけ多く入れる方針です。name、url、logo（112×112px 以上）、sameAs（SNS などの公式プロフィール）、address、telephone などが推奨されています。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://example.com/",
  "logo": "https://example.com/images/logo.png",
  "sameAs": [
    "https://x.com/example",
    "https://www.facebook.com/example"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+81-3-0000-0000",
    "contactType": "customer service"
  }
}

FAQPage（よくある質問）

書き方そのものは従来から変わっていません。ただし次章のとおり、FAQ のリッチリザルトは現在 Google 検索に表示されません。

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "構造化データは必須ですか？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "必須ではありませんが、ページの意味を正確に伝える助けになります。"
    }
  }]
}

複数の種類を 1 ページに入れる場合は、<script> を種類ごとに分けて並べても、配列でまとめても構いません。

リッチリザルトの種類と現状（FAQ は 2026 年 5 月で終了）

リッチリザルトとは、青いリンクだけの標準表示を超えた、画像・評価・パンくずなどを含む検索結果の表示です。Google 検索セントラルの「検索ギャラリー」に、対応する機能（Article、Breadcrumb、Organization、Product、Recipe、Event、Job posting、Local business、Video など）が一覧されています。

近年の縮小・廃止の動き

Google 検索セントラルの更新情報では、構造化データ関連の機能が段階的に整理されています。確認できた主な事実は次のとおりです。

• 2025 年 9 月 9 日: Course info、Estimated salary、Learning video、Special announcement、Vehicle listing が検索結果に表示されなくなり、ドキュメントから削除
• 2025 年 11 月 5 日: Practice problem が検索結果に表示されなくなった。Dataset のマークアップは Dataset Search でのみ使われ、Google 検索では使われない
• 2026 年 5 月 8 日: FAQ のリッチリザルトを廃止すると告知（2026 年 5 月 7 日から Google 検索に表示されない）
• 2026 年 6 月 15 日: FAQ リッチリザルトのドキュメントを削除。「Google 検索結果に表示されなくなった」と明記

なお、FAQ の表示はその前から、2023 年 9 月に「政府機関や医療系の信頼できるサイトのみ」へ制限されていました。最終的に全面終了した形です。

これから構造化データをどう扱うか

• FAQ 目的のマークアップを新規に追加する必要はありません。既存の FAQPage マークアップを消さなければならない、という案内は確認できていませんが、リッチリザルトの効果は期待できません
• 表示の対象になる機能は変動するため、実装前に検索ギャラリーで最新の対応状況を確認してください
• Article・Breadcrumb・Organization のように、ページの意味づけとして素直に書けるものは、表示の有無にかかわらず整えておく価値があります

図3　導入前の確認ポイント

リッチリザルト テストと Search Console で検証する方法

構造化データは書いた直後に検証し、公開後も継続して監視します。使う道具は主に 2 つです。

公開前: Rich Results Test

Google の Rich Results Test は、公開されている URL を入力する方法と、コードのスニペットを直接貼り付ける方法の両方に対応しています。まだ公開していないマークアップは、コードスニペットで検証できます。結果には、検出された機能と、エラー・警告が表示されます。

公開後: Search Console

Search Console には、検出された構造化データの種類ごとに「リッチリザルト ステータス」系のレポートが表示されます。有効な項目数、警告、エラーが推移で確認でき、修正後は検証を依頼できます。個別の URL は URL 検査ツールでも確認できます。

エラーと警告の違い

• エラー: 必須プロパティの欠落など。リッチリザルトの対象外になる
• 警告: 推奨プロパティの不足など。対象にはなるが、情報が増やせる余地がある

なお、Rich Results Test で問題なしでも、ガイドライン違反までは検出できない場合があります。見えない内容のマークアップや内容の不一致は、ツール上は通っても手動対策の対象になり得るため、ページの見た目との一致は自分で確認してください。また、構造化データを含むページが robots.txt や noindex で遮断されていると、Google はそれを読み取れません。

図4　検証から公開後の監視まで

OGP・Twitter（X）カードとの違いと設定例

構造化データと混同されやすいのが OGP（Open Graph Protocol）です。両者は目的も読み手も異なります。

• 構造化データ（schema.org）: 主に検索エンジンが、ページの意味を理解するために読む
• OGP: SNS やチャットアプリが、リンクが共有されたときにタイトルや画像のカードを作るために読む

OGP の仕様では、全ページに og:title、og:type、og:image、og:url の 4 つが必須とされています。実務では、og:description や og:site_name も合わせて設定します。X のカードは、twitter:card でカードの種類を指定します。画像を大きく見せたいときは summary_large_image を使います。title・description・image は twitter: 系の値がなければ OGP の値が使われる構成が一般的ですが、最新の挙動は X の開発者向けドキュメントで確認してください。

<meta property="og:title" content="構造化データの書き方">
<meta property="og:type" content="article">
<meta property="og:url" content="https://example.com/articles/structured-data">
<meta property="og:image" content="https://example.com/images/ogp.png">
<meta property="og:description" content="JSON-LD の具体例と検証方法を解説します。">
<meta name="twitter:card" content="summary_large_image">

OGP の設定は検索順位に直接効く施策ではなく、SNS 経由のクリック率や見栄えを整える施策です。画像は絶対 URL で、共有時に切り取られても意味が通るデザインにしておくと安全です。

図5　構造化データと OGP の違い

構造化データのよくあるエラーと対処法

実際に多いつまずきを、原因別に整理します。

JSON の構文エラー

末尾カンマ、シングルクォート、閉じ忘れの括弧は典型例です。テンプレートで値を埋め込むとき、タイトルに含まれる " がエスケープされず JSON が壊れるケースもあります。CMS の出力は、必ずソースで確認してください。

必須プロパティの欠落

機能ごとに必須プロパティが異なります。Article や Organization は必須なしですが、パンくずの itemListElement の position と name、FAQ の Question や Answer のように、構造上欠かせない項目があります。ドキュメントで機能ごとに確認してください。

ページの内容と一致していない

ページに無い情報、たとえば表示されていない評価や価格をマークアップしてはいけません。これはガイドライン違反で、手動対策の対象になり得ます。

重複・競合

テーマ、プラグイン、手動追加で同じ種類が複数出力されることがあります。ソースを確認し、出力元を一つに絞ります。

遮断されている

構造化データを含むページが robots.txt でクロールを遮断されている、または noindex になっていると、リッチリザルトは表示されません。

図6　エラー切り分けチェック

サイトスカウターの SEO 診断で現状を確認する

サイトスカウターの SEO 内部診断では、対象ページを 1 回取得して、構造化データの有無、OGP（og:title・og:description・og:image の 3 つ）の設定数、canonical、noindex / nofollow（メタタグと X-Robots-Tag）などを自動判定します。

構造化データの判定は、JSON-LD の <script> 数、または Microdata（itemscope）の有無を検出するもので、中身の正しさやリッチリザルトの対象可否までは判定しません。マークアップの妥当性は、前述の Rich Results Test で確認してください。診断結果で「構造化データなし」と出たページがあれば、本記事の例を参考に、まず Article と BreadcrumbList から追加するのがおすすめです。

よくある質問

構造化データを入れると検索順位は上がりますか？

構造化データは順位の押し上げを保証するものではありません。Google はリッチリザルトの表示も保証しないとしており、ページの意味を正確に伝え、表示の対象になるための土台と考えるのが適切です。

JSON-LD と Microdata はどちらを使うべきですか？

Google は JSON-LD を推奨しています。HTML 本文と切り離して 1 か所にまとめて書けるため、実装と保守が容易だからです。Microdata と RDFa にも対応していますが、特別な理由がなければ JSON-LD を選びます。

FAQPage の構造化データはまだ入れるべきですか？

Google 検索セントラルによると、FAQ のリッチリザルトは 2026 年 5 月 7 日以降 Google 検索に表示されません。リッチリザルトを目的とした新規追加は不要です。

構造化データが正しいか確認する方法は？

公開前は Google の Rich Results Test に URL またはコードを入力して確認します。公開後は Search Console のリッチリザルト ステータス レポートと URL 検査ツールで、検出状況とエラーを継続的に確認します。

OGP を設定すれば構造化データは不要ですか？

役割が異なるため代替にはなりません。OGP は SNS などでの共有時のカード表示用、構造化データは検索エンジンにページの意味を伝えるための情報です。必要に応じて両方を設定します。

出典・参考資料

最終確認日：2026-10-06。制度・仕様は変更されることがあるため、実施前に各一次情報をご確認ください。

• 構造化データ マークアップの概要 | Google 検索セントラル
• 構造化データの一般的なガイドライン | Google 検索セントラル
• 検索ギャラリー | Google 検索セントラル
• Google 検索セントラル 更新情報
• Article の構造化データ | Google 検索セントラル
• パンくずリストの構造化データ | Google 検索セントラル
• Organization の構造化データ | Google 検索セントラル
• FAQ の構造化データ | Google 検索セントラル
• Rich Results Test
• The Open Graph protocol