我们用自己开发的 AI 可见度扫描器自测，得了 75 分——然后一路修到 92 分

我们花了好几个月开发 GetCiteFlow——一款告诉企业其内容在 AI 搜索引擎中可见度如何的工具。然后我们做了一件让人有点不安的事：拿它扫了我们自己的官网。结果不太好看。我们公开分享这次自检的完整过程：发现了什么、修了什么、按照什么优先级修、最终效果如何。如果你是做 SaaS 或内容营销的，你大概率也中了同样的坑。

真相时刻：我们给自己打了 75 分

去年我们发布了 GetCiteFlow 的第一个内部版本。这个工具的定位很明确：告诉企业它们的内容在 ChatGPT、Perplexity、Google AI Overviews 等 AI 搜索引擎中的可见度有多高。我们积累了第一批客户，迭代了扫描逻辑，优化了评分模型。然后有人说了一句话："我们应该拿它扫一下我们自己。"会议室安静了几秒。

扫描结果出来了：getciteflow.ai 的 AI 可见度评分是 75/100。对一款告诉别人怎么做 AI 优化的产品来说，这个分数不丢人——大概处于"还不错"的上半区。但也不令人满意。我们的产品卖点是帮客户达到 85+，自己却只有 75。我们决定把找到的每个问题列出来，按影响排优先级，然后一项一项修。

扫描发现了什么（不太好看的真相）

GetCiteFlow 的扫描器对网站做了多维度的诊断，从实体清晰度到结构化数据到跨来源一致性。对于 getciteflow.ai，它指出了四个问题。

1. 缺少 FAQ Schema：我们的定价页、产品页和文档页没有标记任何 FAQPage 结构化数据。这意味着 LLM 无法直接从我们的网站提取问答对——它们必须解析整段文本来尝试理解我们做什么，增加了提取出错或被跳过的概率。
2. 缺少 llms.txt 文件：我们根本没有生成这个文件。对于 AI 爬虫来说，这相当于你的网站在说"我不知道你想让我看什么，你自己随便翻吧"。llms.txt 是告诉 LLM 哪些页面重要、每个页面是什么的标准方式——而我们没提供这张路线图。
3. 实体清晰度弱：我们的网站用了至少 6 种不同的方式描述自己——"AI 可见度平台""GEO 工具""品牌引用监控""生成式搜索优化""AI 搜索分析""内容 AI 优化"——同一产品在不同页面上的标签都不一样。模型看到的是一堆互相矛盾的描述，无法形成一个清晰的实体画像。
4. 内容未针对 AI 提取做结构化：我们的博客文章是纯文本流，没有对比表格，没有 FAQ 区块，没有定义列表。内容本身质量够好，但结构不支持 AI 快速提取关键信息。

我们修了什么（按影响排序）

修复 1：构建 llms.txt（2 小时）

这是最快见效的修复。我们创建了一个 llms.txt 文件放在网站根目录，列出了所有核心页面及其描述和优先级。同时生成了一个 llms-full.txt——包含所有核心页面完整内容的单一文件，方便 LLM 一次性检索。文件结构清晰：产品页、功能页、文档入口、核心博客文章，各有明确的简短描述。完成上线后，AI 爬虫能在第一次请求时就了解整个站点结构，而不是靠猜测爬取。

修复 2：添加 FAQ Schema（1 小时）

我们在定价页、产品主页和文档首页上各添加了 5-8 个 FAQPage 标记的问答对。问题直接来源于客户实际问过的问题——"GetCiteFlow 是什么""和 SEO 工具有什么区别""数据来源是什么""支持哪些 LLM""如何计费"。每个答案都写成自包含的段落，确保脱离页面上下文后依然完整可读。用结构化数据测试工具验证通过后部署上线。

修复 3：统一实体定义（3 小时）

这是最耗时的修复，但不是因为它技术上复杂——是因为需要协调。我们决定用一句话作为所有页面的标准实体定义："GetCiteFlow 是一个 AI 可见度平台，帮助团队监控和优化其内容在 ChatGPT、Perplexity、Google AI Overviews 等生成式引擎中的引用情况。"首页、产品页、文档、博客的作者框、OG 描述——全部统一到这句。我们把它放进了 Schema.org Organization 标记的 description 字段和 llms.txt 的第一行。

修复 4：重构博客内容结构（1 天）

我们选取了 5 篇流量最高的博客，做了结构性重写：每篇开头加入"核心要点"列表，正文中引入对比表格和编号清单（ol），在关键声明旁添加数据锚点，并为包含问答内容的文章补充 FAQ Schema。这不是对文章本身的重写——论点、数据和结论全部保留——而是对页面 DOM 结构和语义节点的重新组织，让 AI 提取管道能找到明确的提取目标。

效果：75 → 92

修复上线两周后，我们再次用 GetCiteFlow 扫描。得分从 75 提升到 92。拆开来看：FAQ 覆盖率从 0% 变为 100%（核心页面均覆盖），实体清晰度从"模糊——6 种互相矛盾的定义"变为"清晰——1 种统一定义在所有页面中一致出现"，llms.txt 从无到有，内容结构评分从"未结构化的文本流"变为"关键页面具备可提取结构"。

更重要的是实际引用表现的变化。修复后几周内，我们观察到 ChatGPT 和 Perplexity 中对 GetCiteFlow 的引用中，引文片段变得更加精准——从之前通用的描述性提及变为引用具体的产品定义和功能描述，直接取自我们在 FAQ Schema 和实体定义中精确写下的文字。

更深层的反思：为什么要先吃自己的狗粮

这次自检最深刻的收获不是技术层面的，而是方法论层面的：构建一个你需要的工具，然后在公开发布前先用它来检视你自己。你会比任何 beta 用户都更早地发现盲区。我们开发 GetCiteFlow 时的假设是"大多数网站缺少实体清晰度和结构化数据"。扫了自己之后我们意识到问题比假设的更深：即使你懂这些概念，执行层面仍然会在流程缝隙中漏掉。FAQ Schema 不是技术难题，它只是不在内容团队的标准工作流里。llms.txt 不是开发排期的遗漏，它是因为没有流程要求生成它。

给你自己网站的实操建议

1. 先做一个 llms.txt：列出核心页面并配上简短描述。放在网站根目录。这是所有修复中工时最短、最便宜、最不应该不做的。如果只做一件事，先做这个。
2. 把 FAQ Schema 加到标准内容流程中：每次上新产品页、定价页或文档页，强制要求附 5-8 个 FAQPage 标记的问答对。把它写进内容 checklist，不然团队永远会跳过。
3. 用一句话定义每个核心实体：产品是什么，属于哪个类别，解决什么问题。把这句放在所有页面的同一位置（如首段或 Schema 标记），不要在每个页面上重新措辞。
4. 把对比表格和编号清单作为博客的默认结构元素，而不是可选项。AI 提取管道优先处理这些格式，纯文本流是被动兜底。：把对比表格和编号清单作为博客的默认结构元素，而不是可选项。AI 提取管道优先处理这些格式，纯文本流是被动兜底。
5. 定期扫描自己：用你自己的工具或第三方工具。修复后再扫一次，追踪趋势。AI 可见度不是一次性的项目，它是一个需要持续维护的信号体系。