技術情報 2026.05.09

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

はじめに

Webサイト制作において、構造化データや JSON-LD を扱う機会が増えています。

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

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

構造化データとは

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

構造化データを実装すると、検索結果に次のような拡張表示（リッチリザルト）が出る場合があります。

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

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

構造化データの目的は、リッチリザルトの表示そのものではなく、検索エンジンにページ内容を正確に伝えることです。

記述形式の種類

構造化データの記述形式は主に3つあります。現在は JSON-LD を選べば問題ありません。HTMLの構造から独立して記述できるため、保守性が高く実装も容易です。

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

JSON-LD の基本構文

JSON-LD は <head> 内、または <body> 内に配置できます。

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

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

よく使うスキーマタイプ

Organization（組織・企業）

企業や団体のサイトでよく使うスキーマで、共通テンプレートから出力することが多い項目です。

<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（サイト全体）

サイト全体を表すスキーマで、トップページまたは共通テンプレートで出力します。各ページの 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は2023年にFAQリッチリザルトの表示対象を政府機関や医療系などのサイトに限定しており、一般的なサイトでは検索結果にFAQリッチリザルトが表示されなくなっています。

そのため、Google向けのリッチリザルト施策としては期待できません。ページ内容を機械的に説明するための補助情報として扱い、FAQとして見せていないコンテンツを無理に変換しないようにします。なお、最新の取り扱いは変更される可能性があるため、実装前にGoogle Search Centralの該当ドキュメントを確認してください。

<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 との整合

検証ツール

まとめ

他の技術情報

大量のRAW写真を待たずに選別・現像するデスクトップアプリ「FlyView」を公開しました

WordPressをFTPで直接アップロードすると、失敗しても成功に見える。ctimeから原因を絞り込んだ話

WordPressのwp2shellとは？影響するバージョンと今すぐ行う対策

お問い合わせ・お見積もりはお気軽に