構造化データとは何か｜仕組みと実装方法を解説

構造化データを設定すると、検索結果にレビューの星や料金・FAQが表示される「リッチリザルト」を獲得でき、クリック率（CTR）の改善につながります。技術的な実装が必要なため「難しそう」と感じる担当者も多いですが、仕組みを理解すれば対応の優先度を正しく判断できます。この記事では、構造化データの基本概念から種類・実装方法・Googleによる検証手順まで、導入判断に必要な知識を一通り解説します。

【基礎知識①】構造化データとは

構造化データとは、WebページのコンテンツをGoogleなどの検索エンジンが機械的に正確に理解できる形式で記述したメタデータのことです。通常のHTMLだけでは「この数字は価格なのか評価スコアなのか」が検索エンジンには判断しにくいため、専用の記法で情報の意味を明示します。見た目のページデザインには影響せず、クロール・インデックス・リッチリザルトの表示に直接関わる技術です。

「構造化データ」「構造化マークアップ」「スキーママークアップ」はほぼ同義として使われます。本記事でも特に区別せず扱います。

HTMLだけでは伝わらない「意味」を補う

通常のHTMLは、見出し・段落・画像などの「見た目の構造」を伝えます。しかし「この文章はレビューである」「この数字は星5段階の評価値である」「この人物は記事の著者である」といった情報の意味（セマンティクス）は、HTMLだけでは検索エンジンに正確に伝わりません。

構造化データを加えることで、検索エンジンは曖昧さなくコンテンツを解釈できます。結果として、検索結果に星評価・価格・FAQなどが視覚的に表示されるリッチリザルトへとつながります。

リッチリザルトとは、通常の青いリンクに加えて星評価・画像・FAQなどが展開表示される検索結果のことです。クリック率（CTR）の向上に寄与します。

Schema.orgとは：Googleも採用する国際標準の共通語彙

構造化データを記述するための共通ルール（語彙）がSchema.orgです。Google・Microsoft（Bing）・Yahoo!・Yandexが共同で2011年に策定した国際標準の仕様で、現在Googleが推奨するメインの規格となっています。

Schema.orgには800種類を超えるタイプ（型）が定義されており、商品（Product）・イベント（Event）・記事（Article）・レシピ（Recipe）などが含まれます。各タイプには、name・price・descriptionのような「プロパティ」が紐づいており、情報の詳細を伝えられます。

Schema.orgの語彙は継続的に拡張されています。最新のタイプ一覧はSchema.org 公式サイトで確認できます。

構造化データが影響する3つの領域

構造化データはページの見た目を変えません。しかし、検索エンジンの処理フローにおいて次の3つの領域に直接影響します。

• クロール：ページの内容をより正確にボットが解釈できる
• インデックス：コンテンツの種類・属性が適切に記録される
• リッチリザルト：星評価・価格・FAQなど拡張表示の対象になる

Googleは構造化データをリッチリザルトの表示条件として活用しており、実装の有無が検索結果の見え方に影響します。詳細はGoogle Search Central – Introduction to structured data markupに公式解説があります。

【基礎知識②】構造化データがSEOにもたらす3つのメリット

構造化データは、Googleの直接的なランキング要因ではありません。しかし、検索エンジンへのコンテンツ理解の促進やリッチリザルト表示など、SEOに間接的な恩恵をもたらします。3つのメリットを順に解説します。

メリット①：検索エンジンがページ内容を正確に認識しやすくなる

HTMLのテキストだけでは、「この文字列は商品名なのか著者名なのか」を検索エンジンが判断しにくい場面があります。構造化データを使うと、コンテンツの意味を明確に伝えられます。

Google公式ドキュメントでも、ページ内容の理解とエンティティ情報の収集の両方に構造化データを活用していると明示されています。人・場所・物・概念を軸にしたエンティティベースの検索が進化する中、ナレッジグラフへの反映や関連クエリへの表示精度が向上します。

