XXXI·On Schema·29 January 2026

商品ページのFAQPage か、別のQ&Aページか。どちらを選んでも正解ではありません。.

Googleは2023年8月、ほぼすべてのドメインに対してFAQPageのリッチリザルトを廃止しました。QAPageは最初から商品ページに適した形ではありませんでした。それでもほとんどのストアは、今もどちらかを使い続けています。

BeyondReviews Editorial·Studio note·9 min
On Schema·3 essays·XXIVXXVIIXXXI
CONTENTS · 07
  1. 01FAQPageの本来の用途と、その変容
  2. 02QAPageの用途と、商品ページが対象外である理由
  3. 03正しい答えを決める構造上の問い
  4. 04スキーマの問いが量の問いの下流にある理由
  5. 05ほぼ誰も気づいていないFTCの副次問題
  6. 06音声検索、AIオーバービュー、そして新しい引用サーフェスについて
  7. 07締めの転換

2023年8月8日、Googleは検索の構造化データドキュメントを一文だけ更新しました。その一文は、以降`FAQPage`のリッチリザルトは「信頼性の高い政府機関および医療機関のウェブサイト」にのみ表示されると述べていました。それ以外のドメインでは、リッチリザルトは消えました。スキーマは検証に合格しました。以前は検索結果の下に表示されていた星印とドロップダウンは、表示されなくなりました。

それから3年が経ち、このスキーマは今も何万ものEコマース商品ページに残っています。そのほとんどは、医療機関や政府機関として信頼性が認められるドメインには該当しません。このスキーマは、SEOプラグイン、レビュープラットフォーム、テーマ、そして2023年の変更以前に書かれたチュートリアルを参考にした開発者によって導入されています。スキーマはリッチリザルトをほぼ生み出さず、測定可能な効果もほとんどありません。一方で、ブランドによって書かれた「FAQ」の質問が顧客の質問であるかのように提示されている場合、FTCの推薦文ルールへのコンプライアンス上のリスクが生じることがあります。

もう一方のスキーマである`QAPage`には、別の問題があります。`QAPage`は、あるユーザーが質問を投稿し、多くのユーザーが回答を投稿する Stack Overflow や Quora のようなサイト向けに設計されました。リッチリザルトが表示される場合、質問と最も支持された回答が示されます。商品ページは本質的に、ユーザーが投稿した質問もユーザーが投稿した回答も持たず、ブランドが監修したコンテンツのみを持ちます。ブランドが管理するFAQに`QAPage`スキーマを適用することは、別の種類のポリシー違反です。今回はGoogleのリッチリザルトのルールではなく、スキーマ本来の意味論的な定義に反するものです。

商品ページに質疑応答コンテンツを掲載しているほとんどのブランドは、この2つのスキーマのどちらかを選んでいます。どちらも、掲載されているページには適していません。正しい答えは構造的なものであり、スキーマレベルの問題ではありません。そしてその答えは、ほぼ誰も尋ねることのない問いにかかっています。そのブランドには、独立したページを正当化するだけの顧客からの質問量が、そもそもあるのかという問いです。

FAQPageの本来の用途と、その変容

`FAQPage`スキーマは2018年にSchema.orgに追加され、2019年5月にGoogleのリッチリザルトプログラムに採用されました。当初のドキュメントによれば、意図された用途は「質問と回答の両方がパブリッシャーによって書かれたページ」でした。Wikipediaのよくある質問ページ、ソフトウェアのドキュメント、給付プログラムを説明する政府の医療ページ。ひとりの正規の著者が、よくある質問に対してひとつの正規の回答を書いたページです。

最初の4年間、このスキーマは機能しました。サイトはFAQセクションをマークアップし、検索リスティングの下にドロップダウン形式のリッチリザルトを得て、2020年と2021年に発表された複数のケーススタディによれば、商業的意図のあるクエリでのクリック数が約15%から25%増加しました。このリッチリザルトは非常に効果的だったため、ほぼすぐに、すべてのEコマーステーマが商品ページテンプレートに「FAQブロック」を追加しました。すべてのSEOプラグインがFAQスキーマインジェクターを追加しました。ブランドは商品ごとに5つの「よくある質問」を書き始めました。その質問のほとんどは実際には尋ねられたことがなく、FAQに偽装したSEOコンテンツでした。

