大家好，我是Neo。

Search Console 里有一份“网页”报告，告诉你哪些页面被收录、哪些没收录。Bing 有 Webmaster Tools，也有类似的清单。

但 AI 搜索没有。

于是每个做独立站的团队都会遇到同一个死循环：老板说“ChatGPT 从来不提我们”，你说“可能它没抓到”，老板问“那你怎么知道”，你说不出话。因为没有一个面板可以让你看“我的页面在不在 AI 的检索范围里”。

9 月 18 日，Search Engine Journal 上 Chris Green 发了一篇很短、但方法很实用的文章（是他自己博客的转载），讲的正是这件事：用一个 SEO 圈用了几十年的老技巧，去测 AI 检索这一层。

这篇我把它整理成一个可以直接执行的版本，并且补上我自己会加的两步交叉验证。

方法本身：用一段原话去“钓”你的 URL

思路来自我们都很熟的两个老操作：

• 想确认页面有没有被收录，就用 site: 操作符；
• 想确认内容有没有被索引，就从页面上复制一段足够长、足够独特的文字，加引号搜索。

Green 的做法是把第二步搬到聊天机器人里。提示词大致是这样：

Search for “把你要测的原文段粘贴在这里” and return any results which contain that exact text only. （搜索这段文字，只返回精确包含这段文字的结果。）

注意要测的是带搜索工具的对话（ChatGPT 的联网搜索、Gemini、Perplexity、Copilot 都行），不是纯聊天模式——纯聊天模式只会从训练记忆里编。

结果怎么读：

• 机器人返回了你的 URL → 说明它调用的那个搜索源里含有这段内容，而且归属无误地落到了你的 URL 上。技术上看，这个页面是“可被检索”的。
• 不返回 → 才是真正有价值的时候，因为你现在有了一份排查清单。

Green 自己反复强调的是：这不是替代品，也不是真相。 机器人的回答要解释着用——同一段话要测 4–5 次，还可能因为不同引擎调用不同的搜索源而出现差异；结果含糊时，换一段话、换一个引擎再测。

不返回的时候：按这个顺序排查

顺序本身就是依赖关系，上面不通，下面全都白做：

顺序	问题	具体怎么查
1	页面能被发现吗？	有没有内链、在不在 sitemap 里？Green 特别点出一种情况：AI 批量生成的内容被故意做成“孤岛页”，从任何地方都点不到
2	页面能被抓取吗？	被 WAF、防火墙或 robots.txt 拦了没有？注意 AI 检索爬虫是另一套名字，见下一节
3	页面能被渲染/抽取吗？	正文是不是只在 JS 执行后才出现？爬虫拿到的是不是一张空壳
4	页面能被索引吗？	有没有 noindex；canonical 是不是指向了别的地方
5	内容够独特吗？	你挑的这段会不会太“通用”，即使抓到了也拼不过别人的版本
6	时间够吗？	可能只是还没被发现或还没被收录，这部分只能等

第 5 条 Green 说得很实在：如果你的页面内容独特到“用一段原话都钓不出自己”，那它大概本来也不会是一个有价值的页面。

补一步：先把“名字”这件事做对

上面第 2 步里藏着一个高频事故：很多人查了 GPTBot，就以为查完了。

AI 相关的抓取器是分开的，各管一摊：

用户代理	谁在用	干什么
GPTBot	OpenAI	训练/索引抓取
OAI-SearchBot	OpenAI	ChatGPT 搜索的检索抓取
ChatGPT-User	OpenAI	用户分享链接时实时抓取
ClaudeBot / Claude-SearchBot	Anthropic	Claude 的训练与检索
PerplexityBot	Perplexity	Perplexity 搜索结果
Google-Extended	Google	Gemini / Vertex AI 的训练控制

这也是为什么“我在 robots.txt 里把 GPTBot 挡了，怎么 ChatGPT 还在引用别人”这类困惑很常见——你挡住的是训练，检索可能是另一行。 反过来也一样：为了训练-data 的立场屏蔽了 GPTBot，顺手把检索通路也废掉了，这是不少出海站踩过的坑。

行业里几份第三方审计给出的数字不完全一致（有的说约 19% 的站点对 AI 代理完全不可访问，有的说约 30% 的站点在不知情的情况下屏蔽了 AI 爬虫），但方向是一致的：最常见的失效点是“访问”，不是“内容”。 团队第一反应往往是去重写文章，而真正的问题是一行 robots.txt 或者一个渲染选择。

