Google の AI Overviews や AI Mode など、生成 AI を使った検索機能が広がるなかで、「構造化データを追加すれば、AI に引用されやすくなるのでは」と考える方もいると思います。
先に結論をお伝えすると、構造化データを追加すれば AI 検索での引用が増える、と確認できる公式情報はありません。少なくとも Google は、AI Overviews や AI Mode に表示されるための特別な構造化データは必要ないと説明しています。
一方で、構造化データそのものに意味がないわけでもありません。記事、著者、事業者、公開日などの情報を決められた形式で表し、検索エンジンがページの内容や関係を理解する手がかりにできます。
僕は、構造化データを「AI に引用されるための裏技」ではなく、人が確認できる情報を、検索エンジンにも正確に伝えるための仕組みとして考えるのがよいと思っています。
この記事では、構造化データと AI 検索の関係、事業サイトで検討しやすい種類、WordPress で確認したい重複や不一致について整理します。
構造化データとは何か
構造化データは、ページに掲載している情報の種類や属性を、機械が処理しやすい決められた形式で表したデータです。
たとえば、ブログ記事には次のような情報があります。
- 記事のタイトル
- 著者
- 公開日と更新日
- 記事を公開している事業者
- 記事の URL
- 記事を表す画像
人がページを読めば、それぞれの意味を前後の文脈や見た目から判断できます。しかし、検索エンジンにとっては、どの文字列が著者名で、どの日付が更新日なのか、HTML だけでは曖昧な場合があります。
そこで、Article、Person、Organization などの語彙を使い、情報の意味や関係を表します。広く使われている語彙が Schema.org であり、Google が多くの場合に推奨している記述形式が JSON-LD です。
Google の構造化データに関する案内では、構造化データをページ内容の情報を提供し、ページの内容を分類するための標準化された形式として説明しています。Google は JSON-LD、Microdata、RDFa を扱えますが、実装や保守をしやすく、入力ミスも起こりにくい形式として、一般に JSON-LD を推奨しています。
ただし、構造化データは人が読む本文の代わりにはなりません。本文にない情報を構造化データへ足すのではなく、ページ上で確認できる情報を機械可読化するのが基本です。
構造化データで AI 検索の引用は増えるのか
現時点では、構造化データの追加によって AI 検索での引用が増えるとは断定できません。
Google は AI features and your website で、AI Overviews や AI Mode に補助リンクとして表示されるための追加要件や特別な最適化はないと説明しています。ページが Google 検索にインデックスされ、スニペットを表示できる状態であることが技術的な前提です。
同じ案内では、AI 機能のために新しい機械可読ファイルや特別なマークアップを用意する必要はなく、専用の Schema.org 構造化データも不要だと明記されています。
つまり、次のような説明は避けた方がよいでしょう。
- 構造化データを入れると AI に引用されやすくなる
JSON-LDを追加すれば、AI が内容を正しく理解する- FAQ の構造化データが AI の回答材料になる
- 構造化データは AI 検索対策の必須項目である
AI 検索がどのページを参照するかは、利用者の質問、ページの内容、クロールやインデックスの状態、検索サービス側の仕組みなど、複数の条件に左右されます。各サービスの選択方法がすべて公開されているわけでもなく、構造化データだけの影響を分けて測ることも簡単ではありません。
そのため、構造化データについては次の3つを分けて考える必要があります。
| 分類 | 現時点での整理 |
|---|---|
| 確認できていること | 検索エンジンがページ、記事、著者、組織などを理解する手がかりになる |
| 条件によって期待できること | 対応する検索機能やリッチリザルトの表示対象になり得る |
| 確認できていないこと | AI 検索での引用件数や引用される確率が直接上がること |
「検索エンジンへ情報を伝えやすくすること」と「AI 検索に引用されること」は、同じではありません。
それでも構造化データを導入する価値
AI 検索への直接的な効果を確認できなくても、構造化データには通常の検索やサイト運用における実務的な価値があります。
ページと情報の関係を伝えられる
構造化データを使うと、このページが記事であること、その著者が誰であるか、どの事業者が公開しているかといった関係を明示できます。
Google も、構造化データをページ内容を理解するために使い、その情報をもとに検索結果へリッチリザルトを表示する場合があると説明しています。
ただし、Google の構造化データに関する一般ガイドラインでは、正しく実装しても検索結果への表示は保証されないことが明記されています。構造化データに問題があった場合の手動対策も、通常のウェブ検索順位ではなく、リッチリザルトの表示資格に関係するものです。
構造化データは、検索順位を直接上げるための設定というより、検索エンジンによる情報理解と検索結果表示を補助する仕組みとして捉えた方が分かりやすいでしょう。
情報の不一致を見つける確認項目になる
構造化データを設計すると、本文、著者プロフィール、サイト設定、公開日、更新日などの情報をどこから取得するか考える必要があります。
たとえば、画面には個人名が著者として表示されているのに、構造化データでは事業者名が author になっていれば、情報の不一致に気づけます。サイト上の屋号と Organization の name が異なる場合も同様です。
WordPress の投稿データ、ユーザー情報、サイト設定など、同じ情報源から画面表示と構造化データを生成できれば、修正箇所を減らしやすくなります。反対に、本文とは別に構造化データを毎回手入力すると、更新漏れや矛盾が起きやすくなります。
保守性を左右するのは JSON-LD という形式そのものではなく、画面表示と同じ情報源から無理なく生成できる設計かどうかです。
アクセシビリティとは分けて考える
構造化データとセマンティックな HTML は、どちらも情報の意味を機械へ伝えるために使われますが、役割は同じではありません。
JSON-LD を追加しても、見出しの階層、ナビゲーション、フォームのラベル、画像の代替テキストなどが改善されるわけではありません。
W3C のページ構造に関する案内では、HTML と WAI-ARIA を使ってページの領域や見出し、内容の構造を示すことが、利用者の移動や理解を助けると説明しています。
アクセシビリティのためには、適切な見出し、main、nav、article、リスト、表などを内容に応じて使うことが先です。構造化データは、その代わりになるものではありません。
事業サイトで検討しやすい構造化データ
Schema.org には多くの型がありますが、使えるものをすべて追加する必要はありません。ページに実際に存在し、継続して正確に管理できる情報を選びます。
Organization または LocalBusiness
Organization は、事業者名、URL、ロゴ、所在地、連絡先、公式プロフィールなど、組織に関する情報を表す型です。
Google の Organization に関する案内では、ホームページへ組織の構造化データを追加することで、組織の情報を理解し、同名の組織と区別する助けになると説明しています。ロゴなど、検索結果の表示に影響する可能性がある項目もあります。
実装時は、次のような点を確認します。
- サイトに表示している事業者名と
nameが一致しているか urlが正式なサイト URL になっているか- ロゴの URL を検索エンジンが取得できるか
sameAsが事業者本人の公式プロフィールを指しているか- 所在地や連絡先が、ページ上の情報と一致しているか
店舗や地域に根ざした事業では、より具体的な LocalBusiness の下位型が適している場合があります。一方、個人の活動を示すサイトでは Person が適切な場合もあります。事業形態だけで機械的に決めず、サイトが誰の、どのような情報を示しているかで判断します。
Article または BlogPosting
ブログ記事では、Article またはその下位型である BlogPosting を利用できます。
Google の記事構造化データに関する案内では、記事ページのタイトル、画像、日付、著者などを Google が理解する助けになると説明しています。
主に確認したい項目は次のとおりです。
headlineauthordatePublisheddateModifiedimagemainEntityOfPage
構造化データに著者名を入れるだけでなく、ページ上にも著者名を表示し、可能であれば著者プロフィールへリンクします。公開日と更新日も、読者が見える日付と一致させます。
記事内容を見直していないのに、テーマの更新やキャッシュ処理だけで dateModified が変わる設計には注意が必要です。何を「記事の更新」とみなすかを決めておくと、表示と構造化データの両方を管理しやすくなります。
BreadcrumbList
BreadcrumbList は、ページがサイト内のどの階層にあるかを表します。
パンくずリストを画面に表示している場合は、そのリンク先や順序と構造化データを一致させます。テーマと SEO プラグインの両方がパンくずリストを生成している場合は、見た目だけでなく構造化データの出力元も確認します。
FAQPage は AI 対策として追加しない
FAQPage は、サイト運営者が用意した質問と回答を表す Schema.org の型です。しかし、FAQ の構造化データを追加したからといって、AI 検索の回答に使われるとは確認できません。
さらに Google は、2026年5月7日から FAQ リッチリザルトを Google 検索に表示しない方針へ変更し、同年6月には関連ドキュメントも削除しました。Google Search Central のドキュメント更新履歴
Schema.org の型として FAQPage が存在することと、Google 検索で目に見える機能に使われることは別です。
質問と回答が読者にとって必要なら、まずページ上に分かりやすく掲載します。検索結果や AI 回答への表示だけを目的に、FAQPage を追加する必要はありません。
WordPress で起こりやすい重複と不一致
WordPress では、テーマ、SEO プラグイン、構造化データ専用プラグイン、独自に追加したコードが、それぞれ構造化データを出力する可能性があります。
ここで注意したいのは、<script type="application/ld+json"> が複数あること自体は、すぐに問題とはいえないことです。
1つのページに WebSite、WebPage、Organization、Person、BreadcrumbList、Article など、役割の異なるデータが存在することはあります。
確認したいのは、同じ対象について、異なる情報や識別子が出力されていないかです。
たとえば、次のような状態です。
- 同じ事業者なのに、異なる名称の
Organizationが複数ある - 同じ事業者を表す
@idが出力元ごとに異なる - ページ上の著者と
authorが一致しない dateModifiedが、記事内容とは関係なく更新されるurlやmainEntityOfPageが canonical URL と異なる- 表示しているパンくずリストと
BreadcrumbListの階層が異なる
複数の構造化データを無理に1つの script 要素へまとめる必要はありません。同じ人や組織を参照する場合は、同じ @id を使うなど、データ同士の関係が矛盾しないようにします。
WordPress の構造化データを確認する方法
構造化データを追加したり、テーマやプラグインを変更したりしたときは、公開前後に次の順番で確認します。
1. 画面に表示される情報を確認する
最初に、記事タイトル、著者、公開日、更新日、事業者名、パンくずリストなど、利用者がページ上で確認できる情報を見ます。
構造化データの検証結果がエラーなしでも、元になる表示内容が古かったり間違っていたりすれば、正しい実装とはいえません。
2. ページソースで出力内容を確認する
ブラウザの「ページのソースを表示」を開き、application/ld+json を検索します。
主に、次の項目を確認します。
- どの
@typeが出力されているか - 同じ型が複数ある場合、何を表しているか
@id、url、name、headlineが一致しているかauthor、publisher、公開日、更新日が正しいか- プラグインを設定したページだけでなく、実際の公開ページにも出力されているか
3. Google リッチリザルト テストを使う
Google リッチリザルト テストでは、Google が対応している検索機能の構造化データについて、エラーや警告を確認できます。
ただし、このテストは Schema.org に存在するすべての型や項目を検証するものではありません。「エラーがない」ことは、検索結果へ必ず表示されるという意味でもありません。
4. Schema.org Markup Validator で全体を見る
Schema.org Markup Validatorでは、JSON-LD、Microdata、RDFa から Schema.org のデータを抽出し、構文上の問題やデータの関係を確認できます。
Google のリッチリザルト対象外を含めて構造化データ全体を確認したい場合は、リッチリザルト テストと役割を分けて使います。
5. Search Console で Google が取得した状態を確認する
公開後は、Search Console の URL 検査を使い、Google がページを取得できるか、インデックス可能な状態かを確認します。
ブラウザで見えていても、robots.txt、noindex、CDN、WAF、ログイン制限などによって、検索クローラーが同じ内容を取得できない場合があります。
6. 重複している場合は出力元を切り分ける
出力元が分からない場合は、いきなり本番環境でプラグインを停止せず、検証環境やバックアップを用意したうえで切り分けます。
確認する場所は次のとおりです。
- SEO プラグインの構造化データ設定
- 構造化データ専用プラグイン
- テーマや子テーマのコード
- 独自プラグイン
- ブロックやカスタムフィールドからの出力
- キャッシュに残っている古い HTML
設定を変更したあとは、キャッシュを削除し、ページソースと検証ツールの両方で再確認します。
構造化データより先に整えたい情報
構造化データは、存在しない情報や説明不足の本文を補ってくれるものではありません。
Google も、構造化データはページの主な内容を正確に表し、利用者に表示される内容と一致させる必要があると説明しています。
構造化データへ手を付ける前に、次の順番で確認すると整理しやすくなります。
- 記事が扱う質問と、その回答が本文にある
- 根拠、条件、例外、確認日が書かれている
- 著者名と著者プロフィールを確認できる
- 公開日と、内容を見直した更新日が正しい
- 事業者名、サービス、連絡先などの情報が統一されている
- 見出しや
articleなど、内容に合った HTML を使っている - ページをクロール、インデックスできる
- 整えた情報を必要な構造化データとして出力する
人がページを読んでも確認できない情報を、構造化データにだけ記述しないことが大切です。
自分で確認できることと、相談した方がよい状態
まずは、次の項目を自分たちで確認できます。
- ページ上の著者、日付、事業者名が正しいか
- ページソースに
application/ld+jsonが何個あるか - リッチリザルト テストでエラーが出ていないか
- Search Console で URL を検査できるか
- WordPress で利用している SEO・構造化データ関連プラグインは何か
一方で、次のような状態では、制作会社や保守担当者へ相談した方が確認しやすくなります。
- どのテーマやプラグインが構造化データを出力しているか分からない
- 同じ
OrganizationやArticleが複数あり、残すものを判断できない - 構造化データと画面表示の内容が一致しない
@idや canonical URL の関係が分からない- 設定を変更すると検索表示やほかの機能へ影響しそう
- 本番サイトでプラグインを停止しないと切り分けられない
相談するときは、対象ページの URL、検証ツールの結果、使用中のテーマとプラグイン、変更した設定、問題に気づいた時期を用意しておくと、原因を整理しやすくなります。
オレインデザインでは、構造化データだけを追加するのではなく、ページに表示される情報、WordPress 内のデータ、テーマやプラグインからの出力を確認し、矛盾が起きにくい形を一緒に考えています。自社だけでは出力元を切り分けにくい場合は、お問い合わせからご相談ください。
まとめ
構造化データは、AI 検索に引用されるための必須条件ではなく、引用を増やすと確認された施策でもありません。
一方で、記事、著者、事業者、公開日などの情報を検索エンジンへ伝え、対応する検索結果表示の対象になるための実務的な価値はあります。WordPress では、テーマや複数のプラグインによる重複、不正確な更新日、著者や URL の不一致を見つける確認項目にもなります。
まず、人が読んで理解・確認できる本文、著者情報、日付、事業者情報を整える。そのうえで、同じ情報を構造化データとして正確に伝える。この順番が大切です。
構造化データは、AI 対策のために情報を作る仕組みではなく、すでに整えた情報の意味を機械へ伝える仕組みです。
AI 検索だけに振り回されず、通常の検索やアクセシビリティ、今後の保守まで含めて、必要なものから整える際の参考になれば嬉しいです。
参考リンク
- AI features and your website｜Google Search Central
- Intro to How Structured Data Markup Works｜Google Search Central
- General Structured Data Guidelines｜Google Search Central
- Organization Structured Data｜Google Search Central
- Article Structured Data｜Google Search Central
- Google Search Documentation Updates｜Google Search Central
- Schema.org Markup Validator｜Schema.org
- Page Structure Tutorial｜W3C Web Accessibility Initiative
