# AI能不能帮助一个网站自动生成FAQ？

URL: https://caijiao.org/posts/200
Source: docs/posts/200.md
Description: 问题从搜索词和客服日志里捞的能生成，凭空想的生成不出有价值的一页。Omni Calculator 一个 test-grade 页面主词搜索量 5900，月流量 61086。

有个同事给站上每个产品页加了一组 FAQ，五个问题，全部由 AI 生成。加完三个月，那几组 FAQ 的点击率是零。

问题不在文案写得不好——写得挺通顺的。问题在于那五个问题没有一个是真的有人问的，它们是"关于这类产品人们通常会关心什么"的答案。这种 FAQ 的宿命就是没人看，因为它服务的不是用户，是页面看起来完整。

自动生成 FAQ 这件事是可行的，但可行与否几乎完全取决于**问题的来源**，而不是答案的质量。

## 问题必须从真实查询里捞

可用的来源按可靠性排序：

客服邮件和工单是最准的。用户实际敲出来的句子，带着他真实的困惑和真实的用词。一百封邮件里能捞出二十个高频问题，这二十个就是你的 FAQ 骨架。

站内搜索日志次之。用户在你的站里搜了什么，尤其是搜了但没找到结果的那些词，直接反映了内容缺口。

搜索引擎给的长尾词再次。它的价值在于量大、可批量获得，缺点是你只看到词，看不到人问这个词时的具体处境。Omni Calculator 那个例子很能说明长尾的力量：它 `/other/test-grade` 这个页面，主词搜索量 5900，带来的月流量是 61086——一个页面吃下的流量远超主词本身的量级，因为长尾全部落在了同一个页面上。

![Omni Calculator 官网首页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页把 Math 做成了最大的入口，688 个计算器全在这一格后面。*

最不可靠的就是让模型凭空生成问题列表。它生成的是"关于这个话题常见的疑问"，是通用知识，不是你这个站的用户的问题。两者可能重合一部分，但重合的那部分你在别处也能拿到。

## 答案里必须有页面没有的东西

这是第二个决定成败的点。

如果 FAQ 的答案只是把页面上已有的内容换种说法复述一遍，那这一组问答对搜索引擎和用户都是零增量。用户读完正文再看 FAQ，看到的是同一件事的另一种说法，不会有任何收获。

有价值的 FAQ 回答的是正文结构上回答不了的东西：边界情况、例外、和其他方案的对比、具体的限制条件。比如一个在线工具页，正文讲怎么用，FAQ 可以回答"文件大小上限是多少""处理完的文件多久删除""手机上能不能用""收费吗"——这些都是用户真的会犹豫、而正文里塞不进去的内容。

写这一层时 AI 很好用，因为它的任务是"基于我给的这些事实，回答这一个问题"，事实由你提供，它只负责组织语言。这个分工下产出质量相当稳定。

反过来，让它既定问题又写答案，等于把两个最需要真实输入的环节都交了出去。它会写出一篇挑不出毛病的 FAQ——措辞得体、结构工整、每句话都对——唯独没有人会搜这些问题，也没有人会从答案里得到新信息。这种页面最难被发现有问题，因为从质量检查的角度看它什么都没错。

## 结构化数据这块别偷懒

FAQ 页面加结构化数据是标准做法，但有几个细节容易出错。

标记里的问题和答案必须与页面上用户能看到的内容一致，不能把页面上没有的内容塞进标记里。答案字段里可以包含有限的 HTML 标签，但不能用脚本。还有一条常被忽略的：只有页面上真实可见的问答才能标记，把隐藏内容写进标记属于违规。

不同页面上的同一组问答不要重复标记，尤其是当你有一批结构相似的页面时——完全相同的一组 FAQ 挂在几十个页面上，本身就是信号。具体的字段要求和写法在 [JSON-LD](/json-ld/) 里有完整示例，照着写一遍比凭记忆写稳。

## 规模化的红线在哪

生成 20 组 FAQ 和生成 2000 组 FAQ 是两件性质不同的事。

前者的每一组你都能看一遍，确认问题真实、答案准确、和页面内容有关。后者的绝大多数你不会看，而其中一定会有错误——模型会把某个不适用于该页面的限制条件写进去，会把两个产品的参数搞混，会生成一句你根本做不到的承诺。

Google 的政策把这件事说得很明白：规模化内容滥用针对的是"大量生产对读者没有增量的页面"，而"用少量精力生成的页面"本身单独成罪。也就是说，即使你的 FAQ 内容是正确的，如果它是批量套模板生成、每个页面之间没有实质差异，风险依然存在。2025 年之后帮助内容系统的信号是整站级别的——一个目录下的低质量页面会拉低其他页面的表现，这一点在 [Google Search Central](/google-search-central/) 的文档里写得很清楚。

我的做法是给数量设上限，并且分层：每个页面最多五组问答，其中至少两组来自真实的客服或搜索来源；整站 FAQ 总量控制在几百组以内，超过之后宁可只给核心页面保留。宁可少，不要凑数。

## 怎么判断这一组 FAQ 值不值得留

上线一个月后看两个数据：有没有人点开、有没有人从 FAQ 区域继续往下一步走。两个都是零，就删掉。

留着的那些，你会发现它们的共同点——问题来自真实的人，答案里有正文装不下的具体信息。这两条不是 AI 能替你补上的，得你自己去捞问题和挖事实。AI 在这件事上负责的是最后那一公里：把已经确认的事实组织成通顺的回答。

---

*Omni Calculator 页面流量数据为第三方估算工具公开案例；Google 政策表述参考其搜索质量指南中 Scaled Content Abuse 与相关条目。*
