robots.txt优化用一次小流量灰度暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /10a9a0c4d860.html
📄
robots.txt优化用一次小流量灰度暴露全量发布的例外
结论先说：灰度只放行少数爬虫或少数目录，能提前暴露“规则在真实抓取路径上不生效”的例外，但它不能证明全量发布安全。原因是灰度样本会天然偏向你选中的那部分路径，而例外往往藏在未纳入灰度的目录、参数组合或爬虫身份里；一旦全量发布，这些例外会同时暴露，且未必伴随可观察的抓取量变化。
灰度要放行什么，才能让例外有机会出现
常见的错误是把灰度做成“只让一个测试爬虫访问全站”。这样得到的结论是“这条规则对这条爬虫有效”，而不是“规则对所有目标路径有效”。要暴露例外，灰度应同时改变两个变量：路径范围和爬虫身份。例如假设站点有 /product/ 与 /product/compare/ 两类目录，你想用 Disallow 限制后者，灰度阶段只对一部分爬虫放行 /product/，同时保留 /product/compare/ 的抓取日志。
判断依据不是“灰度期间没报错”，而是三个可核对的现象：灰度路径的抓取请求是否出现、被限制路径是否确实不再被抓、以及服务器返回的状态码是否仍是 200 而不是被规则改写成 403 或 404。只有第三条成立，才能说明限制发生在抓取层而不是索引层。
为什么灰度通过，全量发布仍会出现例外
最容易被忽略的反例是：灰度期间被放行的爬虫恰好不抓取你真正想限制的那类 URL。比如你限制的是带 ?sort= 参数的排序页，而灰度放行的爬虫只抓了无参数版本，于是灰度日志“干净”，全量后带参数版本仍被抓取。这不是规则写错，而是灰度样本没覆盖目标 URL 形态。
另一个反例来自 robots.txt 本身的语义：它限制的是抓取，不是移除。即使全量发布后某条规则对目标爬虫生效，已经进入索引的 URL 也不会因为新规则自动消失。灰度期间若只观察“新抓取是否减少”，就无法区分“规则生效”与“抓取需求本来就在下降”。抓取量归零可能由规则、站点改版、服务器超时或爬虫调度变化共同造成，不能单独作为规则正确的证据。
用一组可区分原因的证据代替直觉判断
- 看请求身份：按 User-Agent 分组统计目标路径的请求数。若只有灰度爬虫的请求下降，其他爬虫不变，说明规则可能只对部分身份生效，需要分别核查各搜索引擎对通配符和目录规则的支持差异。
- 看路径形态：把 URL 按目录、参数、扩展名拆开。若限制
/product/compare/后，/product/compare/index.html仍被抓，说明规则没覆盖默认文档路径。 - 看状态码而非数量：请求数下降但状态码仍为 200，可能是抓取预算转移；请求数不变但状态码变为 403，说明限制在服务器层发生，与 robots.txt 无关。
- 看站点地图与索引：站点地图不保证收录，robots.txt 也不保证移除。灰度后若站点地图仍包含被限制 URL，索引状态不会因规则更新而立刻改变。
这些证据的作用是排除解释，而不是证明因果。若多组证据同时指向同一路径形态，才值得把它作为全量发布前必须修补的例外。
下一步动作：把例外变成发布前的检查项
灰度结束后，不要直接全量发布。先做一次“反向抽样”：从你打算限制的 URL 集合里，随机抽取若干条，逐条确认它们在灰度期间是否真的没有被目标爬虫请求。对仍被请求的 URL，记录其完整形态，并检查规则是否因大小写、结尾斜杠、通配符位置或目录前缀匹配而漏掉。
把这个动作的结果写进发布清单：漏掉的 URL 形态补进规则，无法用 robots.txt 覆盖的（例如已被索引的页面）改用其他移除手段，并明确这些手段的生效条件。只有灰度期间被限制路径的请求身份、路径形态和状态码三项都对得上，全量发布才具备可核对的依据。否则，灰度通过只是说明你选中的样本没问题，而不是规则本身没问题。