また、AuthorスキーマやOrganizationスキーマを正しく実装すると、GoogleがE-E-A-T（経験・専門性・権威性・信頼性）シグナルを把握しやすくなります。著者やサイト運営者の信頼性を補強する手段としても有効です。

インデックス速度の向上効果は期待できる可能性がありますが、公式エビデンスは限定的です。過度な期待は避け、あくまで副次的な効果として捉えましょう。

メリット②：リッチリザルトが表示されCTRの向上が期待できる

リッチリザルトとは、星評価・価格・FAQ・パンくずリストなど、通常の検索結果より視覚的に目立つ表示形式のことです。同じ順位でもリッチリザルトがある方がクリックされやすく、CTR（クリック率）の大幅な改善が期待できます。

Googleの公式ケーススタディでは、以下の成果が報告されています。

企業名	効果
Rotten Tomatoes	構造化データ付きページでCTRが25%向上
Food Network	訪問数が35%増加
Nestlé	リッチリザルト表示ページが非表示ページより82%高いCTR

構造化データを正しく実装しても、リッチリザルトの表示はGoogleのアルゴリズムが判断します。実装したからといって表示が保証されるわけではない点に注意してください。

なお、パンくずリストはデスクトップの検索結果表示においてGoogleが廃止を進めています。ただし、Search Consoleのレポートやサイト構造の把握には引き続き有効なため、実装自体は続ける意義があります。

メリット③：音声検索・AI検索（AI Overview）に引用されやすくなる

2025年時点で、AI Overview（旧SGE）は50%超の検索結果に表示されています。構造化データは、AIによる検索サマリーに引用されるための重要なシグナルとして注目されています。

FAQ・HowTo・Article・OrganizationなどのスキーマをもつページはAI生成サマリーに引用されやすいとされており、構造化データが整っているページへの優位性が高まっています。ChatGPT・Perplexity・GeminiなどのAIエンジンも、構造化データを通じて「これは組織情報」「これは商品の価格」といった明確な文脈を読み取ります。

また、音声検索では「near me（近くの〇〇）」「〇〇のやり方」など質問型クエリが多く寄せられます。LocalBusinessスキーマやHowToスキーマは、音声検索の回答精度向上に貢献する可能性があります。

Googleの公式ブログ（2025年5月）でも、AI検索で成果を出すために構造化データのガイドライン遵守が推奨されています。
（出典: Google Search Central Blog – Succeeding in AI search）

【基礎知識③】構造化データの主な種類と具体例

GoogleがサポートするSchema.orgのタイプは100種類以上ありますが、SEO実務でとくに効果的な7種類を厳選して解説します。各タイプにはJSON-LDのコードサンプルを掲載しているので、そのままコピーして使えます。

種類を選ぶ際の基本原則は、ページの実際のコンテンツ内容に合致するタイプを選ぶこと。ページに存在しない情報を構造化データだけに書くと、Googleのガイドライン違反になります。

パンくずリスト（BreadcrumbList）

パンくずリストは、業種を問わずほぼすべてのWebサイトで実装が推奨される基本スキーマです。検索結果のURL部分にサイトの階層構造（例：ホーム > SEOブログ > 構造化データ）を表示します。

2024年9月以降、Googleデスクトップ検索での視覚的な表示は廃止されました。ただし、Search Consoleのレポートやクロール効率の改善への貢献は継続しており、実装の価値は変わりません。

以下がJSON-LDの基本サンプルです。

{
  "@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": "構造化データとは",
      "item": "https://example.com/seo/structured-data/"
    }
  ]
}

パンくずリストのさらに詳しい実装方法や構造化データとの連携については、パンくずリストとは？SEO効果を高める実装方法でも解説しています。

記事・ブログ（Article / BlogPosting）

ブログや記事ページに実装するスキーマです。大きなサムネイル画像・見出し・著者名・公開日が検索結果に表示され、クリック率（CTR）の向上が期待できます。

Googleガイドラインで定められた必須プロパティは headline と image の2つ。image を省略するとSearch Consoleでエラーが発生するため注意してください。また、datePublished はISO 8601形式（例：2025-01-15T09:00:00+09:00）で記述します。

