構造化データとは？SEO・AI検索での役割とサイト別の実装方法

構造化データは、ページに書かれている内容が何を指すのかを機械が読める形で明示するラベルです。本記事では、BtoBサイトで先に入れるべき型、検証ツールでの確認手順、そして実装しても成果が出ない原因を、自社サイトで実際に起きた事例とあわせて解説します。

【この記事の結論】 

・構造化データは「機械が読むためのラベル」

・実装しただけではAIに引用される理由にはならない 

・AI検索で根拠として使われるには、構造化データと同じ情報を本文にも書く必要がある 

・BtoBサイトで先に実装する型はOrganization・Service・Articleの3つ。FAQPageはリッチリザルトが廃止されたが削除不要 

・自社の公式サイトでAIクローラーが本文を取得できていない事象が確認された（2026年8月）。構造化データの検証ツールではこの問題は検出されない 

・実装後の確認は3段階で行う：①Schema Markup Validator → ②リッチリザルトテスト → ③Search Console

構造化データは検索エンジンに「このページは何の情報か」を伝える

構造化データは、ページに書かれている内容が何を指すのかを機械が読める形で明示するラベルです。名前・価格・著者・日付といった情報をSchema.orgで定義された項目名と値の組として記述することで、検索エンジンやAIがページの意味を個別に解釈せず、確実に読み取れるようになります。

会社・商品・記事などの情報を検索エンジンが理解しやすくなる

検索エンジンに対しては、リッチリザルトとして表示される要素を判定するための材料になります。会社概要ページにOrganization型を実装すれば社名・所在地・連絡先が構造化され、商品ページにProduct型を入れれば価格や在庫ステータスが検索結果上に表示される対象になります。記述の正確さが表示の前提になるため、実態と一致した値を書くことが大前提です。

AI検索でも大事なのは構造化データだけではない

AI検索に対しては、料金・提供者・対象といった項目の切り分けを助け、回答の根拠として抽出しやすくなる可能性があります。ただし、構造化データが正しく実装されていても、同じ情報が本文にテキストとして書かれていない場合、AIは根拠として採用しにくい状態になります。構造化データは「機械が読むためのラベル」であり、本文は「AIが根拠として引用するコンテンツ」という役割の違いを理解しておくことが重要です。

普通の文章との違いは情報の意味を明確にできること

本文の散文が非構造化データであるのに対し、構造化データは同じ内容を項目名と値の組にそろえたものです。たとえば「東京都渋谷区に本社を置くWeb制作会社です」という文章は人が読めば意味がわかりますが、機械が「東京都渋谷区」を住所として、「Web制作会社」を業種として確実に切り出すには、addressや@typeという項目名に紐づけた記述が必要です。構造化データはこの「意味の明示化」を担います。

出典：Google 検索セントラル「構造化データ マークアップをテストする」

https://developers.google.com/search/docs/appearance/structured-data?hl=ja

使う構造化データはサイトの種類によって変わる

入れるべき構造化データの型はサイトの目的ごとに異なり、BtoBサイトとECサイトでは先に実装する型が入れ替わります。すべての型を一度に実装しようとすると更新負荷が増えるため、自社サイトの目的に合う型から優先して入れるのが実務的です。

BtoB企業サイトはOrganizationやArticleを中心に考える

BtoBサイトでは、会社の実体を固定するOrganization、提供内容を明示するService、書き手と日付を示すArticleの3つを先に入れます。Organizationは社名・所在地・連絡先・公式URLを1か所に固定し、外部情報との突き合わせの基準点になります。ServiceはAIが提供内容を切り分ける際に直接参照するため、対象企業規模・対応地域・料金レンジをプロパティとして書ける箇所から埋めていきます。

ECサイトはProductやOfferで商品情報を伝える

ECサイトでは、商品名と仕様を示すProduct、価格と在庫を示すOffer、レビュー評価を示すAggregateRatingが中心になります。Offerに在庫ステータスを書くと、検索結果での表示内容に直結するため実態との一致が必須です（記法例：https://schema.org/InStock）。AggregateRatingは口コミ件数と平均評価をセットで記述し、件数が少ない段階での実装は控えることをおすすめします。

