構造化データはページの意味を Google に機械可読で伝える仕組み

なぜこれを学ぶか

構造化データは 正しく実装すれば CTR が 25-80% 上がる事例があるが、間違えると逆にスパム判定される ハイリスク・ハイリターンな施策。 リッチリザルト（FAQ / レビュー星 / 価格 / 営業時間 / レシピなど）の表示権を獲得できる唯一の手段で、競合がやっていないなら最大の差別化ポイントになる。

EC・メディア・コーポレートサイトで CTR を取りに行く時の主要武器であり、AEO（AI 検索の引用獲得）でも重要な役割を果たす。

学ばないと起きること

学ぶメリット

• リッチリザルト獲得で CTR を 25-80% 改善できる（業界事例多数）
• AI Overview / AI 検索の引用候補に乗りやすくなる
• Google が「このページが何について書いているか」を確実に理解できる
• 競合がやっていない場合、SERP での視覚的な存在感を独占できる

仕組み

構造化データとは

ページの内容を「これはレシピで、材料は…、調理時間は…、カロリーは…」といったラベル付きデータで Google に伝える仕組み。 Google はそのデータを使って、検索結果にリッチリザルト（拡張表示）を出すかを判定する。

構造化データの効果（事例）

Google 公式ケーススタディから:

3 つのフォーマット

Google はどの形式も同等に扱うが、実装・保守の容易性で JSON-LD が推奨される。

JSON-LD はユーザー可視 HTML と分離されているので、ネスト構造を扱いやすく、JavaScript で動的注入もできる（Google が認識する）

JSON-LD の最小実装例（Article）

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO 対策の基本",
  "datePublished": "2026-05-10T10:00:00+09:00",
  "author": {
    "@type": "Person",
    "name": "山田 太郎"
  },
  "image": "https://example.com/article-image.jpg"
}
</script>

リッチリザルトとは

通常の青いリンク + スニペットの代わりに、視覚的に拡張された結果を表示する機能。 代表例:

キー概念

Schema.org が共通語彙、Search Central が Google 仕様の正本

構造化データの語彙は schema.org が共通仕様だが、Google が「どのプロパティを使うか / どれを必須とするか」を独自に定めている。 schema.org のドキュメントは Google 検索の挙動を決めない。Google Search Central のドキュメントが正本。

必須・推奨・任意プロパティ

各リッチリザルトタイプには必須プロパティが定められている。1 つでも欠けるとリッチリザルト対象外。

優先順位は「より少ないが完全で正確な推奨プロパティ」が「多いが不正確・不完全な推奨プロパティ」より良い。

重要な品質ルール

• ページに表示されている情報のみマークアップ（hidden content の構造化データは違反）
• 古い・期限切れの情報を残さない（Google は時限切れコンテンツを表示しない）
• ページ内容と無関係な構造化データは付けない
• 著作者・運営者を偽装しない

Validator / 検証ツール

開発時はリッチリザルトテスト、デプロイ後は Search Console の拡張レポートで定点監視するのが標準フロー。

同一ページに複数タイプ

1 ページに複数のリッチリザルトタイプを入れても OK。例: レシピページに Recipe + Video + Breadcrumb の 3 タイプ。 ネストする方法（メイン Recipe 内に Video を入れる）と、独立に並べる方法のどちらでも認識される。

関連がある場合は @id で紐付けると Google が「この動画はこのレシピのもの」と理解しやすい。

よくある誤解

実務での適用

CTR を狙うなら最初に入れるべき構造化データ

検証 → デプロイ → 監視のフロー

1. リッチリザルトテストで構造化データの妥当性を確認、プレビューで意図通りの表示を確認
2. 本番デプロイ
3. URL 検査ツールで「Google が構造化データを認識したか」を確認
4. Search Console の拡張レポート（FAQPage / Recipe / Product など）でエラー数を定点監視
5. 数週間〜数ヶ月後、Performance レポートで CTR 変化を測定（実装前後のページ比較）

効果測定の方法

公式推奨は「同じテーマの 2 ページで構造化データの有無を比較」する A/B テスト。

1. 構造化データなしのページを数ヶ月分の Search Console データで把握
2. 片方に構造化データを実装
3. 数ヶ月後、両ページの CTR を Performance レポートで比較

季節性がない、内容変化が少ない、流入が安定しているページを選ぶ。

CMS の落とし穴

WordPress プラグイン（Yoast SEO / Rank Math / Schema Pro 等）は構造化データを自動生成するが、テーマやプラグインの更新で出力が変わったり、必須プロパティが欠落することがある。 Search Console の拡張レポートで定期監視する。

トラブル別の対処

公式ソース

• 構造化データの紹介
• 一般的な構造化データのガイドライン
• リッチリザルト カタログ
• リッチリザルトテスト
• Schema.org
• JavaScript で構造化データを生成する

自己テスト

これらの内容を採点付きで挑戦したい場合は、本ドメインのプロ試験で 5 問形式で確認できる。