Neo的解读：这跟前面两篇（9 月 4 日的屏蔽 AI 爬虫决策、9 月 2 日的 AI 搜索技术信号审计）是同一件事的三面。技术问题里，“顺序”常常比“努力”重要——先确认门开着，再讨论屋里摆得好不好看。

再补一步：三种状态要分开记

做检索测试时，结果只有三种，而且它们的含义完全不同：

状态	含义	后续动作
缺席	引擎既没提你，也没引用你	回到上面的排查清单，先解决可检索性
被提到（无链接）	模型在正文里说了你的品牌，但没有给出链接	大概率来自训练数据记忆，不是这次检索的结果
被引用（有链接）	回答挂了你页面/站点的链接	说明这次检索生效了，接下来才是 GEO 的活

混在一起记，就会得出“我们排名还行”这种没用的结论。“被提到”和“被引用”是两件事，这个我们在 8 月 30 日那篇里详细写过。

一步交叉验证：用 curl 和 GSC 把结论钉死

聊天机器人的输出是“一次观察”，不是“一个事实”。所以我建议每次都用另外两个更硬的口径交叉验证同一批页面：

1. curl（不带 JS）抓一遍：curl -A "Mozilla/5.0" -s https://你的域名/关键页 | grep "你那段关键文案的关键词"。 能 grep 到 → 说明正文在服务端返回的 HTML 里，AI 检索爬虫（基本不执行 JS）能拿到。 grep 不到 → 说明正文依赖 JS 渲染，问题在渲染层，不在内容层。
2. GSC 网址检查：看 Google 渲染后的 HTML 与用户看到的是否一致（这也能顺带发现上一篇文章里那种“报错壳页”问题）。 如果你已经有 Search Console 的生成式 AI 报告，也可以一起看，但要记住它只覆盖 AI Overviews 和 AI Mode，不包含 ChatGPT、Perplexity 等平台。

工具：要不要装那个 Chrome 扩展

Green 为了省事写了个 Chrome 扩展（Exactly Matchy）：读取当前页面渲染后的正文，自动过滤导航、cookie 提示、页脚这类样板内容，然后用 Chrome 自带的端侧模型挑出 20–30 词、含具体名称/数字/不常见表述的“独特片段”，一键发起精确匹配提示。

几个细节值得知道：端侧模型只用来排序和挑选候选片段，不改写内容，所以页面文字不会上传到第三方 API，也没有 API key 和费用；Chrome AI 不可用时会退化成简单的打分逻辑。作者也提醒了风险：目前只能通过 fork 仓库、在 chrome://extensions 里开启开发者模式“加载已解压的扩展”，装不装自己负责。

Neo的解读：这个扩展解决的是“挑片段”的体力活。我想说的是——不装也能干。 你自己挑几段包含具体数字或专有名词的段落（比如“我们测试的 137 个页面里…“这种句子），放进一个表格手动跑，成本不会超过 30 分钟。扩展能帮你的是”每次测试都省这一步“，属于第二个月的优化。

一份 30 分钟的自检表

按这个顺序做，一次做完，之后每月复测：

1. 挑 5 个页面：3 个核心产品/服务页 + 1 个博客长文 + 1 个你怀疑有问题的页面（不要全站都是“首页”）。
2. 每个页面人工挑 2 段独特原话（20–30 词，含具体数字/名称/独特说法）。
3. curl 一遍：确认正文在原始 HTML 里（不带 JS 也能拿到）。
4. 查 robots.txt：对着上面的爬虫清单，逐行确认哪些是“故意没有挡”的。
5. 跑精确匹配检索：3 个引擎（ChatGPT / Gemini / Perplexity）× 每页 2 段 × 每段 3 次采样，记录“缺席 / 提到 / 引用”。
6. 记录表：日期、引擎、页面、片段编号、结果、备注（例如“换片段后返回”）。这张表的价值在第三次复测之后才出现——你开始能看到“波动”和“真变化”的区别。

最后

这套方法的价值不在于它能证明什么，而在于它把“AI 看不见我们”这个模糊的抱怨，变成了一个可以定位的层级问题：是没被发现、抓不到、渲染不出来、还是索引不了。

而对独立站来说，最需要记住的优先级是：

可检索 > 可引用 > 有流量。

绝大多数团队是从最后一头开始优化的——先研究怎么写得更“AI 友好”，而前面那扇门可能一直是关着的。先花 30 分钟确认门是开的，再谈内容。

如果你今天只做一件事：挑一个核心页，取一段原话，加引号丢给 ChatGPT，看它会不会把你自己还回来。