採用サイトはJobPosting、店舗サイトはLocalBusinessを使う

採用サイトは求人情報を示すJobPosting、実店舗を持つサイトは所在地と営業時間を示すLocalBusinessが対象になります。JobPostingは掲載期限（validThrough）が切れるとSearch Console上で警告が発生する場合があるため、求人が終了したタイミングで取り下げるか、掲載期限を更新する運用ルールを事前に決めておきます。LocalBusinessはGoogleビジネスプロフィールの情報と一致させることが重要です。

FAQPageのリッチリザルトはGoogle検索で廃止された

GoogleはFAQのリッチリザルト表示を2026年5月7日に終了し、リッチリザルトレポートとリッチリザルトテストのサポートも2026年6月に終了したため、FAQPageは表示目的ではなく質問と回答の対をAIに渡す目的で使える可能性があります。Googleは公式ドキュメントで「FAQPage構造化データを積極的に削除する必要はない」と明記しており、既存の実装を急いで削除する必要はありません。新規に実装する場合は、リッチリザルト目的ではなくAIへの情報提供目的として設計します。

出典：Google 検索セントラル「Google 検索のアップデートに関する最新情報」https://developers.google.com/search/blog

以下の表に、サイト種別ごとに先に実装すべき型と注意点をまとめます。

サイト種別	先に入れる型	何を明示するか	対象ページ	注意点
BtoB企業サイト	Organization / Service / Article	社名・所在地・提供内容・著者・更新日	会社概要・サービスページ・コラム	FAQPageはリッチリザルト廃止済み。AI向けに質問と回答の対を渡す目的で使える場合があります
ECサイト	Product / Offer / AggregateRating	商品名・仕様・価格・在庫・レビュー評価	商品ページ・カテゴリページ	Offerの在庫ステータス（例：schema.org/InStock）は実態と一致させる
採用サイト	JobPosting	求人タイトル・給与・雇用形態・勤務地・掲載期限	求人一覧・求人詳細ページ	掲載期限（validThrough）が切れると警告が発生する場合があります
実店舗サイト	LocalBusiness	店名・所在地・電話番号・営業時間	店舗詳細・アクセスページ	NAP（名称・住所・電話）をGoogleビジネスプロフィールと一致させる

※各型の詳細仕様はGoogle検索セントラルの公式ドキュメントで確認してください。

構造化データは入れたあとに正しく読まれているか確認する

実装後の確認は、スキーママークアップ検証ツールで文法を、リッチリザルトテストで表示要件を、Search Consoleで検出状況を見る3段階で行います。この3段階を順に通すことで、記述の文法エラー・必須プロパティの欠落・実際の検出漏れをそれぞれの段階で発見できます。

スキーママークアップ検証ツール（Schema Markup Validator）で記述ミスを確認する

スキーママークアップ検証ツール（Schema Markup Validator）は記述の文法エラーを検出するため、公開前の最終確認として使います。URLまたはHTMLコードを貼り付けるだけで動作し、型・プロパティ名の誤りや値の形式ミスを一覧で表示します。ここでエラーが出た状態では、以降のリッチリザルトテストで正確な結果が得られないため、先にこのツールで文法を通してから次に進みます。

リッチリザルトテストでGoogleの対応状況を確認する

リッチリザルトテストはGoogleが表示要件として必須にしているプロパティの欠けを確認できますが、FAQについては2026年6月にサポートが終了しています。Product・JobPosting・Article など現在もリッチリザルトの対象となっている型は、このツールで「リッチリザルトの対象かどうか」と「必須プロパティが揃っているか」を確認します。警告と必須エラーは区別が必要で、必須エラーは表示に影響します。

出典：Search Console ヘルプ「リッチリザルト テスト」

https://support.google.com/webmasters/answer/7445569?hl=ja

Search Consoleで検出状況やエラーを追う

Search Consoleの拡張レポートは、公開後に構造化データが実際に検出されているかを継続的に確認できます。「拡張機能」メニュー配下に型ごとのレポートがあり、有効・警告・エラーの件数の推移を追えます。リッチリザルトテストでOKが出ていてもSearch Consoleで検出されていない場合は、クロール頻度が低い・JavaScriptレンダリングの影響・サイトマップの未送信などが原因として考えられます。

