FAQPageの書き方と置く判断 Googleの表示が終わった今も入れる意味はあるか

自社のよくある質問のページに、FAQPageという構造化データを入れるべきか。制作会社から「FAQにはスキーマを入れておきます」と言われたものの、入れると何が起きるのかを説明できない。この記事は、そう感じている経営者とWeb担当者に向けて書いています。

制作会社に任せきりだと、ページのソースに何が書いてあるのかを見る機会がありません。それでも、書いてあることの責任は、サイトの持ち主にあります。

先に答え：検索結果の見た目を変える役目は終わり、置くかどうかは別の判断になった

結論から書きます。FAQPageの構造化データから作られていたGoogleの検索結果の表示（FAQのリッチリザルト）は、2026年5月7日からGoogle検索に表示されなくなりました。

検索結果の見た目を良くする目的で、新しく入れる理由は、公式の文書を読む限りありません。

一方で、FAQPageはschema.orgという共通の語彙に今も載っている型です。Googleは2023年8月の公式ブログで、使われていない構造化データは検索に問題を起こさない、と書いています。

そのため、置くかどうかの判断は、1つの問いに絞れます。画面に見えている質問と回答を、そのまま写すだけで済むか。済むなら置いても構いません。写し間違いが起きそうなら、置かないほうが安全です。

AIの回答との関係も、公式の文書で確かめました。Googleの「AI機能とウェブサイト」のページには、AIによる概要やAIモードに出るために追加すべき特別なschema.orgの構造化データはない、と書かれています。

つまり「FAQPageを入れればAIに引用される」とは、公式の文書からは言えません。

この記事に書いた事実は、Googleの検索セントラルの文書と更新履歴、Googleの公式ブログ、Search Consoleのヘルプ、schema.orgの公式サイトを、2026年11月3日に開いて読んだ範囲です。確かめられなかったことは「公式に記載なし」と書きます。

答えを表で先に見る

迷いやすい5つの疑問を、公式から確かめた答えと、次にすることに並べました。

疑問	公式から確かめた答え	次にすること
Googleの検索結果にFAQの表示は出るか	2026年5月7日から表示されなくなった（検索セントラルの更新履歴）	見た目を目的にした追加はしない
入れたままだと害があるか	使われていない構造化データは問題を起こさない（2023年8月の公式ブログ）	急いで外さなくてよい
AIの回答に引用されるか	追加すべき特別な構造化データはない（AI機能の文書）	本文の質問と回答の質を上げる
QAPageで代わりにできるか	サイト自身が書いたFAQには使えない（QAPageの文書）	代用しない
書くときの決まりはあるか	画面に見える内容と一致させる（構造化データの一般ガイドライン）	質問を変えたら両方を直す

Q&Aサイトで見かけた、どこに貼ればよいのか分からない声

先日、Q&Aサイトでこのような切実な悩みを拝見しました。数年前に投稿された質問で、初心者の方が書いたものです。

FAQのページを構造化データでマークアップし、HTMLのコードを作った。そのコードはheadとbodyのどちらに入れるのがよいのか。閉じタグの直前など、もっと好ましい位置はあるのか。

さらに、使っているサイトにheadやbodyの欄が見当たらない場合、ヘッダーとフッターへコードを貼り付けられるプラグインを入れれば、きちんと動くのか。そう尋ねていました。

寄せられた回答は、構造化データがどういうものか分からないので答えに困る、実際のブラウザーに表示されるのはbodyの中身だ、使っているCMSの名前を書くと的確な回答が付きやすい、という趣旨でした。

質問が書かれた当時は、FAQの構造化データが検索結果の見た目に効いていた時期です。投稿者は、見た目を変えたくてコードを作ったのだと思います。

この質問に重なっている3つの疑問

この1つの質問には、実は3つの疑問が入っています。

1つ目は、コードをどこに置くかという疑問です。2つ目は、そもそも今も入れる意味があるのかという疑問です。3つ目は、入れたあとにどうやって確かめるのかという疑問です。

