FAQ構造化データは削除すべき？リッチリザルト終了後のWordPress対応

Google検索のFAQリッチリザルトは、2026年5月7日から表示されなくなりました。ところが、WordPressの多くのサイトにはFAQPage形式の構造化データが残っています。「表示されないなら全部削除するべきか」「残すとSEOで不利になるのか」と迷う担当者もいるでしょう。

結論は、一律削除ではありません。Googleは、使われなくなった構造化データを急いで消す必要はなく、残っていても検索で問題を起こさないと案内しています。ただし、画面に見えないQ&A、古い回答、複数プラグインによる重複出力などは別です。検索結果の装飾が終わった今こそ、運用目的のないコードを棚卸しする機会です。

この記事では、WordPressに詳しくない担当者でも作業できるように、FAQ構造化データの見つけ方、残す・直す・削除する判断、プラグイン別の確認、変更後の検証まで順番に説明します。作業前に本番サイトのバックアップを取り、最初は一ページだけで試してください。Googleの仕様と画面は2026年9月11日時点の公式情報を基準にしています。

2026年に何が変わったのか

FAQ構造化データは、ページ内の質問と回答を機械が理解しやすい形で記述する仕組みです。2019年にGoogle検索がFAQリッチリザルトへ対応したことで、検索結果の下に質問と回答が展開される表示が広まりました。通常の青いリンクよりも表示面積が大きくなるため、クリック率の改善を期待して導入したサイトも少なくありません。

その後、Googleは検索結果を簡素にする方針を進めました。2023年にはFAQ表示を著名な政府・医療サイトへ限定し、2026年5月7日に機能自体を終了しました。公式の更新履歴には、FAQリッチリザルトがGoogle検索に表示されなくなったことが明記されています。

検索結果から消えたのは、FAQの内容そのものではなく、検索結果に展開して見せる機能です。ページ内のよくある質問は、訪問者の疑問を解消するコンテンツとして引き続き使えます。FAQPageというSchema.orgの型も存在します。ただし、Google検索のFAQリッチリザルトを得る目的では使えなくなりました。

Search Consoleで使っていたFAQの拡張レポートや検索での見え方、リッチリザルトテストの対応は2026年6月に終了しました。Search Console APIのFAQ関連サポートも同年8月に削除されました。レポートが消えたことをエラーや設定ミスと誤解しないようにしてください。

FAQを残すこととSEO評価を分けて考える

FAQリッチリザルトが終了したからといって、FAQを掲載すると順位が下がるわけではありません。反対に、FAQPageを残すだけで順位が上がるという公式根拠もありません。検索順位、検索結果の装飾、読者への情報提供という三つの目的を混同しないことが大切です。

Googleの構造化データ一般ガイドラインでは、マークアップはページに表示される内容を正しく表し、古くない情報であることが求められます。画面上に存在しない質問をJSON-LDだけに入れる、別商品の回答を流用する、終了した料金や受付条件を残すといった状態は避けるべきです。

検索結果で目立たなくなっても、FAQ本文が問い合わせ前の不安を解消しているなら、表示コンテンツは残す価値があります。たとえば、納期、対応地域、契約期間、準備物を分かりやすく説明できれば、相談前の理解が進みます。目的はコードを維持することではなく、読者の判断を助けることです。

「AI検索に必ず引用されるから残す」という断定にも注意が必要です。GoogleはSchema.orgの語彙が他の検索エンジンやサービスで役立つ場合があると説明していますが、特定の生成AIがFAQPageを評価する保証は示していません。将来の期待だけで保守コストを正当化せず、現在の利用目的と正確性で判断します。

最初にFAQ構造化データを棚卸しする

削除ボタンを探す前に、どのページへ、どの仕組みからFAQPageが出力されているかを調べます。WordPressでは、SEOプラグイン、構造化データ専用プラグイン、テーマ、FAQブロック、手書きコードが同時に使われていることがあります。出力元を確認せず設定を切ると、パンくずや記事情報など必要なSchemaまで消えるおそれがあります。

対象URLは、Search Consoleの過去のFAQレポート、サイト内検索、WordPressの投稿一覧から集めます。記事本文で「よくある質問」「FAQ」を検索し、公開中ページを一覧にしてください。以前のレポートを保存していない場合でも、重要なサービスページと流入の多い記事から確認すれば、影響の大きい場所を優先できます。