Article・NewsArticle・BlogPostingの使い分けは次のとおりです。

• ニュース記事 → NewsArticle
• ブログ投稿 → BlogPosting
• 解説・まとめ記事 → Article

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "構造化データとは？SEO効果と実装方法を解説",
  "image": "https://example.com/images/structured-data.jpg",
  "author": {
    "@type": "Person",
    "name": "山田 太郎"
  },
  "publisher": {
    "@type": "Organization",
    "name": "WEBマーケティングの瓦版",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2025-01-15T09:00:00+09:00",
  "dateModified": "2025-06-01T12:00:00+09:00"
}

Article構造化データの詳細な仕様はGoogle Search Central「Article構造化データ」で公式確認できます。

FAQページ（FAQPage）

よくある質問（FAQ）ページに実装するスキーマです。かつては検索結果上でアコーディオン形式のQ&Aが展開されるリッチリザルトが表示されていました。

ただし、2023年8月以降、Googleは一般サイトでのFAQリッチリザルト表示を大幅に制限しており、現在は政府・医療機関などの限られたサイトのみを対象としています。一般サイトでは視覚的な恩恵を受けにくい状況です。

それでも実装価値は残っています。FAQPageスキーマはGoogleのコンテンツ理解を助けるほか、ChatGPTやPerplexityなどのAI検索で回答として引用されやすくなる効果（LLMO観点）が期待できます。

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "構造化データとは何ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "構造化データとは、検索エンジンがページの内容を正確に理解できるよう、決められた形式で情報を記述したコードのことです。"
      }
    },
    {
      "@type": "Question",
      "name": "構造化データの実装にはどのフォーマットが推奨されますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "GoogleはJSON-LDフォーマットを推奨しています。HTMLに直接書き込まず、scriptタグで別途追記できるため、非エンジニアでも管理しやすい形式です。"
      }
    }
  ]
}

商品（Product）

ECサイトや商品紹介ページで必須のスキーマです。価格・在庫状況・星評価が検索結果に直接表示されるため、購入意向の高いユーザーへのアプローチに効果的です。

採用サイト数は2020年の約59.4万サイトから2024年には約282万サイトへと475%成長しており、ECサイト運営者にとって実装は競合対策としても重要になっています。

星評価を検索結果に表示させるには、aggregateRating 内に ratingValue（評価値）と reviewCount（レビュー件数）の両方を記述する必要があります。どちらか一方だけでは星評価が表示されません。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "ワイヤレスイヤホン Pro",
  "image": "https://example.com/images/earphone-pro.jpg",
  "description": "ノイズキャンセリング搭載の高音質ワイヤレスイヤホン。防水等級IPX5対応。",
  "offers": {
    "@type": "Offer",
    "price": "12800",
    "priceCurrency": "JPY",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "128"
  }
}

additionalProperty プロパティを使うと、防水等級やチップセットなど独自仕様の詳細情報もGoogleに伝達できます。商品の差別化要素が多い場合に活用してみてください。

動画（VideoObject）

自社サイトに動画を掲載している場合に実装するスキーマです。サムネイル・再生時間・公開日が検索結果に表示され、動画コンテンツへの流入増加が期待できます。

再生時間（duration）はISO 8601形式で記述します。たとえば5分30秒であれば PT5M30S と表記します。また、contentUrl（動画ファイルのURL）か embedUrl（埋め込みURL）のどちらかを指定することで、Googleが動画の実体を認識しやすくなります。

{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "構造化データの実装方法を5分で解説",
  "description": "JSON-LDを使った構造化データの基本的な実装手順を動画で解説します。",
  "thumbnailUrl": "https://example.com/images/video-thumbnail.jpg",
  "uploadDate": "2025-01-15T09:00:00+09:00",
  "duration": "PT5M30S",
  "contentUrl": "https://example.com/videos/structured-data.mp4",
  "embedUrl": "https://www.youtube.com/embed/xxxxxxxx"
}

