2023年8月，我正在为一个法律服务客户进行审计时，Google悄悄投下了一枚炸弹：FAQ富文本搜索结果被"限制在权威政府和健康网站"。一夜之间，我在过去两年内为大约400个网站建设中所采用的策略就……停止了工作。没有手风琴式的摘要。没有加倍的搜索结果页面房地产。网站在标记中保留了FAQ schema，但视觉效果消失了。
我没有做的是：惊慌失措，撕掉schema。
这个本能证明是对的，原因我直到2024年AI概览开始正式推出后才完全理解，当时我开始在客户网站中执着地观察引用模式。FAQ schema的表现方式已经改变。但它现在在做其他事情，如果你理解那是什么，你就可以故意为其进行构建。
Google实际上杀死的是什么（以及没有杀死什么）
Google Search Central在2023年9月的公告很明确。大多数商业网站的FAQ标记的富文本结果资格被取消了。搜索结果中的下拉手风琴（那个加倍你的列表高度并压低你下面所有人点击率的东西）对99%的发布商来说已经消失了。
但schema本身呢？仍然完全有效。仍然可被爬虫抓取。仍然被索引。Google没有说"停止使用它"。他们说的是"我们不再为其显示花哨的搜索结果处理"。
这个区别现在非常重要。
这样想：结构化数据是你的内容和机器之间的翻译层。AI系统，无论是驱动AI概览的Google Gemini，还是Bing用来为Copilot提供信息的爬虫，或ChatGPT的网页浏览模式，它们都是试图大规模解析意图并提取事实答案的机器。Schema标记是你直接说它们的语言。
我在3月份使用Schema标记验证工具从四个电商客户那里提取了结构化数据报告，并将其与它们的AI概览引用频率进行了交叉参考（手动跟踪，我知道很痛苦）。高流量类别页面上具有干净、有效FAQ schema的网站的引用率大约是具有相同内容但没有结构化数据页面的2.3倍。样本量小。但足够一致，足以让我重视。
AI系统实际上如何提取引用
这是大多数schema指南变得含糊的部分。让我具体说明该机制的运作方式。
AI概览和Perplexity等工具并非在爬取搜索结果排名并选择顶部结果。它们做的更接近检索增强生成：提取与查询语义结构相匹配的内容块，然后合成答案。问题是什么信号有助于一个块首先被检索。
结构化为问答对的内容更容易被干净地检索。FAQ schema告诉爬虫"这个文本块是一个问题，相邻的这个文本块是它的答案"。该对随后成为一个连贯的单元。比较一下将相同信息埋在1,400字博客文章的第三段中而没有标记的情况，答案可能在那里，但机器必须更努力地隔离它。
Seahawk去年有一个金融科技客户，我们为其建立了产品对比页面，大约有18个FAQ项目在schema中，涵盖"如果应用崩溃我的钱会怎样"和"这是FCA监管的吗"之类的问题。该页面在自然排名中没有排在前三位。但它因监管问题在AI概览中被引用，因为答案是干净的、有界的，并明确标记的。这是转变。引用不再总是遵循排名。
权威来源问题
这里有个问题。AI系统越来越对来源敏感。例如，Perplexity倾向于偏好具有明确E-E-A-T信号的网站：展示的专业知识、具名作者、指向的外部链接。仅有schema不会拯救一个瘦弱的网站。但权威网站上的schema在放大该信号。
FAQ schema中的问答格式与作者的Person schema以及发布者的Organization schema配合得非常自然。在一个页面上同时运行这三种schema可以向任何机器阅读它的工具讲述一个更加丰富的故事。我大约在十八个月前开始在Seahawk客户项目中把这作为标准做法，我不会停止。
什么让一个FAQ条目真正值得被引用
并非所有的FAQ内容都是平等的。我审计过太多网站，有人在"你的营业时间是什么"和"你提供免费送货吗"这样的问题周围堆砌schema。这对本地SEO卫生来说还可以。但不足以获得一个试图回答实质性查询的AI系统的引用。
根据在数十个网站上的观察，能够赢得引用的FAQ条目往往有以下共同点：
- 具体性优于一般性。"FCA通常需要多长时间来授权一个新的支付公司"比"我如何获得监管"要好。问题越具体，越匹配真实人类输入的查询方式，效果就越好。
- 自成一体的答案。答案应该不需要阅读页面其余部分就能理解。如果你的答案说"如上所述"，它就还没准备好被引用。
- 一个数字、一个名字或一个日期。具体事实给答案加以锚定。"通常根据FCA自身的指导意见需要12到18个月"就是生成式模型想要复现的那种答案。
- 开头没有模棱两可的废话。"那是个很好的问题！有很多因素需要考虑……"是致命的。直接从答案开始。
- 长度在40到80字左右。足够有实质内容。短到足以被提取。
技术实现仍然必须正确
我见过这么多FAQ schema部署错误的情况，现在我把schema QA步骤作为任何Seahawk网站上线前的硬关卡。常见的失败模式：
- 在不是真正FAQ页面的页面上使用
FAQPageschema（比如底部有一个FAQ小工具的产品页面，Google不喜欢这样）。 - 嵌套JSON-LD不正确导致
mainEntity数组格式错误。Rich Results Test会立即捕捉到这一点。 - 在schema中包含页面上看不到的问题。这曾经有效过。现在它违反Google的指导原则，可能会触发手动操作。
- 跨多个页面使用重复的问题文本。为每个问题选择一个规范的首页。
- 在页面内容改变时忘记更新schema。我见过网站的schema仍然引用2021年的定价。
通过Rich Results Test和Schema Markup Validator来运行你的实现。它们捕捉的东西不同。两个都要做。
Yoast、Rank Math和手工JSON-LD
如果你在用WordPress，Rank Math的schema模块能够很好地处理FAQ schema生成，并让你将其绑定到自定义块。我今年早些时候在为一个SaaS客户的200页知识库构建中使用了这个，效果很好。Yoast也能做，但UI在大规模实现上更笨拙。
对于headless构建或任何WordPress之外的东西，我手工编写JSON-LD并将其放在<head>中。更多控制权。值得花这十分钟。
ChatGPT和Perplexity呢？
ChatGPT的浏览模式和Perplexity的爬虫方式都不完全像Google那样工作，它们在Google的结构化数据文档所描述的意义上都不正式"支持"schema。那么如果你追求那些引用，为什么还要费事用schema呢？
因为schema纪律性地规范你的内容结构。它强制你编写干净的问答对。那个底层结构就是被引用的东西，无论工具是否正式读取JSON-LD。
特别是Perplexity倾向于从答案出现在内容顶部、视觉上分离（标题、清晰段落）且与查询紧密匹配的页面抽取内容。FAQ schema促进的正是这样的内容架构。schema是脚手架。它执行的内容才是真正可被引用的资产。
我在去年秋天用一个房产行业的客户测试了这一点。两个页面，域权威值几乎相同，反向链接配置文件相似。一个有FAQ schema配有编写良好的问答对。另一个有一个以流畅散文形式编写的非结构化FAQ部分。在90天期间，Perplexity引用结构化页面11次，相比散文版本的2次。我用Perplexity自己的搜索界面手动追踪了这些，每两周输入一次关键查询。繁琐。但很有说服力。
你应该在每个页面上都添加常见问题解答架构吗?
不应该。我会反对任何建议将其作为通用策略的机构。
在以下情况下使用它:
- 你拥有真实的问答内容格式
- 页面针对信息类或考虑阶段的查询
- 你能写出具体、独立、事实依据充分的答案
- 页面背后有更广泛的E-E-A-T可信度支撑
不要在纯产品列表页面、首页主图区域或任何你为了有架构而生硬填充问题的地方使用它。Google会忽略它，Perplexity也不会在意。
我网络中获得持续AI引用的网站，并不是那些到处撒放架构的。它们是那些针对特定主题打造专门的高质量问答内容，然后正确标记的网站。
FAQ
常见问题解答架构在2025年还值得实施吗?
值得，但不是为了它曾经生成的SERP手风琴效果。现在的价值在于让你的问答内容对AI检索系统更易理解，包括Google的AI Overviews、Perplexity和Bing Copilot。拥有良好、有效的FAQ架构的精心编写的问答页面比没有架构的等效页面获得引用的速率明显更高。
常见问题解答架构会直接帮助我的排名吗?
不会直接帮助。架构从严格意义上讲不是排名因素。它的作用是改进机器对你内容的解析和检索方式，这可以增加你在AI生成答案中的引用率，进而影响零点击和接近零点击查询的可见性。这是一条间接的路径，但它是真实的。
每个页面应该包含多少个常见问题项目?
没有魔法数字。我通常的目标是五到十二个精心编写的项目，而不是二十个薄弱的。质量远比数量重要。每个项目都应该通过用具体、独立的答案回答一个真正不同的问题来赢得它的位置。
我可以在同时有HowTo或Article架构的页面上使用FAQ架构吗?
可以。只要每种架构类型都描述页面上真实存在的内容，单个页面上的多个架构类型就没问题。不要任意堆叠它们，但一篇在底部包含常见问题解答部分的长篇文章可以合理地同时使用Article和FAQPage架构。
检查我的常见问题解答架构是否有效的最快方式是什么?
进入Google的Rich Results Test，粘贴你的URL。它会告诉你你的架构是否可解析，以及它是否符合富结果处理的条件(即使该处理现在受限)。也通过Schema.org的验证器运行一遍，以获得第二意见。
---
局面发生了变化。AI答案占据了零点击空间的大部分，Google的SERP手风琴对商业出版商来说基本消失了。但结构化数据作为一种做法并不是遗物。它只是现在做不同的工作:帮助机器查找、解析和引用你的内容，而不是帮助Google呈现一个花哨的下拉菜单。正确实施，写出值得引用的答案，架构会在后台安静地完成它的工作。这仍然是合理的权衡。