一句话：FAQ 块是一个问题配一段自洽的答案，出现在渲染后的 HTML 里，并在 FAQPage 结构化数据里镜像一份——而它的故障形态几乎总是「标记描述了页面并不显示的内容」。

为什么这个形状这么合适

答案引擎检索段落，需要的是一个「问题到答案」的映射。FAQ 块恰好把这个直接递给它，已经切好段，不需要任何推断。在所有可用的结构化数据类型里，它是形状与消费方需求最贴合的那一个。

毁掉它的那种滥用

给页面从不渲染的内容生成 FAQPage 标记。这很诱人：schema 从数据文件里很容易吐出来，页面还保持视觉干净。但这份标记描述的是一张不存在的页面，而一个把标记与渲染内容对照的系统，有理由把两者都打折。

如果这个答案值得标记，它就值得显示。结构化数据是关于你页面的一条论断；一条被页面本身推翻的论断，代价比不写更大。

折叠块同理。收起来的 FAQ 没问题——内容在 HTML 里，只是用 CSS 藏起来了。点击时才去取答案的 FAQ 就不行；服务端渲染的页面上有问题，一个答案都没有。

怎么写答案

  • 自洽。答案必须经得起被剪出来。「取决于你的套餐」没法用；「导出功能在专业版与企业版上提供」可以。
  • 点明主语。不要用依赖上方问题才成立的代词。
  • 两到四句。长到完整，短到能被整段抬走。
  • 真实的问题。从你的客服邮箱、销售通话和 Search Console 查询里取——不要从关键词工具里取。问句形态的查询已经在进来了：2026 年 9 月我们自己的数据里，475 个产生曝光的查询有 181 个是完整问句或七词以上。
  • 回答那些尴尬的问题。价格、局限、你不做什么。买家之所以会拿这些去问助手，恰恰是因为厂商都在回避，所以这块地是空的。

放在哪儿

放在回答这个问题的那张页面上，不要放进一个集中的 FAQ 页。定价问题属于定价页，集成问题属于集成页。一个巨型 FAQ 页把答案从「让它可信的那个上下文」旁边搬走了，而且会为同一批查询和你自己的页面竞争。

怎么验证

把页面真正输出的 JSON-LD 提取出来，逐条对照关掉 JavaScript 后读者看到的内容。模板改动之后再查一次，因为标记和内容是悄悄分道扬镳的，而第一个迹象通常不是报错——是被引用的页面缓慢减少。