手順解説やレシピ系のコンテンツに動画を組み合わせると、VideoObjectリッチリザルトの効果がとくに高くなる傾向があります。

ローカルビジネス（LocalBusiness）

実店舗や特定エリアでサービスを提供する事業者向けのスキーマです。ローカル検索（Googleマップ連動）で住所・営業時間・電話番号が強調表示され、来店・問い合わせのきっかけになります。

Googleビジネスプロフィール（GBP）の情報とWebサイトの構造化データを一致させると、Googleからの信頼性が高まります。住所表記やビジネス名の表記ゆれに注意してください。なお、LocalBusiness・Organizationスキーマで自己レビューを記述することはGoogleガイドライン違反です。

• 実店舗・訪問型サービス → LocalBusiness
• オンライン専業・法人情報 → Organization

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "サンプル整体院 渋谷店",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "渋谷1-2-3",
    "addressLocality": "渋谷区",
    "addressRegion": "東京都",
    "postalCode": "150-0001",
    "addressCountry": "JP"
  },
  "telephone": "03-0000-0000",
  "openingHours": ["Mo-Fr 10:00-20:00", "Sa-Su 10:00-18:00"],
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": "35.6580",
    "longitude": "139.7016"
  },
  "priceRange": "¥¥"
}

MEO対策（地図検索エンジン最適化）と構造化データを組み合わせると、ローカル集客の効果がさらに高まります。詳しくはMEOとは何か？仕組みから対策方法まで徹底解説をご覧ください。

ハウツー（HowTo）／レシピ（Recipe）

手順解説コンテンツには HowTo、料理レシピには Recipe を使います。HowToのリッチリザルトはGoogleでの視覚的表示が廃止されていますが、ChatGPTやPerplexityなどのAI検索で手順コンテンツが引用されやすい傾向があり、HowTo構造化データがその精度を高める可能性があります。一方Recipeは、Googleのリッチリザルト（カロリー・調理時間・評価）が引き続き表示対応しています。

HowToを実装する際の注意点として、step に記述する内容はページ本文に実際に存在する手順と対応させてください。本文にない詳細をJSON-LDだけに記述すると、クローキング（検索エンジンとユーザーに異なる情報を見せる行為）とみなされるリスクがあります。

// HowTo のサンプル
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "構造化データをWordPressに実装する方法",
  "step": [
    {
      "@type": "HowToStep",
      "name": "プラグインをインストールする",
      "text": "WordPressの管理画面から「Yoast SEO」または「Rank Math」をインストールします。"
    },
    {
      "@type": "HowToStep",
      "name": "スキーマタイプを選択する",
      "text": "各ページの編集画面でスキーマタイプ（Article・FAQPageなど）を選択します。"
    },
    {
      "@type": "HowToStep",
      "name": "リッチリザルトテストで確認する",
      "text": "Google提供のリッチリザルトテストにURLを入力し、エラーがないか確認します。"
    }
  ]
}

// Recipe のサンプル
{
  "@context": "https://schema.org",
  "@type": "Recipe",
  "name": "基本のトマトパスタ",
  "image": "https://example.com/images/tomato-pasta.jpg",
  "recipeIngredient": [
    "パスタ 200g",
    "トマト缶 1缶",
    "にんにく 2片",
    "オリーブオイル 大さじ2"
  ],
  "recipeInstructions": [
    {
      "@type": "HowToStep",
      "text": "にんにくをオリーブオイルで炒め、トマト缶を加えて10分煮込みます。"
    },
    {
      "@type": "HowToStep",
      "text": "塩茹でしたパスタをソースと絡め、器に盛り付けます。"
    }
  ],
  "cookTime": "PT20M",
  "nutrition": {
    "@type": "NutritionInformation",
    "calories": "520 calories"
  }
}

【実装方法①】JSON-LDで記述する形式を理解する

構造化データの記述形式には、JSON-LD・Microdata・RDFaの3種類があります。Googleは公式ガイドラインでJSON-LDを推奨形式として明記しており、実装のしやすさと管理のしやすさが主な理由です。それぞれの特徴を整理したうえで、なぜJSON-LDが選ばれるのかを解説します。

