メインコンテンツまでスキップ

Google ガイドラインと JSON-LD 推奨の根拠

この章で扱うこと​

実装に着手する前に、Google が 構造化データに対して何を要求し、何を禁じているか を整理します。違反すると検索結果から除外されたりマニュアルアクションを受けたりするため、技術的に「動く」マークアップを書く前に必ず把握すべき内容です。

公式の一次ソースは General Structured Data Guidelines (確認: 2026-05) です。本章では URL の引用だけに頼らず、方針の精神 (なぜそのルールがあるのか) を要約します。Google ガイドラインのページ構造は定期的に再編されるため、URL より本質を残すことを優先しています。

大原則: 「コンテンツとの整合性」​

Google ガイドラインで一貫している最大の原則は、次のとおりです。

構造化データの内容は、ページに表示されているコンテンツと一致しなければならない

ということです。これは技術的というより倫理的な要請で、検索エンジンとユーザーへの誠実さを担保します。

何が「整合性」違反になるか​

パターン問題
ページに無い情報を構造化データで主張するユーザーが検索結果から来たとき期待を裏切る
ページにある情報と構造化データの値が食い違う検索エンジンへの誤情報提供
構造化データで宣言した型と実際のコンテンツが乖離 (例: 商品ページに Article をマークアップ)検索エンジンの分類精度を損なう
具体例

たとえば商品ページに「★4.8 (250 件のレビュー)」と書かれていないのに、AggregateRating で ratingValue: 4.8 を宣言してはいけません。実数値と一致させるか、レビューを表示するか、どちらかです。

規範 1: 不可視コンテンツのマークアップ禁止​

ユーザーには見せず、構造化データだけで宣言する 「不可視マークアップ」 は禁止です。

  • display: none や visibility: hidden で隠された要素を構造化データで参照する
  • ページに記載されていない FAQ を FAQPage でマークアップする
  • 表示されていない価格を Product.offers で宣言する

これは前項「コンテンツとの整合性」の派生規範です。検索結果に表示される情報は、ユーザーがクリックして到達したページで確認できなければなりません。

規範 2: スパム / 誤導的マークアップの禁止​

意図的に検索順位を操作する目的のマークアップは禁止です。代表的な禁止事項:

  • 競合製品名を Product.name に入れる (ブランド詐称)
  • 無関係なキーワードを description や keywords に詰め込む
  • 全ページの主題を同じ高評価の Review でマークアップする (レビュー詐欺)
  • 関係のない型を組み合わせて検索流入を狙う (例: 通常記事に Recipe を付ける)

規範 3: ページ主題と型の対応​

構造化データはページの主題を正しく表現する必要があります。

  • 1 ページの主題は基本 1 つ。複数主題を持つページ (例: 製品一覧ページ) は適切に表現する (ItemList 等)
  • mainEntity は ページの主たる entity 1 つ に対して使う。schema.org 公式の背景ノートは "about can refer to multiple entities/topics, while mainEntity should be used for only the primary one" と明記している
  • ホームページに全製品の Product を網羅的に書くのは過剰

03 章 で詳述しますが、「ページの主題は何か」を一義に決められないなら、まずページ自体の構造を見直すべきです。

違反時のペナルティ​

ガイドライン違反が検知されると、以下の段階的ペナルティがあります。

  1. リッチリザルト非掲載: 検索結果に通常リンクとしては出るが、リッチリザルト (画像 / レビュー / パンくず等) が出なくなる
  2. 構造化データ無視: 該当ページの構造化データ全体が無視される
  3. マニュアルアクション: Google が手動で対策を実施し、Search Console の「手動による対策」レポートに通知が来る。構造化データのマニュアルアクションは該当ページがリッチリザルト表示資格を失うもので、ウェブ検索のランキング自体には影響しないと公式に明記されている

マニュアルアクションを受けると、修正後に 再審査リクエスト を出す必要があり、回復までに時間がかかります。リスクと対価が見合わないので、グレーゾーンの実装は避けます。

JSON-LD が推奨される根拠​

01 章 で「JSON-LD / Microdata / RDFa の 3 形式があり、JSON-LD が Google 推奨」と述べました。ここで詳しい根拠を整理します。

公式ソース: Intro to How Structured Data Markup Works (確認: 2026-05) で Google が JSON-LD を推奨する旨が明記されています。