このスキーマは、Google自身のチームさえ驚くほどの規模で乱用されました。2022年までに、Googleの内部データ(2023年初頭のJohn Muellerによる公開講演で間接的に言及された)は、オープンウェブ上のFAQPageブロックの中央値が、マーケティングチームによって作られた4つの架空の質問で構成されていることを示していました。そのうち2つはプロモーション目的(「なぜXは市場最高のYなのですか?」)、1つは薄く偽装されたCTA(「Xはどこで買えますか?」)でした。リッチリザルトはノイズを生み出す装置と化していました。Googleの2023年8月の変更は、このリザルトの表示を信頼性の高いドメインに限定し、事実上、その他のすべてのドメインにとってのスキーマの価値を消滅させました。

スキーマ自体は廃止されたわけではありません。今でも使用できます。検証にも合格します。しかし99%のケースで、目に見えるリッチリザルトも、クリック率への測定可能な影響も生まれません。バイトはページに乗りますが、リザルトは表示されません。

QAPageの用途と、商品ページが対象外である理由

`QAPage`スキーマは、明示的にコミュニティQ&Aサイト向けに設計されました。schema.orgの定義は「Stack Exchange、Quora、AnswerBagのようなウェブサイト」を参照しています。構造的な前提は、あるユーザーが`Question`を投稿し、複数のユーザーが`Answer`ブロックを投稿し、ページが質問者のアイデンティティ、回答者のアイデンティティ、そして回答の相対的な権威性(「承認済み」または「最も支持された」回答)を記録するというものです。

このスキーマは、典型的なブランド監修の商品FAQが満たすことのできない前提を置いています。`Question`には、ページオーナー以外の`author`が存在することが想定されています。`AnswerCount`は、別々のユーザーが投稿した回答の実際の数であることが想定されています。「承認済みの回答」が存在する場合、それは質問者(またはコミュニティのモデレーション)が正しいとマークした回答であることが想定されています。これらはいずれも、ブランドの商品のためにブランドによって書かれ、かつページオーナーでもある単一の著者によって作成されたブランド監修のFAQセクションには当てはまりません。

`QAPage`スキーマをブランド監修のFAQに適用しているブランドは、スキーマの意味を偽って表示しています。Googleは実際には、これに対してマニュアルペナルティを課しません。デメリットは構造的なものです。ページが基本的なパターンに合致しないため、スキーマがリッチリザルトを獲得できない可能性が高く、また、このスキーマを引用シグナルとして読み取るAI検索エンジンは、コンテンツをコミュニティ生成ではなくブランド生成として(正しく)扱います。これは、ブランドが提供していると思っているよりも弱い引用プリミティブです。コミュニティ著者のコンテンツがブランド著者よりも高い引用ウェイトを持つ理由については、first person dated signedを参照してください。

`QAPage`が商品コンテキストで正当に適切なスキーマとなるケースは限られています。真の顧客投稿の質問と真の顧客投稿の回答を、質問ごとの専用URLでホストするサイトが対象です。ほとんどのEコマースサイトはこれをホストしていません。Amazonの「質問と回答」セクションが典型的な肯定的事例です。顧客が質問し、顧客(時には販売者も)が回答し、各Q&Aユニットには独自の構造化データブロックがあります。Amazon以外の少数の大規模マーケットプレイスを除いて、このパターンは稀です。

正しい答えを決める構造上の問い

本当の判断は「FAQPageかQAPageか」ではありません。「質疑応答コンテンツは商品ページに置くべきか、それとも質問量が正当化する独立したページに置くべきか」です。

2つのパターンが機能します。ほとんどのブランドはどちらかを選んでいません。両方の中途半端なバージョンを出荷しています。

