WEB 2026.05.09

Webサイトに構造化データを正しく実装するためのJSON-LDガイド

はじめに

Webサイトを制作していると「構造化データ」「JSON-LD」という言葉を耳にする機会が増えてきたのではないでしょうか。

Googleをはじめとする検索エンジンは、HTMLを解析してページの意味を理解しようとしますが、人間が読むためのHTML構造と、機械が理解しやすい構造には乖離があります。構造化データは、この乖離を埋めるための「機械向けの意味付け」です。

本記事では、構造化データの実装形式として現在もっとも推奨されている JSON-LD の基本と、実際の組み込み方法を解説します。

構造化データとは

構造化データとは、Webページの内容を検索エンジンが解釈しやすい形式で記述した情報のことです。schema.org が定義するボキャブラリーを使い、ページが「会社のサイトである」「記事ページである」「パンくずリストがある」といった情報を明示します。

適切に実装すると、検索結果に以下のような表示が得られる場合があります（リッチリザルト）。

パンくずの表示
記事の公開日・著者名
商品・レシピなど、対象タイプに応じた評価情報
求人、イベント、商品情報などの拡張表示

ただし、リッチリザルトが必ず表示されるわけではありません。また、構造化データの種類によっては、現在Google検索でリッチリザルト表示の対象外になっているものもあります。

構造化データの本質は「リッチリザルトを狙う」ことではなく、検索エンジンにページ内容を正確に伝えることです。

記述形式の種類

構造化データの記述形式は主に3つあります。

形式	説明
JSON-LD	`<script>` タグ内に JSON 形式で記述。Google検索向けの実装では推奨されている形式
Microdata	HTML 要素に属性を付与する形式
RDFa	同じく HTML 属性ベース

現在は JSON-LD 一択で問題ありません。HTMLの構造と独立して記述できるため、保守性が高く実装も簡単です。

JSON-LD の基本構文

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "スキーマタイプ",
  "プロパティ": "値"
}
</script>

<head> 内、または <body> 内に配置できます。複数のスキーマを出力する場合は、<script> タグを分ける方法と、@graph でまとめる方法があります。小規模サイトでは <script> タグを分けても問題ありませんが、関連する情報をまとめて管理したい場合は @graph を使うと整理しやすくなります。

よく使うスキーマタイプ

Organization（組織・企業）

企業・団体のサイトでよく使います。共通テンプレートで出力することが多い schema です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://example.com/",
  "logo": "https://example.com/assets/images/logo.png",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "〇〇町1-2-3",
    "addressLocality": "〇〇市",
    "addressRegion": "〇〇県",
    "postalCode": "000-0000",
    "addressCountry": "JP"
  },
  "telephone": "000-000-0000"
}
</script>

注意点

logo には実在する画像URLを指定する。検索エンジン向けには、SVGよりもPNG/JPEG/WebPなどのラスター画像を用意しておくと安全
sameAs（公式SNS）は確認済みのURLのみ追加する

WebSite（サイト全体）

サイト全体を表す schema です。トップページまたは共通テンプレートで出力します。各ページの WebPage と関連付けたい場合は、WebPage 側で isPartOf を使って WebSite を参照すると整理しやすくなります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "サイト名",
  "url": "https://example.com/"
}
</script>

サイト内検索が実装されている場合は potentialAction を追加できますが、なければ省略します。

WebPage / AboutPage / ContactPage（各ページ）

各ページの意味付けです。ページの役割に応じて @type を使い分けます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "ページタイトル",
  "url": "https://example.com/page/"
}
</script>

ページ	推奨 `@type`
会社概要	`AboutPage`
お問い合わせ	`ContactPage`
その他の固定ページ	`WebPage`

BreadcrumbList（パンくずリスト）

ページにパンくずリストが表示されている場合のみ追加します。UIの階層と必ず一致させてください。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "ホーム",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "お知らせ",
      "item": "https://example.com/news/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "記事タイトル",
      "item": "https://example.com/news/sample/"
    }
  ]
}
</script>

BlogPosting / Article（記事）

ブログ記事や投稿ページに使います。headline、datePublished、dateModified、author、publisher などは、ページ上の内容と矛盾しないように設定します。特に著者名や更新日は、画面上の表示・管理画面の情報・JSON-LDの内容が食い違わないように注意します。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "記事タイトル",
  "mainEntityOfPage": "https://example.com/blog/sample/",
  "datePublished": "2026-05-01",
  "dateModified": "2026-05-09",
  "author": {
    "@type": "Organization",
    "name": "株式会社サンプル"
  },
  "publisher": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/assets/images/logo.png"
    }
  }
}
</script>

FAQPage（よくある質問）

Q&A がページ上にそのまま掲載されている場合に使用できます。ただし、Google公式ドキュメントでは、2026年5月7日以降FAQリッチリザルトはGoogle検索に表示されなくなったと案内されています。そのため、Google向けのリッチリザルト施策としては期待できません。ページ内容を機械的に説明するための補助情報として扱うのが現実的です。