ブラウザでページを開き、何もない場所を右クリックして「ページのソースを表示」を選びます。MacではCommand＋F、WindowsではCtrl＋Fを押し、「FAQPage」を検索してください。見つかった周辺に「application/ld+json」があれば、JSON-LD形式で出力されています。

同じページにFAQPageが二つ以上ある場合は、複数の仕組みが重複している可能性があります。コード内の質問文を本文と照合し、どのブロックや設定が出力元かを調べます。確認したURL、本文のFAQ有無、FAQPageの個数、利用プラグイン、最終更新日、担当者を表へ記録してください。

残す・修正する・削除する判断基準

残す候補は、表示中の質問と回答に完全に一致し、内容が最新で、サイト内のデータ管理や他サービスでも使う目的があるものです。更新担当と確認時期が決まっていることも条件にします。単に「以前からある」という理由だけでは、維持する根拠として弱いでしょう。

修正する候補は、FAQ本文に価値がある一方で、構造化データとの食い違い、古い回答、重複出力があるページです。本文とコードの質問数を合わせ、誤った側を直します。二つのプラグインが出力しているなら、管理しやすい一方だけを残します。

削除候補は、本文にFAQがないのにコードだけがある、終了したサービスを説明している、生成元が分からず保守できない、他の仕組みと競合している、出力する目的が存在しないケースです。構造化データを削除しても、読者に役立つFAQ本文まで消す必要はありません。

判断に迷ったら、一ページを選んで構造化データだけを停止し、表示、クロール、問い合わせへの影響を確認します。全ページを一括変更すると、不具合の原因を追いにくくなります。結果を見てから同じ条件のページへ展開してください。

WordPressで出力元を見つける具体的な操作

WordPressへ管理者または編集権限のあるユーザーでログインします。変更前に、サーバーまたはバックアッププラグインでデータベースとファイルを保存してください。作業対象のURL、公開状態、スクリーンショット、ソース内のFAQPageを記録しておくと、元へ戻すときに役立ちます。

投稿編集画面を開き、本文内のFAQブロックを選びます。右側のブロック設定に「Schema」「構造化データ」「FAQ schema」などの切り替えがないか確認してください。表示文と構造化データが一体のブロックもあれば、コード出力だけを停止できるブロックもあります。

次に「プラグイン」→「インストール済みプラグイン」を開きます。Yoast SEO、Rank Math、All in One SEO、Schema Pro、FAQ系プラグインなど、構造化データを扱うものを探します。ただし、確認のためにプラグイン全体を無効化してはいけません。サイト表示や別のSchemaまで変わるため、各プラグインの設定画面でFAQに限定した項目を探します。

テーマに直接記述されている場合は、「外観」から本番ファイルをその場で編集せず、制作会社や保守担当へ確認します。子テーマ、独自プラグイン、functions.php、テンプレートファイルにJSON-LDが含まれることがあります。更新で上書きされる場所やPHPエラーの危険があるため、ステージング環境で変更するのが安全です。

手書きの「カスタムHTML」ブロックも確認します。投稿編集画面のリスト表示を開き、カスタムHTMLを選び、「FAQPage」または「application/ld+json」を探してください。削除前にコードを別ファイルへ控え、FAQ本文が別ブロックとして残ることを確認します。

一ページだけ変更して公開後に確認する

最初の検証ページには、問い合わせや売上への影響が比較的小さく、構成が代表的な記事を選びます。バックアップを取ったあと、FAQPageの出力だけを停止します。FAQ本文に価値がある場合は、その文章と見た目を残してください。

変更を保存したら、WordPress、キャッシュプラグイン、サーバー、CDNのキャッシュを順に削除します。ログアウトしたブラウザまたはシークレットウィンドウでページを開き、質問と回答が正しく表示され、レイアウトが崩れていないか確認します。

ページのソースを再表示して「FAQPage」を検索します。削除対象ならゼロ件になったこと、残す対象なら意図した一件だけが出ることを確かめます。Schema.org Markup Validatorは一般的なSchema.org記述の確認に使えます。Googleのリッチリザルトテストでは、FAQ対応が終了しているため、以前と同じFAQ判定が出ない点に注意してください。

