FAQ構造化データが表示されない理由と今やるべき実装手順
この記事の要点
- FAQリッチリザルトはGoogleが表示を終了済み
- FAQPage構造化データ自体は、ページ内容を検索エンジンに伝えるために引き続き使える
- 可視コンテンツと完全一致したJSON-LDを正しく実装するのが今の正解
「FAQの構造化データを入れたのに、検索結果にQ&Aが表示されない」。そうお困りではありませんか。
結論から言うと、それは実装ミスではなく、Googleが仕様そのものを変えたからです。この記事では、なぜ今は表示されないのか、それでもFAQの構造化データを入れる意味はどこにあるのか、そして2026年時点で本当に効果のある実装手順を、コピペで使えるコード付きで解説します。非エンジニアの方にも分かるように進めます。
Contents / 目次
FAQのリッチリザルトはもう表示されない。だから狙う場所を変える
最初に、いちばん大事な事実からお伝えします。GoogleはFAQリッチリザルト（検索結果にQ&Aが折りたたみ表示される機能）の扱いを大きく変更し、今では大半の一般的なサイトで表示されなくなっています。
つまり、今からどれだけ正しくFAQの構造化データを実装しても、検索結果にあの展開式のQ&Aが出ることは、原則としてありません。「表示されない」のはあなたのサイトの不具合ではなく、Google側の方針転換が原因です。ここを取り違えて設定を延々と見直しても、答えは出ません。
では、FAQの構造化データはもう無意味なのでしょうか。答えは「いいえ」です。役割が「見た目の装飾」から「検索エンジンにページ内容を正しく伝える土台」へと移っただけです。狙う場所を変えれば、今も使えます。
FAQ構造化データとは。ページ内のよくある質問と回答を、検索エンジンが機械的に読み取れる形（多くはJSON-LDという記述形式）でタグ付けしたデータのことです。人間が読む文章とは別に、裏側で「これは質問、これがその答え」と教えてあげる仕組みだと考えてください。
この変更を受けて、今やるべきことは次の3つに整理できます。焦って新しいテクニックを探す前に、この方向性をつかんでください。
- 狙いの再設定：「リッチリザルト表示」を目的にするのをやめ、AI検索（AI Overviews）や関連質問（他の人はこちらも質問）への露出、コンテンツ理解の向上に狙いを移す
- 実装の正常化：表示中のQ&Aと完全に一致したJSON-LDを、正しい場所に置く。ここは今でも重要なので手を抜かない
- 検証手段の切り替え：Search Consoleだけに頼らず、後述の検証ツールでも実装が正しいか確かめる
過去と現在で、FAQ構造化データの位置づけがどう変わったのかを一覧にまとめました。この表を頭に入れておくと、この先の判断がぶれません。
| 観点 | リッチリザルト表示時（以前） | 表示終了後（今） |
|---|---|---|
| 検索結果の見た目 | Q&Aが折りたたみ表示（リッチリザルト） | 表示されない（機能終了） |
| クリック率への直接効果 | 表示枠が広がり効果があった | 直接の見た目の効果はほぼ消えた |
| FAQPageスキーマの有効性 | 有効 | 引き続き使える |
| 主な価値 | 検索結果での目立ち | 検索エンジンへ内容を正しく伝える土台 |
FAQリッチリザルトの表示を縮小・終了した経緯は、Google検索セントラルのブログ記事「FAQ と使い方のリッチリザルトの変更について」で告知されています。構造化データの仕様全般はGoogle 検索セントラル ドキュメントの更新履歴でも確認できます。仕様は今後も更新される可能性があるため、迷ったら必ず公式で最新の状態を確かめてください。
FAQ構造化データの正しい実装手順。コピペで使えるコード付き
ここからが本題です。表示されなくなった今でも、正しく実装する価値は残っています。AIや検索エンジンにページ内容を正確に伝えるための、再現できる手順を順番に見ていきましょう。WordPressでも手書きでも共通する考え方です。
ステップ1。ページ上に「見える」Q&Aを用意する
まず、構造化データを付ける前に、ページ本文にQ&Aを実際に表示させます。これが大前提です。
Googleのガイドラインでは、構造化データでマークアップする質問と回答は、ユーザーがページ上で見られる状態でなければなりません。ユーザーに見えない隠しテキストにタグだけ付ける行為は、ガイドライン違反です。まず読者に役立つQ&Aを本文に置き、そのうえで裏側のデータを合わせる、という順番を守ってください。
Q&Aの中身は、実際に問い合わせで来る質問、検索されている疑問を選びます。1問1答で、回答は具体的に。宣伝文句や、同じ質問の重複は入れません。
ステップ2。JSON-LD形式でコードを書く
Googleが推奨する記述形式はJSON-LDです。かんたんに言うと、質問と答えのセットを決まった型に流し込むだけです。下のコードをベースに、質問文と回答文を、ページに表示しているものと一字一句そろえて書き換えてください。
<!-- ページの <head> 内、または </body> の直前に設置する -->
<!-- 質問・回答は、ページ本文に表示している文言とそろえること -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "［質問1をそのまま入れる。例：初回相談は無料ですか］",
"acceptedAnswer": {
"@type": "Answer",
"text": "［回答1をそのまま入れる。ページ本文と同じ文章にする］"
}
},
{
"@type": "Question",
"name": "［質問2をそのまま入れる］",
"acceptedAnswer": {
"@type": "Answer",
"text": "［回答2をそのまま入れる］"
}
}
]
}
</script>書き換えるときの注意点を挙げます。ここでつまずく人が多い箇所です。
- ダブルクオート：回答文の中で「”」を使うと構文が壊れます。使う場合は日本語の「」に置き換えると安全です
- HTMLタグ：回答の “text” の中に簡単なリンクや改行タグを入れることは可能ですが、複雑なHTMLは避け、まずはプレーンな文章にするのが無難です
- 質問の数：mainEntity の中括弧セットをコピーすれば、3問でも5問でも増やせます。各セットの最後はカンマで区切り、最後の1問だけカンマを付けません
ステップ3。WordPressなら「プラグイン」か「手動」を選ぶ
WordPressサイトの場合、実装の入り口は大きく2通りです。自社の状況で選んでください。
1つ目は、SEO系プラグインを使う方法です。コードを触りたくない担当者に向いています。
- Rank Math、Yoast SEO、All In One SEO（AIOSEO）など、構造化データの出力機能を備えたSEOプラグインがあります。
- ただし、FAQの構造化データに対応しているか、どんなブロックや設定で出力できるかは、プラグインやバージョンによって異なります。仕様変更で機能そのものが変わることもあります。
- 利用中のプラグインでFAQの構造化データが扱えるか、その手順はどうかは、必ず各プラグインの公式ヘルプで最新の情報を確認してください。
2つ目は、手動で入れる方法です。ステップ2のコードを、テーマの適切な位置やGoogle タグ マネージャー経由でページに追加します。プラグインを増やしたくない、細かく制御したい場合に向きます。ただし、間違えるとページ全体の表示に影響することもあるため、必ず本番前にバックアップと検証をしてください。タグ マネージャーの基本的な使い方はGA4タグをGTMで正しく設定する方法でも触れているので、あわせて参考にしてください。
ステップ4。実装後にコードを検証する
設置したら、必ず構文が正しいか検証します。JSON-LDは、カンマ1つの抜けでも丸ごと読み取られなくなります。
検証には、Schema Markup Validator（schema.orgのバリデータ）を使うのが確実です。エラーがゼロで、質問と回答が意図通り読み取れていれば、実装は成功です。
ステップ5。AIに下書きを作らせて時短する
JSON-LDの手書きが不安なら、AIにたたき台を作らせる手があります。ここはAIが得意な作業です。ChatGPTやClaude（AnthropicのAIツール）に、ページのQ&Aを渡してコード化してもらいます。
出発点として、次のような短い指示（seed）を渡せば十分です。あとはAIと対話しながら、自社のQ&Aに合わせて詰めていってください。
あなたはSEOの実装担当です。
以下のQ&Aを、schema.orgのFAQPage形式のJSON-LDに変換してください。
・出力はJSON-LDのコードのみ
・質問と回答の文言は、渡したテキストを一字一句変えない
・構文エラーがないか確認してから出力
［ここにページ上のQ&Aを貼り付け］大事なのは、AIの出力をそのまま信じないことです。AIが作ったコードは、必ずステップ4の検証ツールにかけ、質問と回答がページ表示と完全に一致しているかを人の目で確認してください。AIは生成は得意ですが、細部が本文とズレることがあります。最終チェックは人の仕事です。この「渡す→生成させる→検証して直す」の流れさえ押さえれば、実装はぐっと楽になります。
実装するとどう変わるのか。今のFAQ構造化データの効果
リッチリザルトが消えた今、FAQ構造化データの役割は「見た目の装飾」から「内容を正しく伝える土台づくり」に変わりました。具体的にどんな位置づけになるのかを整理します。
もう1つは、検索結果の「他の人はこちらも質問」（People Also Ask）への対応です。ここに表示される疑問と、あなたのページのQ&Aがかみ合えば、関連する検索からの流入が期待できます。
さらに、地味ですが役に立つのが「コンテンツ理解の助け」です。ページのテーマと守備範囲を機械が読み取りやすい形で整理できるため、内容が薄いページとの差になります。ただし、これは順位を直接上げる魔法ではありません。
注意したいのは、ここで「導入すればCTRが何%上がる」といった具体的な数字を鵜呑みにしないことです。ネット上に出回るFAQスキーマの成果データの多くは、リッチリザルトが表示されていた時期のものです。表示機能が終わった今、当時の数字はそのまま当てはまりません。過去の派手な成功事例ではなく、現在の役割（内容を正しく伝える土台）を基準に判断してください。
効果を実感するには、FAQ単体ではなく記事全体の質が土台になります。見出しの組み立て方はスマホで読みやすい記事の見出し構成の作り方で詳しく解説しているので、Q&Aの前段として整えておくと読者の理解が進みやすくなります。
FAQ構造化データでよくある失敗と回避法
ここでは、現場で実際によく見かける失敗を挙げます。どれも「知っていれば防げる」ものばかりです。3つのパターンに分けて、なぜ起きて、どう防ぐかをセットで解説します。
失敗1。表示していないQ&Aをコードにだけ入れる
いちばん多いのがこれです。「検索で目立たせたいから」と、ページには載せていない質問を構造化データにこっそり入れてしまうケースです。
こうなると、Googleの構造化データに関する general guidelinesに反します。ユーザーに見えないコンテンツへのマークアップは禁止されており、違反すると手動対策（ペナルティ）の対象になることがあります。回避法はシンプルで、コードに入れるQ&Aは、必ずページ上に表示しているものだけにすること。まず本文にQ&Aを載せ、そのあとにコードを合わせる。この順番を絶対に崩さないでください。
失敗2。ページを更新したのにコードが古いまま
回答内容を書き換えたのに、裏側のJSON-LDだけ古い文章のまま放置される、という食い違いもよく起きます。特に、料金やサービス範囲、営業時間など、変わりやすい情報で起こりがちです。
この状態だと、表示と構造化データが一致せず、検索エンジンに「どちらが正しいのか」と混乱させます。回避法は、ページ本文とコードを必ずセットで更新するルールにすること。プラグインで自動出力している場合はこのズレが起きにくいので、更新が多いFAQなら自動化を選ぶのも有効です。手動運用なら、更新チェックリストに「JSON-LDも直したか」を1行加えておきましょう。
失敗3。全ページに無差別にFAQを付ける
「効果がありそうだから」と、サイトの全ページにFAQ構造化データをばらまくのも失敗パターンです。FAQが本来必要ないページにまで付けると、内容と実態が合わず、かえって評価を下げかねません。
回避法は、FAQがユーザーの疑問解決に本当に必要なページに限定することです。専用のよくある質問ページ、サービスページ、商品ページ、疑問に答える記事など、Q&Aがあって自然な場所だけに絞ります。「とりあえず全部に」は禁物です。
失敗4。FAQPageとQAPageを取り違える
意外と見落とされるのが、スキーマの種類の取り違えです。単一の公式回答があるよくある質問には「FAQPage」を使いますが、掲示板やコミュニティのように、ユーザーが複数の回答を投稿できるページには「QAPage」を使い分ける必要があります。
ここを間違えると、ページの性質とデータの型が合わず、正しく理解されません。自社の企業サイトのよくある質問なら、ほぼFAQPageで問題ありません。ユーザー投稿型のページを扱う場合は、Q&Aページ（QAPage）の構造化データに関するGoogle公式ドキュメントで違いを確認してください。
実装前に知っておきたい本音。どこまで自力でやるか
ここまで手順を解説してきましたが、最後に現場で感じている率直なところをお伝えします。教科書的な記事には載らない、判断の分かれ目です。
まず本音として、今からFAQ構造化データに大きな工数をかけるのは、優先順位としては高くありません。リッチリザルトという分かりやすい見返りが消えた以上、「これさえやれば集客が激変する」施策ではなくなりました。
誤解を恐れずに言えば、これは「土台を整える地味な作業」です。ここに何日もかけるより、Q&Aそのものの中身、つまり読者の疑問にちゃんと答えているかを磨く方が、はるかに効果が大きいのが実情です。
とはいえ、やる価値はあります。JSON-LDの実装は一度整えれば長く使え、AI検索の時代に向けた準備になるからです。おすすめは、力の入れどころを間違えないことです。凝ったコードを書くより、「表示と一致しているか」「本当に読者の役に立つQ&Aか」の2点に集中してください。
自力か外注かの線引きも悩ましいところです。次の判断軸を参考にしてください。
- 自力で十分なケース：WordPressでSEOプラグインを使っており、FAQブロックにQ&Aを入れるだけで完結する。ページ数も少ない
- 相談を検討したいケース：手書きのJSON-LDでエラーが解決しない、サイト全体の構造化データ設計を見直したい、AI検索も含めた集客全体をどう組むか整理したい
特に、「FAQだけ直しても検索の集客が伸びない」という段階まで来ているなら、問題はFAQではなく設計全体にあることが多いです。検索意図とのズレや内部構造の問題が隠れていることもあります。この見極めについてはSEO内部対策のチェックリストもあわせて確認すると、どこから手を付けるべきかが見えてきます。
コストの見落としにも触れておきます。プラグインで自動化する場合、無料でできる範囲も多いですが、多機能な構造化データ管理を求めると有料機能が必要になることもあります（各ツールの料金や機能は変わるため、導入時に公式で最新情報を確認してください。2026年07月10日時点）。まずは無料でできる範囲から始めて、必要になったら広げるのが堅実です。
よくある質問
FAQの構造化データはもう入れなくていいの？
入れる価値は残っています。検索結果のリッチリザルト表示はGoogleが終了しましたが、FAQPage自体は引き続き使え、ページ内容を検索エンジンに正しく伝える土台になります。ただし最優先の施策ではないので、力の入れすぎは禁物です。
今からでもリッチリザルトを表示させる裏技はある？
ありません。FAQリッチリザルトはGoogleが表示機能そのものを終了したため、どんな正しい実装をしても検索結果には出ません。 裏技を探すより、本文の質を高めることに力を移すのが正解です。
すでに入れているFAQ構造化データは消すべき？
急いで消す必要はありません。正しく実装されていて、表示中のQ&Aと一致しているなら、そのまま残して問題ありません。むしろ内容を正しく伝える土台として役立ちます。表示と食い違っている場合だけ、修正するか外してください。
コードが読み取られているか確認する方法は？
schema.orgのスキーマ検証ツールにURLかコードを貼れば、構文エラーの有無を確認できます。
まとめ。狙いを変えれば今も使える
FAQの構造化データを入れてもリッチリザルトが表示されないのは、あなたのミスではなくGoogleの仕様変更が理由です。だからこそ、狙う場所を「見た目の装飾」から「検索エンジンへの正しい理解シグナル」へ切り替えるのが、2026年の正解です。表示中のQ&Aと一致したJSON-LDを、必要なページに限って正しく置く。やることはシンプルです。
とはいえ、「FAQを直しても検索からの問い合わせが増えない」「そもそも自社サイトのどこから手を付ければいいか分からない」と感じているなら、原因はFAQ単体ではなく設計全体にあるかもしれません。現状を整理するだけでもかまいません。気になることがあれば、気軽にご相談ください。一緒に、優先順位から整理していきましょう。
30分の無料相談
現状をお聞きし、優先順位を一緒に整理します。
予約する →