JSON-LD・Microdata・RDFaの特徴

3つの形式は、いずれもGoogleが技術的にサポートしています。ただし、HTMLへの記述方法と管理のしやすさに大きな差があります。

形式	記述方法	管理のしやすさ
JSON-LD	HTMLと分離した<script>タグ内に記述	◎ 容易
Microdata	HTMLタグの属性として埋め込む	△ 煩雑になりやすい
RDFa	HTML属性内に記述	✕ 構文が複雑

実際の普及状況を見ると、JSON-LDの優位性は明らかです。WebDataCommonsの2024年調査によると、構造化データを実装するサイトのうちJSON-LDが約70%（約1,150万サイト）を占めています。一方、Microdataは約46%（約760万サイト）、RDFaはわずか約3%（約40万サイト）にとどまっており、JSON-LDが業界標準として定着しています。

Googleは「3形式はGoogleにとって同等であり、正しく実装されていればどれでもよい」とも補足しています。技術的にはどの形式でも認識されますが、実務上はJSON-LDを選ぶのが合理的な判断です。

GoogleがJSON-LDを推奨する理由

Google Search Centralは、JSON-LDを推奨する理由を「サイトオーナーが実装・大規模メンテナンスをしやすく、ユーザーエラーが少ないため」と明記しています。HTMLと分離しているため、デザイン変更やCMS更新の影響を受けません。<script>ブロックを追加・更新するだけで済むので、既存のHTML構造を一切触らずに実装できます。

また、WordPressの主要SEOプラグイン（Yoast SEO・All in One SEO・Rank Mathなど）はすべてJSON-LD形式で出力します。プラグインを使えばコーディング不要で導入できる点も、非エンジニアにとっては大きなメリットです。

JavaScriptで動的にJSON-LDを注入する実装は、Googlebotがレンダリングできない場合があります。サーバーサイドでHTMLに静的に埋め込む方法が推奨されており、この点は実装時の注意点として覚えておいてください。

(出典: Google Search Central – Introduction to structured data markup（Supported Formats）)

【実装方法②】JSON-LDコードの作成方法

JSON-LDコードの作成には「手動記述」「ツール活用」「生成AI活用」の3つのアプローチがあります。初心者はツールや生成AIから始めて、慣れてきたら手動記述に移行するのがおすすめです。

HTMLに直接記述する方法

<head>タグ内、または<body>の末尾に<script type="application/ld+json">ブロックを配置するのが基本的な構文です。以下は Article タイプの記述例です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事のタイトル",
  "author": {
    "@type": "Person",
    "name": "著者名"
  },
  "datePublished": "2025-01-15T09:00:00+09:00",
  "image": "https://example.com/images/article.jpg"
}
</script>

記述時に守るべきルールが3点あります。

• URLはすべてきっとURL（例：https://example.com/）で記述する
• 日時はISO 8601形式（例：2025-01-15T09:00:00+09:00）を使う
• 1ページに複数タイプを入れる場合は<script>タグを分けるか、配列で記述する（どちらも有効）

手動記述の最大のメリットは自由なカスタマイズができる点ですが、カンマ抜けやスペルミスがリッチリザルト未表示の最多原因になります。記述後はぜひ検証ツールでチェックしてください。

1ページに複数の<script type="application/ld+json">タグを置いても問題ありません。タイプごとに分けて管理するほうが可読性が高まります。

構造化データマークアップ支援ツールを使う方法

コードを一から書かずに済むツールを活用すると、記述ミスのリスクを大幅に減らせます。主要ツールの特徴は以下のとおりです。

ツール名	主な用途
Googleリッチリザルトテスト	実装前・実装後のコード検証
Schema Markup Validator	schema.org規格への準拠確認（Google非対応タイプも検証可）
構造化データ マークアップ支援ツール	ページ上で要素を選択するだけでJSON-LDのベースコードを自動生成
Merkle Schema Markup Generator	Product・Article・FAQなどをGUI入力だけで生成