公開ページがHTTP 200で開くこと、タイトルや本文、パンくず、Articleなど他の構造化データが消えていないことも確認します。Search ConsoleのURL検査から公開URLを調べ、Googleがページへアクセスできる状態かを見ます。異常があればバックアップまたは控えた設定へ戻し、出力元を再確認してください。

変更後に見る数字と判断の期間

FAQリッチリザルトはすでに終了しているため、変更前後でその表示回数を比べることはできません。代わりに、対象ページの検索クリック、表示回数、平均掲載順位、問い合わせや購入、FAQ周辺の利用状況を確認します。構造化データの整理と同時にタイトルや本文を大きく変えると原因を分けられないため、検証中は変更点を限定します。

Search Consoleでは対象URLと検索語を絞り、変更前後の同じ曜日数を比較します。季節要因やキャンペーンの影響がある場合は、前年や近いページも参考にしてください。数日の増減だけで判断せず、クロールと再評価に必要な時間を見込みます。

GA4や問い合わせ管理では、ページ閲覧後のフォーム開始、完了、電話、資料請求などを見ます。FAQ本文を残したままコードだけ整理した場合、ユーザー行動が大きく変わらないのが通常です。もし問い合わせが減ったなら、FAQ表示そのものまで消していないか、ページ崩れや計測停止がないかを先に疑います。

運用面では、プラグインの警告件数、重複Schema、更新作業の時間も記録します。検索数値に変化がなくても、誤情報や二重出力を減らし、担当者が更新できる状態になれば整理の効果があります。

失敗しやすい対応と元に戻す方法

最も危険なのは、FAQリッチリザルト終了という情報だけを見て、SEOプラグインや構造化データ機能を丸ごと無効にすることです。FAQ以外のArticle、Breadcrumb、Organizationなども同時に消える場合があります。変更はFAQの出力だけに限定し、前後のソースを比較してください。

FAQ本文まで一括削除すると、検索から来た人が判断に必要な情報を失います。閲覧者から実際に質問される内容、契約や購入前の不安を減らす回答は残します。内容が重複する場合は、本文の適切な場所へ統合し、必要ならFAQ見出しだけを整理します。

キャッシュを残したまま確認すると、設定を直したのに古いコードが見え続けます。WordPress側だけでなく、サーバーキャッシュやCDNも対象です。逆に、キャッシュ削除後すぐの表示崩れは、構造化データではなくHTMLブロックまで削除した可能性があります。

元へ戻すときは、保存しておいた設定値やコードを復元し、キャッシュを消して公開ページとソースを再確認します。バックアップからサイト全体を戻す前に、変更した一項目だけ戻せるかを試します。作業日時、担当者、変更URL、復元手順を記録しておけば、障害時の対応が早くなります。

作業前後のチェックリスト

作業前は、対象URL、FAQ本文、FAQPageの件数、出力元、バックアップ、担当者を確認します。変更理由は「Google表示が終わったから」だけでなく、「本文と不一致」「重複出力」「保守目的がない」のようにページごとに記録してください。

作業後は、公開ページ、ページソース、他の構造化データ、キャッシュ、URL検査、問い合わせ計測を確認します。一ページの検証が終わるまで全体へ展開せず、同じ出力元と条件のURLだけをまとめます。

FAQ本文を残す場合は、回答の責任者と更新時期を決めます。料金、提供地域、納期、契約条件など変化しやすい情報には確認日を設けます。構造化データの有無より、表示内容が正確で読者に役立つことを優先してください。

公式情報と関連する実務記事

仕様変更の根拠は、GoogleのGoogle検索ドキュメント更新履歴で確認できます。構造化データを残す場合は、構造化データの一般ガイドラインと構造化データの仕組みを読み、表示本文と一致させてください。一般的なSchema.orgの構文確認にはSchema.org Markup Validatorを利用できます。

構造化データだけでなく、検索流入、ページ内容、問い合わせまでまとめて改善したい場合は、ignityのWeb制作・SEO・広告支援をご覧ください。検索状況の確認にはSearch Consoleで生成AI向け表示を管理する方法、改善対象の選び方にはSEOリライトの優先順位も参考になります。

まとめ

よくある質問