構造化データを入れても成果が出ない3つの原因

実装が正しくても成果が出ない場合、原因は本文の記述不足、レンダリング方式、型の入れすぎのいずれかに集約されます。これら3つは検証ツールでは検出されないため、担当者が個別に確認する必要があります。

本文と構造化データの内容がそろっていない

構造化データにしか存在しない情報は根拠として扱われにくく、同じ内容を本文にもテキストで書く必要があります。たとえば、Serviceの料金プロパティに価格帯を記述しても、ページ本文にその価格帯が一切書かれていない場合、AIは根拠として採用する情報が本文上にないと判断します。構造化データの項目を埋めたタイミングで、同じ情報を本文にも追記することをセットで行うのが最も確実な方法です。

JavaScriptの影響で本文を正しく取得できていない

本文をJavaScriptで描画するサイトは取得時に中身が返らないことがあり、構造化データ以前に読まれていない状態になります。ノーコードツールや特定のCMS・フロントエンドフレームワークはクライアントサイドレンダリングを採用していることが多く、AIクローラーがHTMLを取得した時点では本文テキストがまだ生成されていないケースがあります。この状態では構造化データを正しく実装していても、根拠として使われる本文が存在しない状態になります。

構造化データを増やしすぎて更新が追いついていない

型を増やすほど更新漏れが起き、料金改定後も古い値が残るとかえって誤った情報を渡すことになります。実装できる型を増やすことよりも、実装した型の値を常に最新の状態に保つほうが重要です。管理する型が多くなるほど料金改定や拠点移転のタイミングで更新漏れが発生しやすくなります。アムールの支援現場では、まず2〜3型を確実に運用できる体制を作り、安定したら追加するという順序を推奨しています。

構造化データが正しくても本文を読まれていないことがある

自社の公式サイトで構造化データ以前に本文が取得時に返っておらず、最も情報量の多いページがAI側から読めていませんでした。構造化データの検証ツールではこの問題は検出されません。AIクローラーが取得したHTMLに本文テキストが含まれているかを直接確認することが、原因特定の最短経路です。

ノーコードサイトで本文を正しく取得できていなかった事例

ノーコードのサイト構築サービスで作った公式サイトが、取得時にメタタグだけを返し、本文が返らない状態になっていました。このサービスはクライアントサイドレンダリングを採用しており、JavaScriptが実行されて初めて本文が生成される仕組みになっていました。AIクローラーはJavaScriptを実行せずに静的HTMLのみを取得する場合があるため、本文が全く存在しない状態のHTMLが返ってきていました。

AIが自社サイトではなく比較サイトの情報だけを参照していた

AIに自社を問う質問を投げても社名が挙がらず、外部の比較サイトに書かれた記述だけが参照されていたことから逆算して発覚しました。自社サイトの本文が取得できていなければ、AIが参照できる自社情報は第三者メディアに書かれた内容のみになります。このケースでは比較サイトに掲載されていた古い料金情報や簡略化された説明が参照され、実際のサービス内容と異なる情報が回答に使われていました。

取得されたHTMLを見れば同じ問題がないか確認できる

ブラウザではなく取得時のHTMLを直接確認し、本文テキストが含まれているかを見れば、同じ状態にあるかどうかが判定できます。ブラウザのデベロッパーツールで「ページのソースを表示」するとJavaScript実行後のDOMが見えますが、クローラーが取得するのはJavaScript実行前の静的HTMLです。curlコマンドやGoogle Search ConsoleのURL検査ツールで「HTMLを取得」した結果を確認すると、クローラー視点でのHTMLが確認できます。

構造化データは「入れて終わり」にしない

構造化データは一度入れて終わりではなく、料金やサービス内容の変更に合わせて更新する担当を決めておく必要があります。更新が遅れた構造化データは古い情報を提供し続けることになり、AIが誤った情報を根拠として採用するリスクにつながります。

料金・サービス名・住所を変えたら構造化データも更新する