回答に困った人の気持ちも分かります。構造化データは、画面に見えない部分の話だからです。見えないものは、誰にも相談できないまま放置されやすくなります。

この記事は、3つの疑問に順番に答えます。置き場所は「貼る場所」の節、置く意味は「それでも置く意味はあるか」の節、確かめ方は「テストで確かめられること」の節です。

質問者が知っておくと楽になること

先に、質問者に伝えたいことを書いておきます。

コードの置き場所は、headとbodyのどちらでも構いません。Googleの公式文書がそう書いています。詳しくは後の節で引きます。

そして、検索結果の見た目を目的にした作業は、2026年5月7日で意味を失っています。当時の質問への答えは、今では「見た目のためなら、やらなくてよい」に変わりました。

FAQPageとは何か：型の名前と、Googleの表示機能を分けて考える

FAQPageの話がややこしくなる原因は、2つのものが同じ名前で呼ばれていることです。1つはschema.orgという共通の語彙にある型。もう1つはGoogleが検索結果で見せていた表示機能です。

schema.orgでの定義

schema.orgは、検索エンジンなどが共通で使える構造化データの語彙を公開しているサイトです。このサイトでFAQPageは、次のように定義されています。

英語の原文を訳すと「FAQPageは、1つ以上の『よくある質問』を提示するWebPageである」という意味になります。あわせて、QAPageも参照するように、という案内が付いています。

同じ公式サイトのQAPageの説明には、「質問とその答えに焦点を当てたWebPage。質問応答サイトや、よくある質問を記録する文書などが例」という趣旨の定義があります。ここが後で効いてきます。

schema.orgの定義だけを読むと、QAPageもFAQを書くために使えるように見えるからです。Googleが別の決まりを出している点は、QAPageの節で説明します。

Googleの表示機能は、別のもの

Googleは、FAQPageを含む構造化データを読んで、検索結果にリッチリザルトを出していました。これが「FAQのリッチリザルト」です。

型の名前はschema.orgのものですが、検索結果への表示を決めるのはGoogleです。同じ型を書いても、表示するかどうかは検索エンジンごとに決まります。

この2つを分けて読むと、今の状況が整理できます。型は残っている。Googleの表示は終わった。

用語	何を指すか	2026年11月3日時点の状態
FAQPage	schema.orgにある型の名前	公式サイトに今も載っている
FAQのリッチリザルト	Googleが検索結果で見せていた表示機能	2026年5月7日から表示されない
QAPage	1つの質問と複数の回答を表す、別の型	Googleの文書は今もある
構造化データ	ページの内容を機械に伝えるための決まった書式	一般ガイドラインとして今もある

型の中身：質問と回答の組

FAQPageの中には、質問と回答の組を並べます。質問を表す型がQuestion、回答を表す型がAnswerです。

schema.orgの公式サイトでは、Questionは「オンラインで答えを求める利用者からの質問、またはよくある質問の文書にまとめられた質問」と説明されています。Answerは「質問に対して示された答え」です。

Questionには、採用された答えを入れるacceptedAnswerというプロパティがあります。Answerの本文は、textというプロパティに入れます。次の節で、この組み立てを実際のコードで見ます。

Googleの表示は、いつ、どう終わったのか

FAQのリッチリザルトは、いきなり消えたのではありません。2段階で縮み、最後に終わっています。公式の記録を、日付つきで順に見ます。

2023年8月：表示が政府と健康分野のサイトに限られた

Googleは2023年8月8日の公式ブログで、FAQとHowToのリッチリザルトの扱いを変えると発表しました。

FAQについては「FAQPageの構造化データによるFAQのリッチリザルトは、よく知られた信頼できる政府機関と健康関連のサイトにのみ表示される」という趣旨が書かれています。それ以外のサイトでは、この表示は通常は出なくなる、とも書かれています。

