FAQPage構造化データを入れてもAI検索に拾われない理由と直し方

2026年9月17日

FAQPage構造化データを入れても、AI検索でも通常検索でも変化が見えないなら、まず疑うべきなのは「未実装」ではなく「実装のされ方」です。コードがあっても、本文との不一致、重複出力、クロール阻害があると、FAQとして正しく扱われません。

PentraはAI検索とSEOで“引用される”情報設計を重視するメディアとして、FAQPage構造化データも、マークアップ単体ではなく、会社情報や運営主体の明示まで含めて見直す方が手戻りを減らせると考えています。

まず結論：FAQPage構造化データは“入れた”だけではAI検索に反映されない

結論は明快です。FAQPage構造化データの有無だけで、AI検索への引用や検索結果の見え方は決まりません。AI検索、AI Overview、従来のリッチリザルトは判定ロジックも表示条件も別です。

とくに誤解されやすいのが、FAQのマークアップを入れれば検索結果で目立つという認識です。Google検索におけるFAQリッチリザルトは段階的に縮小され、2026年5月以降は一般企業サイトでの表示前提では考えにくいとされています。Google検索でのFAQ表示制限は、FAQPageの表示変更に関する案内でも確認できます。

そのため、FAQPage構造化データの役割は「検索結果を派手にする施策」ではなく、「質問と回答の対応関係を機械に伝える補助」と考えるべきです。

FAQのマークアップがあっても評価されないのは、実装・内容・クロールの3層で失敗するから

切り分けは3層で考えると早いです。1つ目は実装で、JSON-LDの構文ミスや必須プロパティ不足、FAQPageとQAPageの使い分けミス。2つ目は内容で、本文にない質問をコードだけで足していたり、回答が短すぎたりする状態です。3つ目はクロールで、canonicalやnoindex、JS描画依存の影響で取得が不安定になっているケースです。

修正の優先順位で迷うときは、リライトで順位が伸びないときの見直し順と同じ発想で、技術・内容・評価対象の順に点検すると判断しやすくなります。

FAQリッチリザルトが縮小した今も、FAQPage構造化データを整える価値はある

価値は残っています。FAQPage構造化データは、質問文と回答文の境界を明示できるため、生成AIや検索エンジンがページの意味を取り違えにくくなります。

一般企業サイトでは、構造化データを入れたから表示が増えるとは言えません。一方で、本文のQ&Aが整理され、FAQPage構造化データも本文と一致しているページは、要点抽出の土台として扱いやすくなります。質問の立て方そのものを見直したい場合は、AIが読み取りやすいFAQ設計の考え方が参考になります。

FAQPage構造化データが拾われない原因を切り分ける診断フロー

最短で直したいなら、確認順を固定してください。先にコード、次にHTML、最後にSearch Consoleとページ設計を見る流れです。

手順1：リッチリザルトテストとSchema Markup Validatorで構文エラーを確認する

最初に見るのはJSON-LDの文法です。引用符の閉じ忘れ、カンマ漏れ、mainEntityの配列崩れ、acceptedAnswerの入れ子ミスは頻出です。ツール上でエラーが出るなら、内容評価の前にそこを直すべきです。

警告も軽視できません。必須ではない項目でも、authorやpublisher周りが欠けたまま複数スキーマが分断されていると、ページ全体の意味が弱くなります。

手順2：HTML上に質問と回答が実際に表示されているか確認する

コードだけ存在し、本文にFAQが見えない状態は危険です。構造化データと可視コンテンツの一致が重要で、JavaScriptで後から描画する実装だと取得が不安定になることがあります。

ブラウザのソース表示と検証ツールのElementsで、質問文と回答文が初期HTMLに出ているかを確認してください。レンダリング後しか存在しないなら、サーバー側で出す形へ寄せた方が安全です。

手順3：Search Consoleでクロール・インデックス・重複URLを確認する