料金改定・サービス名変更・拠点移転の3つを更新トリガーとして定めると、実際の改定に追随できます。この3つは公式サイトの文言変更と同時に構造化データも更新が必要なため、変更作業のチェックリストに「構造化データの更新」を明記しておきます。担当者が制作会社の場合は、変更依頼のフォーマットに構造化データ更新を項目として加えることで、漏れを防げます。

制作会社には対象ページと実装する型まで具体的に伝える

制作会社へは「構造化データを入れてほしい」ではなく、対象ページと型、必須プロパティまで指定して依頼します。「トップページとサービスページにOrganization型とService型を実装し、name・url・description・provider・areaServedを必須プロパティとして書く」という粒度で伝えると、意図と異なる実装を防げます。依頼後はリッチリザルトテストとSearch ConsoleのURLでそれぞれ確認することを依頼時点で伝えておきます。

本文と構造化データをそろえたことで問い合わせにつながった事例

都内のカウンセリングルームでは、FAQを構造化データと本文の両方でそろえたことで、AI／Google経由の問い合わせが月2〜3件から6〜8件になりました。この事例では、FAQページにFAQPage型を実装するとともに、質問文と回答文をページ本文にも同じ内容でテキスト記述しました。構造化データが提供する情報と本文が提供する情報の両方がそろったことで、情報を取得しやすい状態になり、問い合わせ増加につながったと考えられます。

構造化データについてよくある質問

構造化データの実装可否や優先度について、担当者から実際に寄せられる質問をまとめます。

構造化データを入れると検索順位は上がりますか

構造化データは表示要素の判定に使われるもので、それ自体が順位を押し上げる仕組みではありません。Googleの公式ドキュメントでも、構造化データがランキングシグナルとして機能することは明示されていません。ただし、リッチリザルトとして表示されることでCTRが上がる場合があり、間接的に流入増につながることはあります。また、AI検索での引用されやすさに寄与する可能性があるという観点では、適切な実装が長期的に価値を持つ場合があります。

FAQPageの構造化データは削除した方がよいですか

Googleはリッチリザルト廃止後もFAQPage構造化データを積極的に削除する必要はないと公式ドキュメントで明記しています。リッチリザルトとしての表示目的での新規実装は意味がなくなりましたが、既存の実装を削除する必要もなく、AIへの情報提供という目的では有効な場合があります。新規にFAQPageを実装する場合は、「AIが質問と回答の対を参照できる状態を作る」という目的で設計します。

JSON-LDとMicrodataはどちらを使うべきですか

本文のHTMLと分離して管理できるJSON-LDのほうが、更新時の事故が起きにくくなります。MicrodataはHTMLタグ内に直接属性を書く方式のため、デザインの変更やCMSのテンプレート更新のタイミングで誤って消えてしまうリスクがあります。JSON-LDは<script>タグとして独立して管理できるため、HTMLの変更に影響されにくく、担当者が変わっても確認しやすい構造を保てます。

実装してからGoogleに認識されるまでどのくらいかかりますか

検出はクロール頻度に依存するため、Search Consoleの拡張レポートで実際の検出状況を確認します。反映までの時間はサイト規模・クロール頻度・技術的な状態などにより異なり、Google公式も一律の期間を保証していません。Search ConsoleのURL検査ツールで対象URLを入力し「インデックス登録をリクエスト」することでクロールを促せます。

まとめ｜構造化データはサイトに合うものを選び、本文とそろえて使う

構造化データはサイトの種類ごとに入れる型を選び、検証ツールで確認したうえで同じ情報を本文にも書き、更新担当まで決めて運用します。スキーママークアップ検証ツール（Schema Markup Validator）→リッチリザルトテスト→Search Consoleの3段階で確認し、本文との整合を取り続けることが、AI検索で参照される状態を維持するための基本的な運用です。

実装が完了したら、自社サイトの主要ページを検証ツールにかけてエラーの有無と本文側の記述のズレを洗い出すことを、次のアクションとして進めてください。

アムールでは、AI検索上の現状診断の無料相談を受け付けています。想定される質問文を設計し、現時点で自社名が挙がるかどうかを測るところから対応していますので、お気軽にご相談ください。

アムール株式会社 公式サイト

トップページ