AI 可见性审计：20 项检查清单

这份审计到底在打分什么

在成为品牌问题之前，它首先是个点击率问题。Pew Research Center 追踪了真实的 Google 用户，发现当页面出现 AI 摘要时，用户点击传统搜索结果的比例为 8%，而没有摘要时为 15%——而且只有 1% 的人会点击摘要内部的链接。成为摘要赖以生成的信息源，远比排在摘要下面更重要。

所以这份审计按严格的依赖顺序考察五件事。抓取可达性决定检索代理能否读到你；实体一致性决定模型能否把你的名字唯一地对应到一家机构；外部口碑决定你自家域名之外有没有东西佐证你的说法；可引用性决定你的句子能否在抽取中存活；可衡量性决定你能否判断以上任何一项是否真的变了。

每一项只判通过或不通过，不给半分。给半分，正是审计报告膨胀成 40 页却没人执行的原因。20 项检查、20 个二元答案，然后从上往下解决未通过项。关于这门功课为什么存在的整体背景，可以看我们那篇 AI 可见性 入门。

第一部分 —— 面向 AI 的抓取可达性（第 1–4 项）

检索代理和训练爬虫不是一回事，大多数 robots.txt 的错误就出在没分清这一点。OpenAI 在其 爬虫说明文档 中列出了三个独立的 user agent——用于训练的 GPTBot、用于搜索索引的 OAI-SearchBot，以及由用户实时触发抓取的 ChatGPT-User。Anthropic 在 官方支持文章 中说明了 ClaudeBot 及其屏蔽方式，Perplexity 则公开了 PerplexityBot 与 Perplexity-User。屏蔽训练爬虫是一个合理的商业决策；误伤检索代理则是自残。

Copilot 的回答依赖 Bing 索引，因此如果你没有在 Bing Webmaster Tools 完成验证，就等于在六大助手中的一个上完全摸黑。

• 1. robots.txt 放行检索代理。 检查：抓取自己的 /robots.txt，搜索 GPTBot、OAI-SearchBot、ChatGPT-User、ClaudeBot、PerplexityBot、Perplexity-User、Google-Extended 和 Bingbot。通过标准：所有检索代理在商业关键路径上均被允许，且任何对训练爬虫的屏蔽都是有据可查的主动决策，而不是照抄的模板。
• 2. 边缘层没有拦截。 检查：用每个代理的 user-agent 字符串，从机房 IP（而不是办公室网络）curl 你最重要的五个 URL。通过标准：返回 HTTP 200 和完整 HTML——而不是 403、429，或者 WAF/CDN 弹出的人机校验页。
• 3. 内容存在于首屏 HTML 中。 检查：查看网页源代码，或在禁用 JavaScript 的情况下抓取。通过标准：标题、正文、价格、参数和关键事实在前端 hydration 之前就已存在。如果你的产品页只是一个空 div，那么无论 robots.txt 怎么写，你都是隐形的。
• 4. 站点地图、canonical 和速度都正常。 检查：每一个与收入相关的 URL 都出现在 XML sitemap 中、返回 200、并带有自引用 canonical。通过标准：没有孤岛页面，没有指向重定向链的 canonical，HTML 返回速度足够快，能在带超时限制的抓取中完成。

第二部分 —— 实体一致性（第 5–8 项）

模型回答“X 是谁”时，实际上是在一堆相互矛盾的文本里做实体消歧。如果你在四个渠道上分别叫“Acme”“Acme Inc.”“Acme Software”和“ACME”，而相邻市场里还存在另一家 Acme，助手要么含糊其辞，要么把两者揉在一起。揉在一起比查无此人更糟：你会继承别人的价格和别人的差评。

结构化数据是你手上最便宜的消歧手段。Google 的 结构化数据文档 讲清了写法，而真正承担身份识别工作的是 sameAs 属性——它把你的站点和描述同一实体的外部资料页连起来。

• 5. 只有一个标准名称写法。 检查：在首页、页脚、LinkedIn、Crunchbase、点评类资料页和新闻通稿模板里逐一核对法定名称和商用名称。通过标准：各处的拼写、大小写和后缀完全一致，变体只作为明确标注的别名出现。
• 6. 带 sameAs 的 Organization 结构化数据。 检查：把首页放进结构化数据校验工具跑一遍。通过标准：存在有效的 Organization（或 LocalBusiness）节点，包含 name、url、logo、description，以及指向你已验证外部资料页的 sameAs 数组。
• 7. 各平台资料页保持一致。 检查：把你能掌控的所有资料页并排打开——LinkedIn、Crunchbase、G2、GitHub、应用商店、本地商户信息。通过标准：一句话简介一致、成立年份一致、所属类目一致、地址和电话一致、URL 格式一致。
• 8. 有一个可被解析的公开身份。 检查：在 Wikidata 和 Wikipedia 上搜自己的名字，看返回什么。通过标准：要么有一条正确的 Wikidata 条目，按 Wikidata 收录标准 填好了所属行业、成立日期和官网；要么至少做到——搜你自己的名字时，没有别的同名实体排在你前面。

第三部分 —— 站外赢得的信号（第 9–12 项）

助手拉候选名单时，依赖第三方来源远多于依赖厂商官网。当有人询问某个品类里最好的工具时，模型通常是在综合清单文章、点评平台、媒体报道和社区讨论。你自家的对比页在这个组合里是弱输入；一篇本来就在该查询下有排名的媒体盘点文章，才是强输入。

这是见效最慢的一类，恰恰因此才要尽早审计。做到第六个月才发现自己在所有品类盘点里都缺席，这个代价远高于发现一个 robots.txt 配置错误。