また、FAQ として見せていないコンテンツを無理に変換しないことが重要です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "質問文をそのまま入れる",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "回答文をそのまま入れる"
      }
    }
  ]
}
</script>

@id によるエンティティの関連付け

複数のスキーマ（Organization / WebSite / WebPage など）を関連付ける場合、@id と @graph を使うと構造を整理できます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "株式会社サンプル",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/assets/images/logo.png"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "name": "サイト名",
      "url": "https://example.com/",
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/about/#webpage",
      "name": "会社概要",
      "url": "https://example.com/about/",
      "isPartOf": {
        "@id": "https://example.com/#website"
      },
      "about": {
        "@id": "https://example.com/#organization"
      }
    }
  ]
}
</script>

@id にはURLフラグメント（#organization など）を使い、同じ @id を参照することでエンティティ間のリレーションを表現します。小規模サイトでは必須ではありませんが、スキーマの関係性を明確にしたい場合に有効です。

WordPress での実装

WordPress テーマで実装する場合、PHP 配列から wp_json_encode() で生成するのが定番です。

<?php
$schema = [
    '@context' => 'https://schema.org',
    '@type'    => 'Organization',
    'name'     => get_bloginfo('name'),
    'url'      => home_url('/'),
];
?>
<script type="application/ld+json"><?php echo wp_json_encode($schema, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES); ?></script>

ポイント

直書き JSON より配列組み立てを使う（変数の混入が安全）
JSON_UNESCAPED_UNICODE で日本語をそのまま出力
JSON_PRETTY_PRINT は出力サイズが増えるため本番では不使用
wp_json_encode() は WordPress 標準関数。非 WordPress 環境では json_encode() を使用

実装時の注意点

やってはいけないこと

ページに存在しない情報を補完する
レビュー・評価・価格を実データなしに書く
パンくずが UI に存在しないのに BreadcrumbList を付与する
無関係なスキーマを1ページに大量追加する
FAQ でない内容を FAQPage に変換する

URLは必ず絶対URLで

// NG
"url": "/about/"

// OK
"url": "https://example.com/about/"

canonical との整合

WebPage の url は、canonical タグのURLと一致させます。

検証ツール

実装後は必ず以下のツールで検証してください。

ツール	用途
schema.org バリデーター	JSON-LD の構文・型チェック
Google リッチリザルトテスト	リッチリザルト対象かどうかの確認
Chrome DevTools（ソース確認）	実際に出力されている JSON-LD の確認

まとめ

JSON-LD は、記述形式のシンプルさとHTMLとの独立性から、現在もっとも扱いやすい構造化データの実装方法です。

ただし、効果を期待するあまり「盛りすぎる」実装は、Googleのガイドライン違反になる場合もあります。根拠のある情報だけを、最小限の構成で正確に記述するという原則を守ることが、長期的に安全で有効な運用につながります。

まずは Organization と WebSite から始め、ページの役割に応じて WebPage 系を追加していくアプローチがおすすめです。

なお、構造化データは「schema.org上で定義されていること」と「Google検索でリッチリザルト表示されること」が同じではありません。Google検索での表示対象やサポート状況は変更されるため、実装前には必ずGoogle Search Centralの最新ドキュメントを確認してください。

本記事の内容は 2026年5月時点の情報をもとにしています。schema.org および Google のガイドラインは随時更新されるため、実装前に最新情報をご確認ください。

ACT3

技術情報

Webサイトに構造化データを正しく実装するためのJSON-LDガイド

はじめに

構造化データとは

記述形式の種類

JSON-LD の基本構文

よく使うスキーマタイプ

Organization（組織・企業）

WebSite（サイト全体）

WebPage / AboutPage / ContactPage（各ページ）

BreadcrumbList（パンくずリスト）

BlogPosting / Article（記事）

FAQPage（よくある質問）

@id によるエンティティの関連付け

WordPress での実装

実装時の注意点

やってはいけないこと

URLは必ず絶対URLで

canonical との整合

検証ツール

まとめ

技術情報

はじめに

構造化データとは

記述形式の種類

JSON-LD の基本構文

よく使うスキーマタイプ

Organization（組織・企業）

WebSite（サイト全体）

WebPage / AboutPage / ContactPage（各ページ）

BreadcrumbList（パンくずリスト）

BlogPosting / Article（記事）

FAQPage（よくある質問）

@id によるエンティティの関連付け

WordPress での実装

実装時の注意点

やってはいけないこと

URLは必ず絶対URLで

canonical との整合

検証ツール

まとめ

他の技術情報

Minecraft Forge MOD で学ぶ：乗り物システムの C/S アーキテクチャと入力同期設計

Claude Code / Codex のトークン消費を減らすために、MCPツールを整理した

Google Antigravity で `invalid UTF-8` が発生し AI チャットが不能になった