URL自体が評価対象から外れていれば、FAQPage構造化データは機能しません。URL検査でインデックス状況、取得可否、ユーザー指定canonicalとGoogle選択canonicalの差を確認してください。検出済み未登録、クロール済み未登録、代替ページが出ているなら、まずURL正規化の問題です。

FAQページが似たURLで量産されている場合は、重複判断に引っかかることもあります。サイト全体の重複整理が必要な場面では、GSCで重複ページを見つける手順の考え方が使えます。

手順4：FAQPageと本文内容の一致、ページ目的の整合性を確認する

FAQPage構造化データの中身が本文とズレていると、信頼できるマークアップとして扱われにくくなります。質問数や回答内容、断定表現の差分は避けるべきです。

記事本文が解説中心なのに、末尾にQ&Aを少し置いてFAQPage構造化データを付けるだけでは、FAQ主体ページとして弱くなります。

手順5：AI検索で引用されにくいページ設計になっていないか確認する

FAQPage構造化データが正しくても、質問文が抽象的、回答の結論が後ろ、運営主体が曖昧、会社情報と記事情報の接続がないと、AI検索で拾われにくくなります。

中小企業サイトでは、FAQだけ整えても会社の実体が伝わらないケースが少なくありません。運営主体の土台が弱い場合は、AI検索で読み取られやすい会社情報の作り方から整える方が改善が早いことがあります。

あなたのサイトは、検索とAIにどう見えているか——3分で無料診断

サイトURLを入れるだけで、メディア健康度と「どの記事から手を入れるべきか」の優先リスト(実記事名つき)をAIが無料でレポートします。登録不要・約3分。

無料でサイトを診断する

よくある実装ミス別にみる、FAQPage構造化データが無効化されるパターン

無効化の原因は、派手なバグより地味な設計ミスに偏ります。WordPressではとくに、プラグイン任せで気づきにくい失敗が多いです。

FAQPageとQAPageの使い分けを間違えている

自社が用意した質問と回答ならFAQPageです。ユーザー投稿の質問に複数回答が付く場ならQAPageが候補になります。企業サイトのよくある質問でQAPageを使うと、ページ実態と型がずれます。GoogleのQAPageの公式仕様でも、Q&A形式の前提が示されています。

本文にない質問や回答をJSON-LDだけで追加している

見えないFAQは避けてください。検索向けにだけ質問を増やす実装や、本文とJSON-LDで回答量が違う状態は、可視コンテンツとの不一致を生みます。

1ページ内に重複したFAQ構造化データが複数出力されている

SEOプラグイン、FAQブロック、手書きのJSON-LDが重なると、同じ質問群が二重三重に出ます。検証ツールで通っても、同一ページに別のFAQPageが複数あると解釈がぶれます。head内と本文末、両方に出ていないかを確認してください。

JavaScript描画やキャッシュの影響でGoogleが安定して取得できない

ローカルでは見えていても、本番のキャッシュや遅延読み込みで欠落することがあります。URL検査のレンダリング結果と実ブラウザ表示を見比べると、差に気づきやすくなります。

canonical・noindex・robots設定で評価対象から外れている

もっとも根本的な失敗です。FAQPage構造化データ以前に、そのURLが評価対象でなければ意味がありません。テンプレート流用でnoindexが残る、パラメータURLへcanonicalが向く、robots.txtで取得制限される、といった問題が残りがちです。

NGからOKへ：FAQPage構造化データの正しい書き方と修正例

修正では、型の正しさよりも「本文と一致しているか」を優先してください。きれいなJSON-LDでも、ページ実体とずれていれば弱いままです。

最低限守るべきJSON-LDの基本形

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "導入前によく確認される点は何ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "契約範囲、対応業務、連絡手段の3点です。本文でも同じ内容を明示します。"
      }
    }
  ]
}

mainEntityの中にQuestionを並べ、その中にacceptedAnswerを入れる。この形から崩さないのが基本です。nameとtextは、本文に表示される質問文・回答文と揃えてください。

よくあるNGコードと、修正版コードの見比べポイント