推奨理由 1: 本文 HTML から完全に分離できる​

Microdata / RDFa は HTML 要素の属性として埋め込むため、構造化データを変更するたびに本文マークアップを触る必要があります。デザイン変更で要素構造が変わると、構造化データも壊れます。

JSON-LD は <script> ブロックに完全分離されているため、本文の DOM 構造に依存しません。SEO 要件のために本文マークアップを歪める必要がない ことが、メンテナンス性で有利な理由です。

推奨理由 2: 動的生成しやすい​

JSON-LD は JSON シリアライズ可能なオブジェクト なので、サーバーサイドとクライアントサイドのどちらでも生成しやすいです。

// 例: サーバーサイドで JSON-LD オブジェクトを構築して返す
const jsonLd = {
  "@context": "https://schema.org",
  "@type": "WebPage",
  name: page.title,
  description: page.description,
  // ...
};

return `<script type="application/ld+json">${JSON.stringify(jsonLd).replace(/</g, "\\u003c")}</script>`;

JSON.stringify は XSS をサニタイズしないため、動的値を埋め込む場合は < のエスケープが必須です (Next.js 公式ガイドも同様の置換を推奨)。

Microdata / RDFa は HTML テンプレート側で属性を組み立てる必要があるため、データソースとマークアップが密結合します。

推奨理由 3: コンポーネント設計と相性が良い​

React / Vue / Nuxt / Next.js のような コンポーネント指向 UI では、コンポーネントツリーがネスト構造を取ります。Microdata の itemscope / itemtype をコンポーネント境界に合わせて書くと、UI 再利用性が損なわれます。

JSON-LD はページのメタ情報として独立しているため、UI コンポーネントは UI の責務だけに集中でき、構造化データは別レイヤーで管理できます。

他形式が選ばれるケース​

JSON-LD は推奨ですが、以下のケースでは他形式も選択肢に残ります。

  • 既存の Microdata マークアップを段階移行中: 並行運用は避け、一気に JSON-LD へ寄せる方が混乱が少ない
  • 静的 HTML のみで JavaScript を一切使えない環境: それでも <script type="application/ld+json"> は JS 実行を伴わないので JSON-LD は使える

実質的に新規実装では基本的に JSON-LD が第一候補 と考えてよいです。

アンチパターン: 過剰マークアップ​

ガイドライン違反ではないものの、過剰なマークアップ は推奨されません。

Anti-pattern 1: 関連性の薄い型を網羅的に追加する​

「WebPage / Article / BlogPosting / Product / Review / FAQPage 全部つけよう」というアプローチは逆効果です。ページの主題が曖昧になり、Google の分類精度が落ちます。

原則: 必要最小限の型を、適切な階層で書く

Anti-pattern 2: 不要なプロパティを埋める​

schema.org は型ごとに数十のプロパティを持ちますが、すべて埋める必要はありません。ページの内容に該当しないプロパティは省略 します (空文字列やプレースホルダ値で埋めない)。

Anti-pattern 3: 巨大な単一 JSON-LD ブロック​

1 つの <script> に全情報を詰め込むより、@graph で複数オブジェクトを並列に並べるほうが可読性とメンテ性が高いです。

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "...", ... },
    { "@type": "WebSite", "@id": "...", ... },
    { "@type": "WebPage", "@id": "...", "isPartOf": { "@id": "..." }, ... }
  ]
}

@graph を使うと各オブジェクトを独立した entity として宣言でき、@id で相互参照できるので、構造が明確になります。

実装着手前のチェックリスト​

ガイドライン遵守のために、実装前に以下を確認します。

着手前チェックリスト
  • ページに表示されている情報と構造化データの内容が一致するか
  • 不可視要素を構造化データで参照していないか
  • ページの主題は 1 つに絞れているか
  • mainEntity を 1 つに決められるか
  • 関連性の薄い型を「念のため」追加していないか
  • プロパティを空文字列やダミー値で埋めていないか

このあと​

ガイドラインの規範と JSON-LD 推奨の根拠を押さえました。次章 03. 型選定の判断プロセス では、本ガイドの中核として、「自サイトでどの型を選ぶか」 を決める判断フローを汎化された決定木付きで提示します。