• 9. 品类盘点文章的覆盖度。 检查：用买家真实会问的十条“最好的[品类]，适合[场景]”查询跑一遍，列出前十条自然结果，记录其中有几篇提到了你。通过标准：出现在半数以上，且描述准确。
• 10. 点评平台的数量与新鲜度。 检查：在你所在品类最关键的两三个点评站上，统计总评价数、最近一个季度的评价数，以及其中有多少条包含实质性文字而非只有星级。通过标准：近期有稳定的新增，且文字量足够让模型引用出某个具体优势。
• 11. 独立媒体提及。 检查：搜索品牌名，排除自有域名和新闻稿分发渠道。通过标准：至少有若干篇独立文章，用一句话描述了你在做什么，且这句话模型可以直接照搬。
• 12. 社区存在感。 检查：在 Reddit、Stack Overflow、Hacker News 以及买家常混的垂直论坛上搜品牌名。通过标准：存在客户描述实际效果的真实讨论帖——不是只有自己团队在发帖，也不是一整片无人回复的投诉。

第四部分 —— 内容的可引用性（第 13–16 项）

可引用性是一种写作约束，不是内容产量指标。模型抽取答案时，想要的是一个自足的命题，脱离上下文段落也能直接引用。铺垫三段才给定义的文案，等于什么都没给它。以一句平实的陈述句开头，把主体、定义和限定条件一次说清，才会被引用。

第二条约束是具体。“上手快”无法被引用；“标准 Shopify 环境下的配置耗时不到 30 分钟”可以被引用、可以被核实、也可以被原话转述给用户。数字、单位、日期和明确的前提条件，都会提高你这句话在抽取中完整存活的概率。

第三条是坦承边界。助手经常被问到比较类问题，而明确写出“产品不适合谁”的页面，通常比宣称“人人适用”的页面被视作更可信。

• 13. 答案前置的结构。 检查：把十个最重要页面的前 40 个词单独拎出来读。通过标准：每一段都能作为独立句子回答标题里的问题，且不含需要回看上一段才能理解的代词。
• 14. 事实都带单位和日期。 检查：把关键页面上的每条主张都标出来，自问一个陌生人能否核实它。通过标准：数量、时长、价格、限制和集成能力都明确写出，任何会变动的数字都注明日期。
• 15. 对比页和定价页写清自身边界。 检查：有没有哪一页说明了产品不适合谁？通过标准：有明确的“以下情况不推荐使用……”板块，且价格直接写在站点上，而不是藏在留资表单后面。
• 16. 结构对机器友好。 检查：标题层级、表格、FAQ 模块和 URL 稳定性。通过标准：H2 用买家真实会问的问句来写，参数用表格而非大段文字呈现，URL 稳定，页面更新时不发生变动。

第五部分 —— 可衡量性（第 17–20 项）

即便提示词完全相同，助手每次生成的答案也会不同，所以问一次只能算轶事。所谓衡量，是指一组固定提示词，在多个助手上反复执行，并把结果存下来，这样你才能对比两个日期，并把变化归因到自己做过的某项改动上。

提示词要从买家真实使用的语言里提炼——销售通话记录、工单、搜索后台里的查询词——而不是从关键词工具里扒。按意图阶段分组：品类发现、候选对比、异议处理、品牌词查询。在候选对比类提示词里从不出现，和在品牌词里出现但描述错了，是两个完全不同的问题。

这一部分正是 Growli（我们的产品）负责自动化的环节：我们按排期把你的提示词集在 ChatGPT、Gemini、Claude、Perplexity、Copilot 和 Grok 上跑一遍，追踪提及率、竞品声量占比、情感倾向以及各助手引用的 URL，然后按投入产出对缺口排序。产品原理 里讲了具体机制。

• 17. 有一份成文的提示词集。 检查：是否存在一个按意图阶段分组、包含 30–100 条提示词的文件？通过标准：提示词用买家的语言写成，覆盖品牌词与非品牌词意图，并纳入版本管理，改动可追溯。
• 18. 多助手、可重复的跑批。 检查：覆盖了几个助手？每个提示词每周期跑几次？通过标准：至少四个助手，每条提示词跑多次，且有存档的历史记录，而不是聊天群里的几张截图。
• 19. 竞品与定性追踪。 检查：你是否记录了哪些竞品与你同时出现、以及你被如何描述？通过标准：能按提示词分组给出具名的声量占比，并对事实性错误的描述打标——这类问题是整份审计中优先级最高的。
• 20. 被引用的来源与转介流量。 检查：助手在谈及你所在品类时引用了哪些 URL？你的分析工具是否单独切分了来自助手域名的转介流量？通过标准：有一份按重要性排序的第三方页面清单（它们在喂养该品类的答案），以及一个已保存的、面向 AI 助手转介来源的分析视图。

如何打分，并把未通过项变成待办队列

把通过项加起来。16 分及以上，说明你的问题是竞争层面的而非结构层面的——把精力投向站外口碑，以及那些被竞品统治的具体提示词。11 到 15 分之间是混合状况：第一周先修抓取可达性和实体一致性这两类，因为它们卡住了下游的一切。10 分及以下，那么在抓取通路和实体图谱清理干净之前，根本不该再立项做新内容。

顺序比分数更重要。抓取可达性一旦不通过，问题存在期间的所有内容投入都会作废，而它往往只是 CDN 上改一行配置的事。实体类问题以天计，可引用性重写以周计，站外口碑以季度计。按这个顺序推进，每一次修复都会叠加在上一次之上，而不是浪费在助手压根抓不到的页面上。

完整审计每季度重跑一次，衡量类的几项则持续运行。爬虫的 user agent 会变，安全同事会悄悄收紧 CDN 规则，评价的新鲜度会衰减，品类盘点文章会被重写、而新版里没有你。这份审计是一项常态控制手段，不是一次性项目。

FAQ