同じブログには、この構造化データをサイトから外してもよいが、積極的に削除する必要はない、とあります。理由は「使われていない構造化データはGoogle検索に問題を起こさないが、検索結果に見える効果もない」からです。

つまり2023年の時点で、一般の中小企業のサイトは、すでに表示の対象から外れていました。

2026年5月：表示そのものが終わった

次の変化は、検索セントラルの更新履歴に載っています。2026年5月8日の項目に「FAQのリッチリザルトの文書に非推奨の告知を追加した」と書かれ、理由は「この機能は2026年5月7日からGoogle検索に表示されなくなるため」です。

政府や健康分野のサイトも含めて、この表示は終わりました。

2026年6月：公式の説明ページが消えた

さらに、更新履歴の2026年6月15日の項目では「FAQのリッチリザルト機能の文書を削除した」と書かれています。理由は「2026年5月の更新履歴で告知したとおり、この機能が検索結果に表示されなくなったため」です。

2026年11月3日に、以前のFAQの文書のURLを開いてみました。今は更新履歴のページに転送されます。説明ページ自体が、もう見られない状態でした。

日付を並べると

日付	起きたこと	出典（文字で示す）
2023年8月8日	FAQの表示が政府と健康分野のサイトに限られた	Googleの検索セントラルブログ
2026年5月7日	FAQの表示がGoogle検索から消えた	検索セントラルの更新履歴（5月8日の項目）
2026年6月15日	FAQのリッチリザルトの文書が削除された	検索セントラルの更新履歴

Search Consoleの表示については

Search Consoleのヘルプには、リッチリザルトのレポートの概要と、検索パフォーマンスのレポートの説明があります。2026年11月3日にこの2つのページを読みましたが、FAQという言葉は見つかりませんでした。

そのため、Search Consoleの中でFAQの項目がどう扱われているかは、公式に記載なしです。自社のSearch Consoleに項目が残っていても、検索結果に表示されているという意味にはなりません。

最小のJSON-LD：質問と回答を写すだけの書き方

書く場合の形を、最小の例で示します。Googleの文書は、構造化データの形式としてJSON-LDを推奨しています。「JSON-LDは、ユーザーに見える文章に混ぜずに書けるため、入れ子のデータを表しやすい」という趣旨の説明もあります。

書く前に、画面の側を先に決める

コードを書く前に、画面に載せる質問と回答を確定させます。構造化データは、画面に見えている内容を機械に伝えるものだからです。

質問は短く、回答は結論から書きます。画面の文章が固まってから、同じ文面をコードに写します。順番を逆にすると、コードにだけ書いた内容が生まれやすくなります。

2問だけの例

架空の整体院が、予約についての質問を2つ載せる場合の例です。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "予約なしでも施術を受けられますか",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "空きがあればお受けします。当日の空き状況は電話でご確認ください。"
      }
    },
    {
      "@type": "Question",
      "name": "キャンセルはいつまでできますか",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "前日の18時までにご連絡いただければ、キャンセルを承ります。"
      }
    }
  ]
}
</script>

このコードの質問と回答は、そっくり同じ文面を、ページの画面にも載せます。それが前提です。

各行の意味

コードの各部分が何をしているかを、表にしました。

部分	書く内容	書き間違えやすい点
@context	schema.orgの語彙を使うという宣言	引用符の閉じ忘れ
@type（外側）	ページの種類としてFAQPage	1ページに1つで足りる
mainEntity	質問の一覧を入れる枠	質問が複数なら角括弧で並べる
Question の name	質問の文面	画面の質問と1字違いでも直す
acceptedAnswer の text	回答の文面	画面にない補足を足さない

JSON-LDでよく起きる書き間違い

コードの書き間違いは、中身より記号で起きます。

質問を2つ以上並べたときの、項目の間のカンマの付け忘れ。最後の項目のあとに余計なカンマを付けてしまうこと。全角の引用符が混ざること。この3つが、実務で見つかりやすい形です。

