2023年8月、私は法務サービスのクライアント向けの監査の途中にいた時、Googleは静かに爆弾を落とした：FAQリッチリザルトは「信頼できる政府および健康ウェブサイトのみに限定される」ことになった。一夜にして、過去2年間にわたって約400サイトの構築に組み込んだ戦術は単に...機能しなくなった。アコーディオンスニペットはない。SERPの不動産が倍増することもない。サイトはマークアップ内にFAQスキーマを保持していたが、視覚的な見返りは消えた。
私がしなかったこと：パニックを起こしてスキーマを削除すること。
その直感は正しいことが判明した。理由は、2024年にAI Overviewsが適切に展開され始め、クライアントサイト全体の引用パターンを執拗に監視し始めるまで完全には理解できなかった。FAQスキーマは以前のように機能していない。しかし今は別の何かをしており、それが何であるかを理解すれば、意図的にそれのために構築できる。
Googleが実際に廃止したもの（そして廃止しなかったもの）
Google Search Centralからの2023年9月の発表は具体的だった。ほとんどの商用サイトからFAQマークアップのリッチリザルト適格性が削除された。SERPのドロップダウンアコーディオン、あなたのリスティングの高さを倍にして下のすべての人のCTRを低下させるもの、それは99%のパブリッシャーにとって消えた。
しかしスキーマ自体は？依然として完全に有効だ。依然としてクロール可能だ。依然としてインデックスされている。Googleは「使用をやめろ」とは言っていない。彼らは「それのための派手なSERP処理は表示しない」と言った。
その区別は今極めて重要だ。
こう考えてみてほしい：構造化データはあなたのコンテンツとマシンの間の翻訳レイヤーだ。AI Overviewsを支えるGoogleのGeminiであろうと、Bingの開発者がCopilotに供給するために使用するクローラーであろうと、ChatGPTのウェブ閲覧モードであろうと、すべてのマシンは意図をパースして規模でファクトベースの回答を抽出しようとしている。スキーママークアップはあなたが直接彼らの言葉を話すことだ。
3月に4つのe-commerceクライアントから構造化データレポートをSchema Markup Validatorを使用して引き出し、AI Overview引用頻度（手動で追跡、わかっている、辛い）に対して相互参照した。高ボリュームカテゴリーページで明確で有効なFAQスキーマを持つサイトは、同一のコンテンツを持つがスキーマがないページの約2.3倍の速度で引用されていた。小さなサンプルだ。しかし注意を払うのに十分一貫していた。
AIシステムが実際に引用をプルする方法
これはほとんどのスキーマガイドが曖昧になる部分だ。理解している限りのメカニズムについて具体的にしてみよう。
AI Overviewsとものようなツールはサーチ結果をスクレイピングして上位の結果を選んでいない。彼らはレトリーバル・オグメンテッド・ジェネレーション（RAG）に近いことをしている：クエリーのセマンティック構造にマッチするコンテンツのチャンクをプルして、その後回答を合成している。問題は、最初の場所でチャンクがプルされるのを助けるシグナルが何かということだ。
質問-回答のペアとして構造化されたコンテンツはより清潔にレトリーブされやすい。FAQスキーマはクローラーに「このテキストブロックは質問であり、この隣接するテキストブロックはその答えだ」と伝える。そのペアはその後一貫したユニットだ。マークアップのない1,400語のブログ投稿の3番目の段落に同じ情報を埋める場合と比較すると、答えはそこにあるかもしれないが、マシンはそれを分離するために苦労する必要がある。
Seahawkは昨年フィンテックのクライアントがいて、私たちは約18個のFAQアイテムをスキーマで構築した商品比較ページを構築した。「アプリが破裂した場合、私のお金はどうなるか」や「これはFCA規制ですか」といったことをカバーしている。ページは機関的にトップ3にランクしていなかった。しかしそれはAI Overviewsの規制質問に対して引用されていた。答えが明確で、境界が定められており、明確にマークアップされていたからだ。それは転換だ。引用は常にランキングに従うわけではない。
信頼性のあるソース問題
ただしこれだ。AIシステムはますますソース感度が高くなっている。例えば、Perplexityは明確なE-E-A-Tシグナル、実証された専門知識、命名著者、指し示す外部リンクを持つサイトを支持する傾向がある。スキーマだけでは薄いサイトを救わない。コンテンツ信頼性のあるサイト上のスキーマはシグナルを増幅している。
FAQ スキーマの質問・回答形式ペアは、著者に対する Person スキーマ、パブリッシャーに対する Organization スキーマと非常に自然に組み合わさります。この 3 つを一つのページで一緒に実行すると、それを読む任意のマシンに、はるかに豊かなストーリーを伝えます。私は約 18 ヶ月前から Seahawk クライアントのビルドでこれを標準として実施し始めており、今後も続けるつもりです。
FAQ アイテムが実際に引用に値するものにするもの
すべての FAQ コンテンツが同じように作成されるわけではありません。「営業時間は何時か」「送料無料は提供しているか」といった質問の周りにスキーマを詰め込んでいるサイトを監査しすぎてきました。ローカル SEO の衛生管理としては問題ありません。実質的なクエリに答えようとしている AI システムから引用を獲得することはできません。
数ダースのサイトでこれが起こっているのを見ながら、引用を獲得する FAQ アイテムが共通して持つ傾向があります：
- 一般性よりも具体性。「新規決済企業の FCA 認可は通常どの程度の期間がかかるか」は「規制対象になるにはどうすればよいか」に勝ります。具体的な質問が実際のユーザーがクエリをタイプする方法とどれだけ一致するかが重要です。
- 自己完結的な回答。回答はページの残りを読まなくても理解できるべきです。回答に「上記で述べたように」と書かれていれば、引用準備ができていません。
- 数字、名前、または日付。具体的な事実が回答を支えます。「FCA 自身のガイダンスによると通常 12～18 ヶ月」といった回答は、生成モデルが再現したい種類の回答です。
- 冒頭に曖昧な文言がない。「それは素晴らしい質問です！考慮すべき多くの要因があります...」は致命的です。回答から始めてください。
- 40～80 語程度の長さ。実質的に十分な長さ。抽出可能な程度に短い。
技術的実装はまだ正しくある必要があります
FAQ スキーマが間違ってデプロイされているのを何度も見てきたので、Seahawk サイトがライブになる前に、スキーマ QA ステップをハードゲートとして含めています。一般的な失敗モード：
- 実際には FAQ ページではないページで
FAQPageスキーマを使用する（たとえば、下部に 1 つの FAQ ウィジェットがあるプロダクトページ。Google はこれを好みません）。 - JSON-LD を誤りなくネストしているため、
mainEntity配列が形式が不正です。Rich Results Test がこれを即座に検出します。 - ページに表示されていないスキーマに質問を含める。これは以前は機能していました。現在は Google のガイドラインに違反しており、手動アクションをトリガーできます。
- 複数のページで重複する質問テキストを使用する。各質問の canonical ホームを選択します。
- ページコンテンツが変わったときにスキーマを更新し忘れる。2021 年の価格設定をまだ参照しているスキーマ付きのサイトを見てきました。
Rich Results Test と Schema Markup Validator の両方を通じて実装を実行します。異なるものを検出します。両方を行ってください。
Yoast、Rank Math、および手動 JSON-LD
WordPress を使用している場合、Rank Math のスキーマモジュールは FAQ スキーマ生成をきれいに処理し、カスタムブロックにバインドできます。今年初め、SaaS クライアント向けの 200 ページのナレッジベースビルドでこれを使用しましたが、うまく機能しました。Yoast も同じことをしていますが、一括実装の UI はより複雑です。
headless ビルドまたは WordPress の外側のものの場合、手動で JSON-LD を記述し、<head> に挿入します。より多くの制御。10 分の価値があります。
ChatGPT と Perplexity については具体的にどうですか？
ChatGPT のブラウジングモードと Perplexity のどちらも Google と全く同じ方法でクロールしておらず、Google の構造化データドキュメントが説明する方法で、スキーマを正式に「サポート」していません。では、それらの引用を追跡している場合、スキーマに手間をかける理由は何ですか？
スキーマはコンテンツ構造を制定するためです。きれいな質問・回答ペアを書くことを強制します。そして、ツールが正式に JSON-LD を読むかどうかに関わらず、その基盤となる構造が引用されるのはこれです。
Perplexity は特に、回答がコンテンツの上部付近に表示され、視覚的に分離されている（ヘッダー、明確な段落）、クエリと密接に一致しているページから引き出される傾向があります。FAQ スキーマはまさにそのコンテンツアーキテクチャを推奨します。スキーマは足場です。それが強制するコンテンツが実際の引用可能な資産です。
昨年秋、不動産セクターのクライアントでこれをテストしました。2 つのページ、ほぼ同じドメイン権威、類似のバックリンクプロファイル。1 つはよく書かれた Q&A ペアを持つ FAQ スキーマを持っていました。もう 1 つは、流暢な散文で書かれた構造化されていない FAQ セクションを持っていました。90 日間で、Perplexity は構造化ページを 11 回引用し、散文版は 2 回引用しました。Perplexity 自身の検索インターフェースを使用して手動で追跡し、重要なクエリをいくつかの週ごとにタイプしました。面倒ですが、顕著です。
全てのページにFAQスキーマを追加すべきか？
いいえ。これをブランケット戦術として推奨するエージェンシーには異議を唱えます。
以下の場合に使用してください：
- 本物の質問と回答のコンテンツ形式がある
- ページが情報提供型または検討段階のクエリをターゲットにしている
- 具体的で、自己完結した、事実に基づいた回答を書ける
- ページに広がりのあるE-E-A-Tの信頼性がある
純粋な商品一覧ページ、ホームページのヒーロー部分、またはスキーマを持つためだけに質問を詰め込んでいる箇所には使用しないでください。Googleはそれを無視し、Perplexityは気にしません。
私のネットワークのサイトのうち、一貫してAI引用を獲得しているのは、スキーマを至る所に撒き散らしたサイトではありません。特定のトピックに対して専門的で高品質なQ&Aコンテンツを構築し、正しくマークアップしたサイトです。
FAQ
2025年もFAQスキーマの実装は価値があるか？
はい。ただし、かつて生成していたSERPアコーディオンのためではありません。現在の価値はQ&AコンテンツをあらゆるAI検索システムに認識させることにあります。GoogleのAI Overviews、Perplexity、Bing Copilotを含むシステムです。きれいで有効なFAQスキーマを備えた適切に書かれたQ&Aページは、スキーマなしの同等のページよりも測定可能に高い率で引用を獲得しています。
FAQスキーマは順位付けに直接役立つのか？
直接的にはいいえ。スキーマは従来の意味ではランキング要因ではありません。機械がコンテンツをどのように解析・検索するかを改善し、AI生成回答における引用率を上昇させ、その結果ゼロクリックおよびニアゼロクリッククエリの可視性に影響を与えます。間接的なパスウェイですが、実在します。
1ページあたりいくつのFAQ項目を含めるべきか？
魔法の数字はありません。私は通常、薄い20個よりも、よく書かれた5～12個を狙います。ボリュームよりも品質が重要です。各項目は、本物で異なる質問に具体的で自己完結した回答することでそこに値する理由を作る必要があります。
HowToスキーマやArticleスキーマも持つページでFAQスキーマを使用できるか？
はい。複数のスキーマタイプは、それぞれがページ上の実際のものを説明する限り、単一のページで問題ありません。恣意的に重ねないでください。ただし、下部にFAQセクションを含む長編記事は、ArticleスキーマとFAQPageスキーマの両方を正当に備えることができます。
FAQスキーマが有効かどうかを確認する最速の方法は？
GoogleのリッチリザルトテストにアクセスしてURLを貼り付けてください。スキーマが解析可能かどうか、リッチリザルト処理の対象となっていたかどうか（その処理は現在制限されていますが）を教えてくれます。さらに、Schema.orgのバリデータでも実行して、2番目の意見を得てください。
---
状況は変わりました。AI回答がゼロクリック領域の大きな部分を占め、GoogleのSERPアコーディオンは商業出版社の大部分で消えました。しかし構造化データの実践は遺物ではありません。別の仕事をしているだけです。機械がコンテンツを検索、解析、引用できるように支援する仕事です。Googleが素敵なドロップダウンをレンダリングしやすくするのではなく。実装を正しく行い、引用に値する回答を書いて、スキーマは背後で静かにその仕事をします。それでも合理的なトレードオフです。