ツールで生成したコードも、ぜひリッチリザルトテストで検証してから公開してください。自動生成だからといって完璧とは限らず、サイト固有の情報が抜け落ちることがあります。

GoogleリッチリザルトテストはコードをURLで検証するだけでなく、コードを直接貼り付けて検証する機能もあります。公開前の確認に活用しましょう。

生成AIを活用して作成する方法

ChatGPT・Gemini・Claudeなどの生成AIにページ内容を貼り付けてJSON-LDを生成させる方法は、競合サイトでほとんど紹介されていない効率的なアプローチです。ページの本文をそのまま渡すと、各プロパティの値を自動で埋めてくれます。

以下のようなプロンプトが実用的です。

以下のWebページ内容を元に、@type: Article のJSON-LDを
schema.orgの仕様に沿って生成してください。
必須プロパティ（headline・image・author・datePublished）を含め、
日時はISO 8601形式で出力してください。

【ページ内容】
（ここに記事本文やページ情報を貼り付ける）

生成AIはハルシネーション（架空プロパティの出力）リスクがあります。URLが実在するか・日時フォーマットが正しいか・必須プロパティが揃っているかをぜひ確認してください。

【実装方法③】構造化データの実装手順

構造化データの実装は、選定・作成・テスト・設置・監視の5ステップで完結します。手順を飛ばさず順番に進めることで、エラーを未然に防ぎ、リッチリザルト獲得への最短ルートを歩めます。

ステップ1：ページに合った種類を選ぶ

まず、ページの「主目的」に合致するタイプを選ぶことが大原則です。ページの実際の内容と関係のないタイプを選ぶと、Googleのガイドライン違反となります。

以下の早見表を参考に、自サイトのページ種別に合うタイプを確認してください。

ページの種類	推奨タイプ
記事・ブログ	Article / BlogPosting
商品ページ	Product
よくある質問	FAQPage
実店舗・地域ビジネス	LocalBusiness
動画コンテンツ	VideoObject
手順解説	HowTo
レシピ	Recipe
サイト全体（全ページ推奨）	BreadcrumbList

複数タイプの併用も可能です。たとえばECページにProductとBreadcrumbList、さらにOrganizationを組み合わせるケースは珍しくありません。

初めて実装する場合は、まず1種類から始めるのがおすすめです。実績を確認しながら段階的に追加すると、トラブルが起きた際に原因を特定しやすくなります。

ステップ2：JSON-LDコードを作成する

コードの書き方は、前のセクション「JSON-LDコードの作成方法」で詳しく解説しています。ここでは設置前に最低限チェックすべき項目を確認してください。

• 必須プロパティがすべて揃っているか
• URLはきっとURL（https://から始まる形式）で記述しているか
• 日時はISO 8601形式（例：2024-06-01T09:00:00+09:00）になっているか
• ページ本文に実際に記載されている内容のみを記述しているか

ステップ3：テストツールでエラーがないか確認する

コードを作成したら、サイトに設置する前にテストツールでぜひ検証します。このステップを省略すると、数か月間エラーに気づかないリスクがあります。

使用するツールは2つです。まずGoogleリッチリザルトテストでURLかコードを直接入力し、「リッチリザルトが表示可能」と判定されればOKです。エラーや警告があれば修正してください。

次にSchema Markup Validatorで、schema.org規格への準拠を確認します。Googleのテストとは別の観点でチェックしてくれるため、両方を使うのが理想的です。

• Googleリッチリザルトテストでリッチリザルト表示の可否を確認
• Schema Markup Validatorでschema.org規格への準拠を確認

ステップ4：サイトにコードを設置する

テストで問題がなければ、いよいよサイトに設置します。サイトの構築方法によって手順が異なります。

WordPressの場合（プラグイン活用）

WordPressであれば、SEOプラグインを使うことでほぼノーコードで構造化データを出力できます。代表的なプラグインは以下の3つです。