回答の文章に二重引用符が入るときも要注意です。そのままコードに写すと、文字列がそこで途切れてしまいます。

貼る場所：headでもbodyでもよい

冒頭のQ&Aサイトの質問に、公式の文書で答えます。

Googleの「構造化データの概要」のページは、JSON-LDを「HTMLページのhead要素とbody要素のscriptタグに埋め込むJavaScriptの記法」と説明しています。つまり、headとbodyのどちらに置いても、Googleは読み取れます。

同じページには、サイトの環境が許すならJSON-LDを使うことを勧める、という趣旨の説明もあります。理由は、サイトの持ち主にとって実装と保守が最も楽で、人為的なミスが起きにくいからです。

閉じタグの直前など「もっと良い位置」はあるか

公式の文書に、置く位置の優劣を示す記述は見つかりませんでした。位置による違いは、公式に記載なしです。

実務では、そのページの質問と回答に近い場所に置くと、更新のときに見つけやすくなります。公式の記述ではありません。弊社の運用上の整理です。

CMSやプラグインで入れる場合

構造化データの概要のページには、CMSを使っていてHTMLを直接編集できない場合の案内があります。CMSの検索エンジン設定のページがあるか、構造化データを指定できるプラグインを入れられるかを確かめる、という趣旨です。

また同じページに、JSON-LDはJavaScriptのコードやCMSの埋め込み部品でページに動的に挿入されても、Googleは読み取れる、とあります。

プラグインで入れる場合、実際のコードがページのどこに出力されているかは、ブラウザーで「ページのソースを表示」して確かめられます。ここまでが、置き場所の答えです。

守る決まり：画面に見えている質問と回答だけを写す

この型を書くときの決まりは、Googleの構造化データの一般ガイドラインに載っています。ここを外すと、せっかく入れたコードが逆効果になります。

判断の順番を、先に図でまとめます。

図の順に、1つずつ説明します。

見えていない内容を、マークアップしない

一般ガイドラインには「ページの読者に見えていない内容をマークアップしてはいけない」という趣旨の決まりがあります。たとえば、JSON-LDが出演者について書くなら、HTMLの本文も同じ出演者について書いていなければならない、という例が添えられています。

これに当てはめると、コードにある質問と回答は、すべて画面に見えている必要があります。

画面にない質問をコードにだけ足して、AIや検索エンジンに読ませようとする作業は、この決まりに触れます。

関係のない内容や、誤解させる内容を書かない

同じガイドラインは、無関係な内容や、利用者を誤解させる内容のマークアップも禁じています。ページの主題と関係のない質問を、コードに混ぜてはいけません。

守らなかったときに起きること

一般ガイドラインには、構造化データに問題があると手動対策の対象になりうる、とあります。手動対策を受けたページは、リッチリザルトとして表示される資格を失います。

ただし、Googleのウェブ検索での順位には影響しない、とも書かれています。

今のFAQPageは、表示の資格そのものが終わっています。したがって、ガイドライン違反で失うものは少ないのが現状です。それでも、画面とコードの食い違いは、情報として誤りを生みます。決まりは守るほうが無難です。

表示は保証されない

一般ガイドラインの冒頭には、正しくマークアップしても検索結果に表示されるとは限らない、という注意があります。理由として、構造化データは機能が出る可能性を作るだけで、出ることを保証しない点が挙げられています。

決まり	公式の趣旨	自社で確かめる方法
見える内容だけを写す	読者に見えていない内容はマークアップしない	コードの質問と回答を、画面の文章と1つずつ照らす
主題に関係させる	無関係な内容や誤解を招く内容は書かない	ページの主題から外れた質問が混ざっていないか読む
最新の内容にする	時間に左右される内容は、古くなると表示されない	料金や営業時間の質問を、更新日つきで見直す
読み取れる状態にする	robots.txtやnoindexなどで構造化データのあるページをGooglebotから遮らない	公開後にURL検査で、取得できているか見る
表示の保証はない	正しい書き方でも表示を約束しない	表示されなくても、不具合とは限らないと理解する