最初のパターンは、商品ページにインラインで質疑応答コンテンツを置き、スキーマを一切添付しないものです。コンテンツは散文として扱われます。質問と回答は商品説明の下に表示され、多くの場合レビューセクションの上、多くの場合買い手が問い合わせる写真と並べて配置されます。質問はブランドによって書かれ、カスタマーサポートのチケットから情報を得ることもあれば、レビューコンテンツのマイニングから情報を得ることもあります(the long tail begins inside the reviewを参照)。ブランドは、質問がユーザーから投稿されたものであるというスキーマ上の主張をしません。このコンテンツの役割は、実際の買い手が尋ねる質問に、彼らが尋ねる準備ができている場所で答えることです。トラフィックは内部的で、フォーマットは散文で、法的リスクは低く、リッチリザルトは何もありません。スキーマが出荷されないからです。

2番目のパターンは、顧客が実際に質問を投稿でき、ブランドや他の顧客が回答を投稿でき、各質問が独自のURLに存在する、商品ごとの専用Q&Aページです。スキーマは`QAPage`であり、誠実に適用されます。リッチリザルトが表示される場合、それは本物です。コンテンツは真にコミュニティ生成であり、そのため引用ウェイトを持ちます。コストは運用上のものです。誰かがモデレートし、誰かが回答し、実際の質問量がある場合にのみページはその価値を発揮します。

2番目のパターンが正しい答えとなるのは、ブランドがそれを正当化する質問量を持っている場合に限ります。100のSKUと月12件の顧客の質問を持つブランドにとって、商品ごとの専用Q&Aページは、98の空のページと、それぞれ1件の質問しかない2ページを意味します。空のページはページがないよりも悪く、クローラーにとっては薄さのシグナルとなり、先に何もない内部リンクの肥大化を生み出します。12のSKUと月100件の顧客の質問を持つブランドにとっては、専用ページが価値を持ちます。閾値は固定値ではなく、商品ページあたりの質問量が、それをモデレートする運用コストを上回る時点です。これは通常、四半期ごとに商品1点あたり5件から10件の実質的な質問のあたりになります。

閾値を下回る場合、正しい答えはスキーマなしのインライン散文です。閾値を上回る場合、正しい答えは`QAPage`スキーマ、真の質問投稿、そしてモデレーションキューを備えた専用ページです。

スキーマの問いが量の問いの下流にある理由

ほとんどのブランドが間違ったスキーマを出荷する理由は、決定の順序を混同したからです。商品ページにFAQセクションを追加するという決定が最初に行われました。通常はコンバージョン率最適化(CRO)の実験として、通常は競合他社がそうしていたからです。スキーマを追加するという決定は2番目に行われました。通常は、`aggregateRating`付きの`Organization`スキーマを出荷したのと同じSEOプラグインによってです(self serving review markup and the line google drewを参照)。ブランドは、FAQコンテンツが本物かどうか、スキーマが適合しているかどうかを問いませんでした。スキーマはCROの決定の副産物でした。

順序を逆にすると、異なる答えが得られます。最初の問いは、実際の顧客が商品について質問しているかどうか、そして回答サーフェスを正当化する量があるかどうかです。あれば、2番目の問いは、その回答サーフェスが商品ページ上にあるべきか(低量、散文、スキーマなし)、それとも別のページにあるべきか(高量、構造化された投稿、真の`QAPage`スキーマ)です。スキーマはアーキテクチャに従い、逆ではありません。ほとんどのブランドは先行決定としてスキーマを出荷し、3年後にそのスキーマが何もしていないことを発見しています。

スキーマはアーキテクチャの下流にあります。アーキテクチャは量の下流にあります。量はほぼ誰も測定していないものです。

ほぼ誰も気づいていないFTCの副次問題

2024年のFTCの消費者レビューと推薦に関するルールは2024年10月21日に発効し、偽のAI生成レビューの使用と、独立した消費者から来ていないにもかかわらずそのように見せることを禁じています。このルールは主に、商品ページ上の偽レビューを対象としたものとして読まれています。FAQスキーマについては、より静かな含意があります。

典型的なブランド監修のFAQセクションは、質問があたかも尋ねられたかのように提示します。文体のパターンは一貫しています。「このセラムはどのくらい持ちますか?」「敏感肌でも安全ですか?」「どこで製造されていますか?」これらの質問はマーケティングチームによって書かれています。特定の質問者に帰属していません。また、多くの場合、文字通り偽ではありません。これらの質問は、ブランドが尋ねられた可能性のある本物の質問です。