NGになりやすいのは、Questionの直下にtextを書いている、acceptedAnswerが配列になっている、HTMLタグを過剰に含める、全角引用符が混ざる、といったパターンです。修正時は、1問ずつ切り出してバリデートすると原因を潰しやすくなります。

? ポイント：WordPressで不具合が続くときは、完成形のJSON-LDを先にメモ帳などで整え、その後にテーマやカスタムフィールドへ戻すと切り分けが速くなります。管理画面上でHTMLとスクリプトを同時に触ると、原因が混ざりやすいためです。

WordPressで起こりやすい設定不足と修正箇所

多いのは、FAQブロックを置いただけで構造化データが出ると思い込むケースです。テーマ側が対応していない、SEOプラグインで無効化されている、逆に両方が出して重複する、といった差があります。公開ページのソースで実出力を確認してください。

AI検索に引用されやすくするために、FAQPage構造化データ以外で整える項目

FAQPage構造化データだけでは足りません。AI検索で扱われやすくするには、誰が何を述べているページかを周辺情報で補強する必要があります。

Organization・Article・author・sameAsをつなげて運営主体を明確にする

会社名、運営者情報、外部プロフィール、記事の著者情報が分断されていると、FAQの回答主体が曖昧になります。Organizationで会社、Articleで記事、authorで執筆者、sameAsで関連プロフィールや公式アカウントを結び、ページ間でも一貫させてください。運営者ページが弱い場合は、運営者情報のように主体を一枚で明示するページを基準点にすると整理しやすくなります。

質問文を検索意図に合わせ、回答は1トピック1結論で短く明確にする

AIが引用しやすいFAQは、質問が具体的です。回答は1つの質問に1つの結論を置き、補足は2文目以降に分けます。長文で周辺事情を詰め込むと、要点抽出で欠落しやすくなります。

FAQだけに頼らず、本文・見出し・内部リンクでページ全体の意味を補強する

FAQが強くても、ページ全体が何の情報か曖昧なら引用候補として弱くなります。本文冒頭に要約を置き、見出しで論点を分け、関連する会社情報やサービス説明へ内部リンクを張る方が安定します。固定ページの土台を先に整える考え方は、AI検索に引用されやすい固定ページ設計とも相性が良いです。

修正後に何を見ればいいか：再クロールから反映確認までの実務手順

修正後は、反映確認の観点を絞ると無駄が減ります。毎日順位だけを見るより、まず取得と解釈が正常化したかを追う方が先です。

Search Consoleで再クロールを促し、検証結果の変化を記録する

URL検査でライブテストを行い、取得可能ならインデックス登録をリクエストします。変更前後で、ソースHTML、JSON-LD、canonical、インデックス状態を記録してください。後から見返せる形にしておくと、再発時の切り分けが速くなります。

反映までの目安と、待っても変わらないときの次の打ち手

構文エラー修正は比較的早く反映されることがありますが、AI検索側の扱いまで含めると時間差があります。数日で決めつけず、取得状況と本文整合性を先に確認してください。待っても変わらないなら、FAQPage構造化データではなく、ページ目的の弱さ、運営主体の曖昧さ、内部リンク不足を疑う段階です。

FAQPage構造化データを使うべきケースと、使わない方がよいケース

FAQPage構造化データは万能ではありません。FAQの形が自然に成立するページだけで使う方が、保守もしやすく、本文との不一致も起きにくくなります。

FAQ主体のページで有効なケース

無理にFAQを増やすよりArticleやHowToを優先した方がよいケース

概念整理、手順説明、比較検討の解説では、FAQよりArticleやHowToの方が自然なことがあります。1ページに無理やりQ&Aを増やすと、本文の流れが崩れます。FAQPage構造化データを足すか迷うなら、「そのページは本当に質問回答が主役か」を基準にしてください。

判断に迷うときは、コードの有無ではなく、読者の質問がそのページだけで完結しているかを先に見ます。そこが曖昧なままでは、FAQPage構造化データを直しても改善幅は小さくなります。