QAPageとの違い：サイト自身のFAQには使えない

schema.orgの定義では、FAQPageもQAPageも、質問と回答を扱う型です。ただしGoogleの文書は、使い分けを厳しく書いています。

QAPageの条件

Googleの「Q&A（QAPage）の構造化データ」のページでは、ページに1つの質問があり、その質問に対する回答が続く形式であること、そして「利用者が質問に回答を投稿できなければならない」ことが求められています。

利用者が代わりの回答を足す方法がないのに、1つの質問に1つの答えだけを載せたページには、QAPageを使ってはいけません。

使ってよい例と、いけない例

同じ文書は、使ってよい例として、利用者が1つの質問に回答を投稿できるフォーラムのページと、製品サポートのページを挙げています。

いけない例には、「サイト自身が書いたFAQのページで、利用者が別の回答を投稿する手段がないもの」が明記されています。ほかに、質問に答えるハウツーガイド、ブログ記事、エッセイも、いけない例です。

さらに、FAQのページや、1ページに複数の質問があるページには、QAPageを使うな、と書かれています。QAPageは、ページの焦点が1つの質問とその回答にある場合の型だからです。

自社のFAQで迷ったとき

自社のページ	向く型	理由
会社が質問と回答をまとめた、よくある質問のページ	FAQPage（Googleの表示は終了）	回答は会社が1つだけ書く
質問が1つで、利用者が答えを投稿できる掲示板のページ	QAPage	利用者による複数の回答がある
1つの質問に会社が答えるコラム	どちらも使わず、記事の型を使う	QAPageの文書がブログ記事を除外している
質問が何十個も並ぶ、サポートの一覧	FAQPage	1ページに複数の質問があるため

検索ギャラリーの一覧で確かめられること

Googleは「構造化データのマークアップ」の一覧ページで、検索の機能ごとに対応する型を示しています。2026年11月3日に読んだこのページには、Q&Aの項目はありましたが、FAQの項目は見当たりませんでした。

先ほどの更新履歴と合わせると、Googleは表示機能としてのFAQを、すでに扱っていないと読めます。

テストで確かめられること：リッチリザルトテストの一覧にFAQはない

書いたコードを確かめるときは、検証の道具を使います。ここで、FAQならではの落とし穴があります。

詳しい使い方は、別の記事で書いています。リッチリザルトテストの使い方とエラーの直し方をご覧ください。ここでは、FAQPageに関係する部分だけを書きます。

Googleのテストが対応している型

Search Consoleのヘルプには、リッチリザルトテストが現在サポートする型の一覧があります。2026年11月3日に数えると、31種類でした。

その一覧には、記事、パンくずリスト、ローカルビジネス、組織、商品スニペット、Q&Aページなどが並びます。FAQは入っていませんでした。

つまり、FAQPageのコードをこのテストに通しても、FAQの結果が出るとは公式に書かれていません。「アイテムが検出されませんでした」と出ても、コードの誤りとは限りません。

schema.orgの検証ツールの出番

schema.orgの公式サイトの上部には、「Validate」という入口があり、スキーマ マークアップ検証ツールにつながっています。名前のとおり、schema.orgの語彙として正しく書けているかを確かめるための道具です。

FAQPageのコードを確かめたいなら、こちらが本命になります。ただし、このツールが通ることは、Googleに表示されることを意味しません。

確かめ方の組み合わせ

確かめたいこと	使う道具	見るところ
コードの書式が壊れていないか	schema.orgの検証ツール	構文のエラーが出ていないか
Googleに取得されているか	Search ConsoleのURL検査	取得できたか、読み取れたか
画面とコードが一致しているか	目視（人の目）	質問と回答の文面が同じか
ページに実際に出力されているか	ブラウザーのページのソース表示	scriptタグが1か所に出ているか