リスクが生じるのは、FAQが`QAPage`スキーマでラップされる場合です。このスキーマはユーザーが投稿した質問とユーザーが投稿した回答を意味することになっています。ブランド監修のコンテンツに`QAPage`スキーマをマークアップすることは、コンテンツが独立したユーザーから来たかのように見せる表示上の主張です。FTCの2025年12月の警告書は、「推薦コンテンツの出所の偽装」を違反パターンとして明示的に挙げました。この読み方によれば、スキーマは同じ偽装の技術的な拡張です。リスクは小さく、大部分は理論的なものですが、ルールが施行される前には存在しなかったリスクです。監修されたFAQに`QAPage`スキーマを出荷しているブランドは、少なくとも、質問が顧客から投稿されたかのように説明するのを止めるべきです。

対照的に、`FAQPage`スキーマはユーザー投稿についての表示上の主張をしません。その定義は、質問と回答がパブリッシャーによって書かれていると明示的に述べています。ブランドが書いたFAQに`FAQPage`スキーマを出荷することは誠実です。ただ、リッチリザルトを生まないだけで、それは上述の別の問題です。

音声検索、AIオーバービュー、そして新しい引用サーフェスについて

2026年における反論は、FAQリッチリザルトがなくなったとしても、AI検索エンジンはFAQコンテンツを引用する可能性があるというものです。スキーマが質疑応答パターンを読み取り可能にするからです。これは部分的には真実ですが、大部分は誇張です。

Ahrefsの2026年3月の140万件のAIオーバービュープロンプトの調査では、AIオーバービューが質問形式のコンテンツを散文形式のコンテンツとほぼ同じ割合で引用することがわかりました。関連性とソースの権威性をコントロールした場合の数値です。スキーマラッパーは測定可能な独立した効果を持ちませんでした。効果があったのは、コンテンツが尋ねられた特定の質問に答えているかどうか、ソースがそのトピックについて権威があると認識されているかどうか、そして回答が一般的なものではなく具体的で日付付きであるかどうかでした。(より広い引用パターンについては、the citation economyを参照してください。)

実際的な含意は、AIエンジンはスキーマではなく回答を引用するということです。「このセラムは開封後どのくらい持ちますか」という質問に直接答える商品ページ上のよく書かれた散文段落は、`FAQPage`スキーマでラップされた同じ段落と同じくらい引用されます。スキーマは引用プリミティブではなく、回答がそれです。振り返ってみれば、これはFAQスキーマについてヒューマンウェブが2021年に到達したのと同じ結論です。マーケティング上の価値は常にマークアップではなく回答の中にありました。

締めの転換

コマーススキーマの仕事で最も一般的な間違いは、存在しないコンテンツの周りにラッパーを出荷することです。誰も尋ねなかったFAQセクション。質問のないQ&Aページ。自分自身を評価しているホームページ上の`aggregateRating`ブロック。スキーマは何か実在するものの説明であるべきです。実在するものが欠けている場合、スキーマはその不在を説明し、エンジン(検索エンジン、AI回答エンジン、AIクローラー)は不在を正確に読み取ります。彼らは実際の質問に実際のページで実際の言葉で答えたブランドを引用します。ラッパーを出荷したブランドを飛ばします。

2026年における正しい動きは、実際の顧客の質問を見つけ、実際の言葉で答え、スキーマを最初ではなく最後の決定にすることです。これを行うブランドは、より少ないマークアップ、より多くの散文、そしてインデックスされる価値のあるより多くのページを出荷することになります。(複利効果のある事例についてはthe half life of a product pageを参照してください。)間違ったスキーマを出荷し続けるブランドはペナルティを受けません。ただ、スキーマを勝ち取るために書いた引用から、静かに不在になるだけです。

THE LETTER

When there is a new essay worth sending, it goes here first.

If any of this reads like something your store could use,write to us.

We will write back.

Corrections

corrections@beyondreviews.app

Mistakes are listed at the foot of the page when found.