• Yoast SEO：世界最多インストール数。Article・BreadcrumbListなど基本スキーマを自動出力
• All in One SEO：直感的なUIで操作しやすい
• Rank Math：多彩なスキーマに対応し、無料版でも高機能

プラグインを複数導入すると重複スキーマが発生し、意図しない表示や評価低下のリスクがあります。構造化データを出力するプラグインはぜひ1つに絞ってください。

プラグインが自動出力するスキーマとは別に、カスタムの構造化データを追加したい場合は、HTMLカスタムブロックまたはfunctions.phpに記述する方法があります。

静的サイト・自社開発サイトの場合

<head>内または</body>直前に、以下のような<script type="application/ld+json">ブロックを挿入します。

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

フロントエンドJavaScriptによる動的注入は、Googlebotがレンダリングできないケースがあるためおすすめできません。動的に差し込む場合は、サーバーサイドレンダリングで実装するのが安全です。

CMSテンプレート（WordPressのsingle.phpやheader.phpなど）にPHPで記述し、記事タイトル・投稿日などを動的変数で出力すると一括管理が容易になります。

ステップ5：Google Search Consoleでインデックス状況を監視する

設置が完了したら、Google Search Console（以下GSC）で継続的に状況を確認します。GSCの左メニュー「拡張」レポートから、実装した構造化データタイプのインデックス状況とエラー数を確認してください。

エラーがある場合、対象URLのリストが表示されます。修正後は「URL検査」→「インデックス登録をリクエスト」でGoogleに再クロールを促しましょう。

リッチリザルトが検索結果に表示されるまでには、数日〜数週間かかることがあります。設置直後に表示されなくても、しばらく様子を見てください。

GSCのパフォーマンスレポートでは、リッチリザルトの表示有無によるCTR（クリック率）の差異も確認できます。効果の継続的な計測に活用してください。

(出典: Google Search Central – Introduction to structured data markup)

【検証・運用①】構造化データの検証ツールと確認方法

構造化データは実装して終わりではなく、正しく認識されているかを検証することが重要です。検証ツールは「公開前」と「公開後」で使い分けるのが効率的で、役割の異なる3つのツールを組み合わせることで抜け漏れを防げます。

リッチリザルトテスト（Google公式）

GoogleがリッチリザルトとしてページをSERP（検索結果ページ）に表示できるかを判定する、最も信頼性の高い公式ツールです。URLを入力するほか、コードを直接貼り付けて検証することもできます。

スマートフォン用・PC用それぞれのGooglebotに切り替えて確認できる点も便利です。

• ツール（https://search.google.com/test/rich-results）にアクセス
• URLを入力、またはコードを貼り付け
• 「テストを実行」をクリック
• 「リッチリザルトが表示可能」と表示されればOK。エラーや警告がある場合は詳細を確認して修正

Schema Markup Validator（schema.org公式）

schema.orgが定義するすべての構造化データの構文を検証できるツールです。旧「構造化データテストツール」の後継として、2021年5月にschema.orgの管理のもとで公開されました。

Googleがリッチリザルトとして未対応のスキーマタイプでも検証できるため、リッチリザルトテストでは確認できないスキーマを補完する役割を担います。

• ツール（https://validator.schema.org/）にアクセス
• URLを入力して「Run Test」をクリック
• JSON-LDが正しく認識されているか、どのスキーマタイプが適用されているかを確認

このツールは構文の正誤を確認するものです。「実際に存在するURLか」などの値の正当性チェックは行いません。リッチリザルトテストと組み合わせて使いましょう。

Google Search Consoleの「拡張」レポート

サイト公開後の継続監視に適したツールです。Search Console左メニューの「拡張」から、実装したスキーマタイプ（FAQページ・パンくずリストなど）を選択すると、サイト全体のエラー・警告・有効ページ数を一括で確認できます。

エラーをクリックすると影響を受けているURLの一覧が表示されるため、大規模サイトでの問題箇所の特定に特に役立ちます。

エラーを修正したら、URL検査ツールで「インデックス登録をリクエスト」してGoogleに再クロールを依頼しましょう。エラー解消後は数日〜数週間でリッチリザルトの表示が始まります。