AI検索との関係：公式に書かれていること

この型の話題に、AI検索がよく混ざります。公式の文書が何を書いているかを、整理します。

「AI機能とウェブサイト」のページの記述

Googleの「AI機能とウェブサイト」のページによると、AIによる概要やAIモードに出るための追加の要件はなく、そのための特別な最適化も必要ない、と書かれています。

さらに「AIのテキストファイルやマークアップを新しく作る必要はない。追加すべき特別なschema.orgの構造化データもない」という趣旨が続きます。

同じページは、構造化データがページの見えている文章と一致していることを確かめるよう、勧めています。

公式に記載がないこと

ChatGPTやGeminiなど、Google以外のAIが、FAQPageの構造化データを引用の判断に使っているかどうか。これは、2026年11月3日に確かめた公式の文書には、記載がありませんでした。

「FAQPageを入れると、AIに引用されやすくなる」と断定している記事もあります。ですが、公式の文書で確かめられない以上、この記事ではそう書きません。

詳しい整理は、別の記事で書いています。AI検索対策に構造化データは必要かも、あわせてご覧ください。

それでも置く意味はあるか：判断を表にする

ここまでの事実を並べると、置く意味は、サイトの状況で変わります。ここからは、公式の文書では決まらない部分です。弊社の整理として読んでください。

置く理由として成り立つもの

まず、置く側の理由です。schema.orgの公式サイトでFAQPageは今も有効な型で、書いてあること自体が誤りになるわけではありません。

CMSやテンプレートが、画面のよくある質問から自動でコードを作ってくれるなら、追加の手間はほぼありません。画面とコードが同じ元データから出るので、食い違いも起きにくくなります。

置かない理由として成り立つもの

次に、置かない側の理由です。Googleの表示が終わった以上、検索結果への見返りは、公式の文書から読み取れません。

さらに、手書きでコードを足すと、質問を直すたびに2か所を直すことになります。更新の漏れは、画面とコードの食い違いを生みます。

公式に記載がない部分は、期待しない

Google以外の検索エンジンやAIが、FAQPageをどう扱うかは、2026年11月3日に開いた公式の文書には記載がありませんでした。

確かめられない効果を前提にして、手間のかかる作業を足す必要はありません。期待は、確かめられた範囲にとどめるのが安全です。

サイトの状況別の判断

サイトの状況	判断	理由
FAQの画面から自動でコードが出る仕組みがある	そのまま置いてよい	手間がなく、食い違いも起きにくい
制作会社が手書きでコードを足している	運用の約束があれば置いてよい	質問を直すときに両方直す約束が必要
FAQの回答に、変わりやすい条件が多い	置かない	更新漏れが、誤った情報につながる
これから新しくFAQを作る	画面の文章を先に整える	コードより読者の疑問への答えが先
すでに入っているが、画面と合っているか不明	先に一致を確かめる	食い違いが見つかれば直すか外す

AIに読まれる側の整え方

AIの回答に自社のページが使われるために公式の文書が求めているのは、構造化データではありません。

Googleの「AI機能とウェブサイト」のページは、AIによる概要やAIモードで補足のリンクとして表示される条件を「ページがインデックスされ、スニペットつきで表示できること。追加の技術要件はない」という趣旨で書いています。

さらに、重要な内容がテキストで読めること、クロールが許可されていること、内部リンクで見つけやすいこと、を基本として挙げています。

よくある質問のページに当てはめると、質問を見出しにして、回答の1文目で結論を言い切る形が、読む人にも機械にも読みやすいと弊社は考えています。公式の記述ではありません。弊社の整理です。

FAQページそのものの作り方は、別の記事にまとめています。BtoB中小企業のFAQページの作り方と育て方で、質問の集め方から回答の書き方まで扱っています。

すでに入っているサイトはどうするか

