【今知りたい】既存サイトに構造化データを追加するとAIに検索されるのか？実態と後付け実装のリアル

既存サイトに JSON-LD を足せば、ChatGPT や Gemini、Perplexity で引用されるのか。クライアントから「GEO（生成エンジン最適化）をやってほしい」と言われたとき、この期待はよく出ます。結論から書きます。構造化データは、ページに書いてある事実を機械向けにラベル付けする手段です。貼るだけで AI 検索の対策は終わりません。 本文が薄い、数字が無い、画面と JSON-LD が違う、では引用の材料になりません。

一方で、後付けに意味が無いわけでもありません。Google は AI Overviews 向けに特別な schema.org は不要としつつ、構造化データはページの見える文と一致させることを、通常の検索と同じ土台として案内しています。リッチリザルトの対象になる型では、検索結果の見え方が変わることがあります。ChatGPT や Perplexity が JSON-LD を必ず読む、引用率が上がる、という公式の契約はありません。やる価値は「機械が取り違えにくいページにする」ことまでです。「認識率が飛躍する」は、測れないので言いません。

この記事では、フリーランスのWebディレクター兼エンジニアとして、既存サイトへの後付けを見てきた立場から、何が起きて、どこから手を付けるかを整理します。特定の生成 AI に選ばれた、検索結果のカードに出た、といった確認できない成果は出しません。

構造化データを足すと、何が起きるか

機械は HTML も読む。JSON-LD は「型付きの要約」

クローラは、多くの場合、まず HTML の本文を見ます。JSON-LD は、その本文を Organization や Service、FAQPage といった Schema.org の型に載せた別表現です。LLM が自然文より JSON-LD だけを信頼する、という公開仕様はありません。あるのは、検索エンジンがエンティティ（誰が、何を、いくらで）を取り違えにくくなる、という使い方です。Google は JSON-LD を推奨していますが、理由は実装と保守がしやすいからです。Microdata や RDFa でも、正しく書けば同等として扱います。

「検索される」と「引用元に選ばれる」は別

通常の SEO で構造化データが効くのは、主にリッチリザルトの対象型です。条件を満たせば、検索結果に価格やパンくずなどが載ることがあります。表示は保証されません。FAQ のリッチリザルトは、2026年5月7日以降、Google 検索では出ない、と Search Central の更新 にあります。FAQPage 自体は Schema.org として残ってよいです。Google は、使われない構造化データが検索を害する、とは書いていません。期待して足す理由は、SERP の FAQ 枠ではありません。

AI 側の「引用」は、索引に載っていること、本文が質問に答えていること、ポリシーに反していないことが先です。Google の AI features and your website は、AI Overviews / AI Mode に出るための追加の技術要件は無い、としています。構造化データの一致はベストプラクティスの一つです。ChatGPT や Perplexity が同じ規則で JSON-LD を必須にしている、という文書はありません。GEO という呼び方も、公式の順位指標ではありません。

後付けでやりがちな失敗と、筋の良い進め方

悪い例：テンプレの JSON-LD だけ貼って、本文と違う

無料のジェネレータで Organization と架空の AggregateRating、存在しない事例を JSON-LD にだけ書く。画面の会社概要には数字も実績も無い。Google の 構造化データの一般ガイドライン は、読者に見えない内容をマークアップしないことを求めています。違反すると、そのリッチリザルトの対象外になることがあります。スパムポリシーに触れると、手動対応の対象にもなり得ます。「AI がスパムと判定して回答ソースから完全に除外した」とまでは、公開情報では言えません。現場で起きるのは、検証ツールでエラー、Search Console で検出されない、本文とラベルが食い違う、です。

良い例：今ある強み・仕様・FAQ を、画面と同じ文で型に載せる

会社概要、主力サービス、よくある質問、実績（確認できる範囲）の本文を先に直す。そのあと、同じ固有名詞・条件・質問文で JSON-LD を足す。検証ツールでエラーを潰す。Search Console で、今も出るリッチリザルト型だけを見る。生成 AI での言及は、参考の目視です。カード表示や「おすすめ」枠に出た、は環境と質問文で変わるので、成果指標にはしません。差はテンプレか、ページの一次情報と一致しているかです。

【役割別】既存サイトへ後付けする手順

Webディレクター / マーケター（優先順位とファクト）

全ページ一括は不要です。機械が取り違えやすいのは、会社（誰か）、サービス（何をするか）、判断材料（FAQ）、証拠（実績）です。この4つから足します。商品を売っているなら Product（Google ではマーチャント向けの要件が別にあることがあります）。受託のWeb制作なら、無理に Product にせず Service や ProfessionalService の方がページの実態に近いです。

一致のルールは 100% です。画面に無い受賞、件数、料金を JSON-LD にだけ書かない。実績ページに社名を出せないなら、構造化データにも出さない。

