你的 FAQ 写得再好，搜索引擎可能根本没看见

你是不是也这样：吭哧吭哧整理了 10 个用户高频问题，答案写得比客服话术还细，结果搜“XX 怎么用”“XX 为什么报错”，首页还是看不到自己的页面？
不是内容不好，是搜索引擎压根没认出——那是一组 FAQ。

为什么结构化数据对 FAQ 如此重要？

结构化数据，说白了就是给搜索引擎递一张“说明书”：这儿是问题，那儿是答案，别当普通段落读。

有了这张说明书，谷歌才敢在搜索结果里直接展开你的问答。用户不用点进来，就能看到关键信息。这种展示叫“富媒体搜索结果”，点击率和曝光量都更稳。

一个做 SaaS 工具教程的团队，在三篇主力教程文末加了 FAQ 结构化标记。两周后，来自“XX 功能怎么设置”“XX 报错 code 502 怎么办”这类长尾词的自然流量明显提升——答案就挂在搜索结果第一屏，谁还往下翻？

FAQ 页面应该用哪种标记格式？

谷歌现在只认两种 Schema 类型：FAQPage 和 QAPage。选哪个，看你的 FAQ 是谁写的、怎么组织的。

  • 如果是编辑/运营人工梳理的、一问一答列好的清单（比如产品页的“常见问题”、文章末尾的“读者最常问”），就用 FAQPage。它天生为这种静态、可控的问答对设计。
  • 如果是社区帖子里用户提问 + 多人回复 + 最佳答案投票，那才是 QAPage 的地盘。

绝大多数内容网站的文章内嵌 FAQ，FAQPage 是唯一靠谱的选择。它结构干净，逻辑清晰，连新手都能一眼看懂。

手把手教你写 FAQPage 结构化数据

不用写新代码，也不用改前端模板。你只需要一段 JSON-LD 脚本，贴进网页 <head> 里就行。

核心就两样：Question（问题）和 acceptedAnswer（被采纳的答案）。每个问答对放进 mainEntity 数组里，几条 FAQ 就放几个对象。

下面这个例子，可以直接复制、改文字、粘贴使用：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "你们的服务支持退款吗？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "我们提供 30 天无理由退款服务。如果您在购买后 30 天内对服务不满意，可以随时联系我们客服申请全额退款。"
    }
  }, {
    "@type": "Question",
    "name": "如何联系客服？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "您可以通过网站右下角的在线聊天窗口，或发送邮件至 support@example.com 联系我们的客服团队。工作时间是工作日 9:00-18:00。"
    }
  }]
}
</script>

注意：mainEntity 是数组，每新增一条 FAQ，就在里面加一个 {} 对象。别漏逗号，也别多逗号——JSON 很较真。

标记 FAQ 时必须避开哪些坑？

写完代码≠万事大吉。谷歌不傻，糊弄它的标记，轻则不展示，重则被忽略。

第一坑：答案太水。
“是的”“请联系客服”“详见文档”——这类回答，谷歌直接跳过。答案必须是完整句子，能独立解决问题。比如“报错 502 是因为网关超时，建议刷新页面或稍后重试”，才算数。

第二坑：问题不在正文里。
你标记的每一个 name，都得原封不动出现在用户能看到的网页正文中。不能为了刷词，偷偷塞进“怎么破解会员”“后台数据库密码是多少”这种页面上根本没有的内容。

第三坑：拿用户评论凑数。
有电商团队试过自动抓取商品评论里的“好不好用”“发货快不快”，拼成 FAQ 去标记。结果富媒体结果断断续续，查了一圈发现：未审核的UGC内容，谷歌根本不信。换成运营自己写的、带步骤的实操答案后，展示立刻稳定了。

如何验证和测试你的标记是否有效？

别靠猜。两个免费工具，5 分钟搞定验证：

  • 富媒体搜索结果测试工具（Google Search Console 里就有入口）：粘贴你写好的 JSON-LD 代码，或者输入页面网址，它会当场告诉你：“检测到 FAQPage”“共识别 4 个问答”“预览效果如下”。错在哪，一目了然。

  • Search Console → 增强功能 → 常见问题解答：这里会列出你全站所有被谷歌成功识别的 FAQ 页面。如果有红色感叹号，点开就知道是哪条问答文本缺失、格式错误，还是 URL 没匹配上。

建议每周扫一眼这个报告。页面改版、FAQ 删除、答案微调——这些变动，都会在这里留下痕迹。

除了 JSON-LD，还有其他标记方法吗？

有，但别碰。

Schema 支持三种写法：JSON-LD、Microdata、RDFa。
JSON-LD 是谷歌官方文档里反复强调的首选，原因很实在：它是一整块独立脚本，扔 <head> 里就行，和 HTML 内容完全隔离。前端改版、CMS 升级，它纹丝不动。

另外两种得把属性硬塞进 <div itemscope itemtype="http://schema.org/Question"> 这类标签里。HTML 稍微一动，标记就断；模板一换，整片结构化数据就消失。维护成本高，出错率也高。

除非你在修十年前的老系统，否则 JSON-LD 是唯一该选的路。

今天下班前就能执行的一个操作

打开你最近一篇阅读量最高的文章（比如上周发的《XX 工具 5 个被低估的技巧》），滚动到文末——如果已经有 FAQ 小标题，就直接用；如果没有，花 8 分钟补上 3 个真实问题（比如“导出 CSV 格式乱码怎么办？”“协作编辑时别人改了我的内容，能找回吗？”）和对应的解决答案。

然后，照着上面的 JSON-LD 示例，把这 3 组问答填进去，生成一段新脚本。

打开 Google 富媒体搜索结果测试工具，粘贴脚本，点“运行测试”。看到绿色对勾 ✅，就说明没问题。

最后，把这段脚本复制，粘贴到这篇文章的 <head> 区域（如果你用的是 WordPress，主题编辑器里找 header.php；用语雀/飞书文档发布，就贴在自定义 HTML 插入位）。保存，发布。

做完这一步，去 Search Console 提交一下这篇 URL。接下来几天，盯紧“增强功能”报告里的变化——你亲手喂给谷歌的第一份 FAQ 说明书，正在被它读取、理解、展示。