制作会社が数年前に入れたこの構造化データが、そのまま残っているサイトは多いはずです。急いで外す必要があるのかを整理します。

外さなくてよい理由

2023年8月の公式ブログは、構造化データを外してもよいが、積極的に削除する必要はない、と書いています。使われていない構造化データは、検索に問題を起こさないからです。

2026年5月の表示終了のあとも、この考え方を変える記述は、更新履歴には見当たりませんでした。

外したほうがよい場面

外す理由が出てくるのは、画面とコードの内容が食い違っているときです。

たとえば、回答の文面を画面だけ書き換えて、コードの回答が古いまま残っている場合。この状態は、一般ガイドラインの「見える内容と一致させる」という決まりから外れています。

確かめる手順

手順	やること	結果の扱い
1	ページのソースを表示し、FAQPageを含むscriptタグを探す	あれば次へ、なければ作業は不要
2	コードの質問と回答を、画面の文章と照らす	一致していれば、そのままでよい
3	食い違う項目を、一覧にする	画面を正とするなら、コードを直す
4	直すのが難しければ、コード全体を外す	外しても、検索に問題は起きない
5	更新のたびに両方を直す決まりを作る	担当者を決めて、記録に残す

運用に落とす：質問を変えたら、コードも変える

これを残すにしても、新しく足すにしても、問題になるのは公開後の更新です。画面とコードを別々に持つことが、食い違いの原因だからです。

元データを1か所にする

食い違いを防ぐ一番簡単な方法は、質問と回答の元データを1か所に置くことです。画面の表示もコードも、そこから作ります。

CMSやテンプレートで元データから自動出力できるなら、手作業は要りません。できないなら、コードを入れない選択も十分に成り立ちます。

変更のたびに起きる作業を決める

料金の条件や営業時間、キャンセルの規定など、変わりやすい回答は、変更のたびに画面とコードの両方を直します。

担当者と確認の時期を決めておきます。たとえば、月の初めにFAQのページを見直す日を決めておけば、直し忘れが減ります。

変更履歴を残す

質問と回答を直した日付は、社内の共有文書に残します。あとで食い違いが見つかったとき、いつから違っていたのかを追えるからです。

制作会社に確かめる質問

制作会社に任せているサイトでは、次の質問をしてみてください。答えを聞くだけで、状況が分かります。

聞くときの前提

責める聞き方は不要です。ページのソースに何が書かれているかを、一緒に確かめたいという姿勢で十分です。

質問	聞く理由	望ましい答えの例
FAQの構造化データは、どのページに入っていますか	範囲を知るため	ページの一覧が出てくる
画面の質問を直すと、コードも自動で変わりますか	食い違いの起きやすさを知るため	元データが同じで自動で変わる
入れた目的は何でしたか	見返りの前提を確かめるため	今も有効な理由が説明できる
2026年5月のGoogleの表示終了を、反映していますか	古い前提のままかを知るため	把握していて、方針を説明できる
外した場合に、何か困ることはありますか	外す判断の材料にするため	公式の文書に沿った説明がある

よくある質問

Q. FAQPageを今から新しく入れる必要はありますか

検索結果の見た目を良くする目的なら、必要はありません。Googleの検索結果でのFAQ表示は、2026年5月7日から表示されなくなりました。

画面のよくある質問から自動でコードが出る仕組みがあるなら、そのまま置いても構いません。手書きで足す場合は、更新の手間と食い違いの危険を比べて決めます。

Q. すでに入っているFAQPageは、外すべきですか

急いで外す必要はありません。Googleは2023年8月の公式ブログで、使われていない構造化データは検索に問題を起こさない、と書いています。

画面とコードの内容が食い違っているときだけ、直すか外すかを決めてください。

Q. FAQPageを入れると、ChatGPTやGeminiに引用されやすくなりますか

公式の文書で確かめられた範囲では、言えません。Googleは、AIによる概要やAIモードに出るために追加すべき特別なschema.orgの構造化データはない、と書いています。