実装直後はリッチリザルトテストで即時確認し、1週間後はSearch Consoleの拡張レポートで実際の表示状況を確認するフローが効率的です。

【検証・運用②】実装時の注意点とガイドライン違反を防ぐ方法

正しく実装しないと、リッチリザルトが表示されないだけでは済みません。Googleのガイドライン違反と判定された場合、手動ペナルティ（Manual Action）の対象となり、検索順位に影響するリスクがあります。

ここでは、非エンジニアのWeb担当者が陥りやすい違反パターンを具体的に示しながら、実装時の注意点を解説します。

ページの実際の内容と一致した情報のみを記述する

Googleガイドラインの大原則は「ユーザーに見えないコンテンツをマークアップしてはいけない」ことです。JSON-LDに記述した情報がページ本文に存在しない場合、クローキング（ユーザーとGoogleに異なる情報を見せる行為）とみなされるリスクがあります。

また、価格・在庫・日時など時間経過で変化する情報は定期的な更新が欠かせません。古い情報が残っていると、Googleが時間感応型リッチリザルトの表示を停止することがあります。

過剰・不正確なマークアップはGoogleガイドライン違反になる

Googleガイドラインは「違反のある構造化データはリッチリザルトの対象外になるだけでなく、スパムとしてマークされる可能性がある」と明示しています。悪意がなくても実装の誤りがペナルティにつながる点に注意が必要です。

また、SEOプラグインを複数同時に有効化していると、同一ページに重複スキーマが出力されてGoogleに誤情報を伝えるケースがあります。プラグインの構造化データ出力設定はぜひ1つに絞りましょう。

ガイドライン違反が確認されると、手動による対策（Manual Action）としてリッチリザルトからの除外やランキングへの影響が発生する可能性があります（Google Search Central – 構造化データに関する一般的なガイドラインに明記）。

【検証・運用③】実装後に必要な定期メンテナンス

構造化データは「一度入れたら終わり」ではありません。Googleはリッチリザルトの必須プロパティやサポートするタイプを定期的に更新するため、継続的な対応が求められます。

WordPressのプラグイン更新・テーマ変更・CMS移行などをきっかけに構造化データが壊れるケースも珍しくありません。変更後はぜひリッチリザルトテストで再検証する習慣をつけましょう。

2023年8月のFAQリッチリザルト表示制限のように、従来有効だったスキーマの効果がGoogleの仕様変更で突然変わることがあります。最新情報の継続的なキャッチアップが欠かせません。

よくある質問

構造化データについて、初めて取り組む方からよく寄せられる疑問をまとめました。実装前の不安を解消するために、ポイントを絞って回答します。

まとめ

構造化データは、検索エンジンやAIにWebページの内容を正確に理解させるためのメタデータ記述形式です。Schema.orgを共通語彙として使い、JSON-LD形式で記述するのが現在の標準です。正しく実装すれば、リッチリザルト獲得によるCTR（クリック率）向上はもちろん、AI検索への引用可能性も高まります。

実装の流れは、種類の選定→JSON-LDの作成→テストツールでの検証→サイトへの設置→Search Consoleでの監視、という5つのステップで進めます。難しく見えますが、1種類から始めれば十分です。

まず取り組むべき具体的なアクションは、自サイトのカテゴリに合った種類を1つ選ぶことです。

• 記事・ブログサイトなら Article / BlogPosting
• ECサイト・商品ページなら Product
• 店舗・地域ビジネスなら LocalBusiness

選んだら、JSON-LDを作成してリッチリザルトテストで動作を確認し、問題がなければ公開してみましょう。小さな一歩が、検索結果での存在感を大きく変えます。

AI検索（AI Overview）が検索結果の50%超に表示される時代において、構造化データはリッチリザルト獲得だけが目的ではありません。AI Overviewへの引用やナレッジグラフへの反映を通じて、ブランドの検索上の存在感そのものを高める施策として、その重要性はさらに増しています。