ミニ事例です。JSON-LD にだけ「導入100社」と書いて検証で弾かれる型と、FAQ の見出しと本文を先に具体化し、同じ質問・回答を FAQPage に載せる型です。後者で「即座に AI 引用を獲得」は約束できません。先に変わるのは、人間が読んでも機械が読んでも同じ答えになることです。

フロントエンドエンジニア / コーダー（実装と検証）

既存サイトなら、対象ページの head か body 末尾に <script type="application/ld+json"> を直書きするのが、いちばん取りこぼしが少ないです。Google は、JavaScript で後から挿入した JSON-LD も読める、と 導入ガイド に書いています。GTM 配信は、タグの発火条件と同意バナー次第で、初回 HTML に乗らないことがあります。Googlebot はレンダリングしますが、JavaScript を実行しないクローラは JSON-LD を見ません。既存サイトで「確実に HTML に載せる」なら直埋めを優先します。GTM にするなら、公開 HTML または URL 検査のレンダリング結果に script があるかを確認します。

検証は二段です。Google が今も対象にしているリッチリザルト型は リッチリザルトテスト。Schema.org としての文法は Schema Markup Validator。FAQ のリッチリザルトは 2026年5月以降 Google では出ないため、リッチリザルトテストで FAQ が出なくても、本文一致の FAQPage を残す判断はあり得ます。エラーゼロは「Google のその機能の対象」と「JSON として壊れていない」を分けて見ます。

次は、サービスページに FAQ があるときの型です。値は画面の文と揃えます。存在しない価格や評価は入れません。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Service",
      "@id": "https://example.com/service/web-production#service",
      "name": "Webサイト制作",
      "url": "https://example.com/service/web-production",
      "provider": {
        "@type": "Organization",
        "name": "Example合同会社",
        "url": "https://example.com/"
      },
      "areaServed": "JP",
      "description": "企画から公開までのWeb制作。広告運用の代行は行いません。"
    },
    {
      "@type": "FAQPage",
      "@id": "https://example.com/service/web-production#faq",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "見積もりに何が必要ですか？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "現状サイトのURL、希望公開時期、必須のページ数を共有ください。未確定でも構いません。"
          }
        },
        {
          "@type": "Question",
          "name": "対応できないことはありますか？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "広告運用の代行と、確認できない実績数値の作成は行いません。"
          }
        }
      ]
    }
  ]
}
</script>

物販で Product が正しいページなら、name / image / offers など、今の 商品の構造化データ の必須項目を公式の表で確認します。サービスページにダミーの offers.price を足すのは、失敗側です。

ミニ事例です。GTM のトリガーが「同意後」だけだと、検査ツールの初回 HTML に JSON-LD が無い型と、テンプレートに直埋めし、画面の FAQ 見出しと name を一致させた型です。後者が「AI クローラに確実に読まれる」保証ではありません。読めるクローラが増える、という実装です。

Web担当者 / 運用者（効果測定）

Search Console の「利便性」やリッチリザルト関連のレポートで、今も Google が出している型の検出とエラーを見ます。FAQ 枠の復活を待たない方がよいです。AI Overviews への掲載は、通常の検索トラフィックに含まれます。専用の「引用回数」公式指標はありません。

ChatGPT や Perplexity で自社名やサービス名を聞く作業は、月1の目視に留めます。回答はモデルと日付で変わり、広告やログイン状態でも差が出ます。URL が出た／出ないを KPI にすると、再現できません。見るなら、質問文、日付、出てきたドメイン、本文と食い違う事実が無いか、の記録です。微調整は JSON-LD より、先に本文の条件と対象外です。

ミニ事例です。追加して検証せず、1年後に JSON-LD だけ古い社名のまま、という型と、四半期で会社概要と JSON-LD を同じ文面で見直す型です。後者でも生成 AI の引用は約束しません。食い違いを残さない、が運用の成果です。

クライアント・上層部にはここを伝える

構造化データは、機械がページを取り違えにくくするための土台です。Google の AI 機能向けの必須条件でも、十分条件でもありません。公式は「特別なマークアップは不要」「見える文と一致させる」です。これだけで ChatGPT に勝つ、は期待値として渡しません。

セットで提案するのは、一次情報です。料金の条件、対象外、実績の出し方、FAQ の具体性。数字が無いなら、構造化データにも書きません。テンプレを全ページに配る工数より、4ページの本文とラベルを揃える方が先です。診断という商品名である必要はありません。

既存サイト 構造化データ後付けチェックシート

まとめ：後付けは遅くない。ただしラベルより本文が先

既存サイトでも、構造化データの追加はできます。いちばん手軽な「AI 対策」に見える作業でもあります。効く範囲は、機械向けのラベルと、Google が今出しているリッチリザルト型までです。生成 AI に検索される・引用されるは、索引と本文の質が先で、JSON-LD 単体の成果ではありません。テンプレを貼らず、4ページの事実を揃えてから型を載せる。それが後付けのリアルです。

既存サイトのマークアップと、本文側の一次情報の整理は、相談・お問い合わせからどうぞ。