ChatGPTやGeminiがFAQPageを引用の判断に使うかどうかは、確かめた公式の文書に記載がありませんでした。

Q. FAQPageとQAPageは、どちらを使えばよいですか

会社が質問と回答を書くよくある質問のページなら、FAQPageの型です。QAPageは、利用者が1つの質問に回答を投稿できるページ向けで、サイト自身が書いたFAQには使えないとGoogleが書いています。

Q. コードは、headとbodyのどちらに入れればよいですか

どちらでも構いません。Googleの構造化データの概要のページは、JSON-LDをhead要素とbody要素のscriptタグに埋め込める、と説明しています。

位置の優劣を示す記述は、公式の文書には見つかりませんでした。

まとめ：型は残り、見た目の役目は終わった。残る問いは「画面と一致させられるか」

FAQPageの構造化データから作られていたGoogleのFAQ表示は、2026年5月7日に終わり、公式の説明ページも2026年6月15日に削除されました。見た目を目的にした新規の追加は、勧められる理由がありません。

置くかどうかの判断は、画面の質問と回答を、そのままコードに写し続けられるかにかかっています。自動で出る仕組みがあれば置いても構わず、手作業で更新の漏れが起きそうなら置かない選択が安全です。

AIの回答との関係は、Googleの公式の文書で確かめた範囲では、特別なschema.orgの構造化データは要りません。AIに読まれる側の整え方は、ページの本文を質問ごとに見出しで区切り、回答の1文目で結論を言い切ることです。

構造化データの全体像は中小企業の構造化データ入門に書いています。

制作会社に任せているサイトでも、ページのソースに何が書かれているかを、一度は一緒に確かめてください。

この記事で確かめた資料

2026年11月3日に開いて読んだ資料です。外部のリンクは貼らず、名前だけを示します。

資料	確かめたこと
Google検索セントラルのブログ「FAQとHowToのリッチリザルトの変更」（2023年8月8日）	FAQの表示が政府と健康分野のサイトに限られたこと。外す必要はないこと
Google検索セントラルの更新履歴	2026年5月7日からFAQの表示が終わったこと。2026年6月15日に文書が削除されたこと
Google検索セントラル「Q&A（QAPage）の構造化データ」	QAPageを使えない例にサイト自身のFAQが入っていること
Google検索セントラル「構造化データのマークアップ」の一覧	Q&Aの項目はあり、FAQの項目は見当たらないこと
Google検索セントラル「構造化データの一般ガイドライン」	見えていない内容を書かないこと。表示は保証されないこと
Google検索セントラル「構造化データの概要」	JSON-LDをheadとbodyの両方に置けること
Google検索セントラル「AI機能とウェブサイト」	追加すべき特別なschema.orgの構造化データはないこと
Search Consoleヘルプ「リッチリザルトテスト」	対応する型が31種類で、FAQは入っていないこと
schema.orgの公式サイト（FAQPage・QAPage・Question・Answer）	型の定義と、acceptedAnswerやtextの使い方

今日できる点検

次の表は、30分ほどでできる順に並べました。

点検項目	見るところ	結果の扱い
FAQPageが入っているか	ページのソース表示で、scriptタグを探す	なければ、ここで終わり
画面とコードが一致しているか	質問と回答の文面を1つずつ照らす	食い違いは、画面を正としてコードを直す
変わりやすい回答がないか	営業時間、規定、対応範囲の回答	更新の担当者を決める
入れた目的が分かるか	制作会社への確認、または当時の発注書	見た目が目的なら、外すか残すかを決める
元データが1か所か	画面とコードを別々に編集していないか	別々なら、更新の約束を作る
本文だけで答えが伝わるか	質問を見出しにし、1文目で結論を書いているか	弱ければ、画面の文章を先に直す
結果の記録	確認した日付とページ名	社内の共有文書に残す

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。