robots.txt：小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cc4573076e90.html
📄
robots.txt：小流量灰度如何暴露全量发布的例外
灰度只放行一小部分抓取请求，不能证明全量发布后 robots.txt 对所有路径都成立。它真正暴露的是：规则在少量样本下看似一致，但一旦流量放大，那些被灰度样本绕开的例外路径、例外爬虫和例外协议会同时出现。灰度能发现例外，却不能替你判断例外是否已经消失。
假设情境：只放行一个目录的灰度
假设某站点准备把一批历史页面从“允许抓取”改为“禁止抓取”，robots.txt 里新增一条 Disallow: /old/。为避免误伤，先做小流量灰度：只让一小部分抓取请求经过新规则，其余仍走旧规则。灰度期间观察到的抓取量下降，看起来符合预期。但全量发布后，日志里出现了三类灰度未覆盖的情况：/old/ 下的子路径被其他规则重新允许；带参数的旧链接没有被 /old/ 前缀匹配；某个爬虫对 Allow 与 Disallow 的优先级处理与预想不同。灰度样本没有包含这些组合，所以它只证明了“样本内一致”，没有证明“规则整体一致”。
灰度能暴露什么，不能证明什么
灰度最有价值的产出不是“抓取量降了”，而是差异清单。把灰度期间实际命中的 URL、User-agent 和响应结果记录下来，再与全量规则逐条比对，才能看出哪些例外只在低流量下被掩盖。以下判断需要分开：
- 能暴露：规则冲突、路径前缀匹配错误、特定 User-agent 被遗漏、协议或端口差异导致的规则未生效。
- 不能证明：全量发布后所有爬虫都会遵守同一规则；被 Disallow 的 URL 会从索引中移除；站点地图里的 URL 会因此被重新收录。
- 不能从抓取量归零直接推出：抓取量下降也可能来自发布窗口、缓存、日志采样或爬虫自身调度变化，不能单独当作规则正确的证据。
robots.txt 的抓取限制不等于可靠的索引移除。即使某个 URL 被禁止抓取，它仍可能因为外部链接或历史索引而出现在结果里。灰度阶段如果只盯着抓取请求数，就会把“抓不到”误当成“已处理”。
缺少完整权限时，最小动作是什么
如果没有全量日志、没有搜索平台后台权限，仍可执行一个最小动作：在灰度规则生效前后，各取一段相同长度的时间窗，只对比 robots.txt 本身被请求的次数、返回状态和内容哈希，同时记录灰度放行的 User-agent 列表。这个动作不需要完整日志，只需要能拿到 robots.txt 的访问记录或边缘节点日志。
动作的结果会直接决定下一步：如果 robots.txt 的内容哈希在灰度前后一致，但放行列表外的爬虫仍按旧规则抓取，说明问题在规则分发或缓存，而不是规则文本；如果哈希发生变化，则要先确认变化是否来自发布流程本身。这个判断不能反过来用“抓取量下降”来替代，因为抓取量下降有多种合理解释。
全量发布前，把例外变成可核对的清单
灰度结束后，不要直接扩大流量，而是把灰度中未覆盖的组合补进核对清单。清单至少包含：规则顺序、User-agent 分组、路径前缀与通配符、协议与端口、站点地图中仍保留的 URL。对每一项，写明“灰度是否覆盖”和“全量后如何确认”。
- 先确认 robots.txt 是否对所有目标 User-agent 返回同一份内容，还是按 UA 分支返回不同内容。
- 再确认
Allow与Disallow同时命中时，实际生效的是哪一条；不同搜索引擎的支持情况须分别核查。 - 最后确认站点地图是否仍包含被禁止抓取的 URL。站点地图不保证收录，但保留这些 URL 会让“禁止抓取”和“希望收录”两个信号互相矛盾。
如果灰度只覆盖了默认爬虫，而全量发布后出现了移动端爬虫或第三方抓取工具，那么灰度结论不适用。此时应把灰度范围明确标注为“仅覆盖已列出的 User-agent”，而不是写成“规则已验证”。
灰度结论的适用边界
小流量灰度的价值在于用较低成本发现规则冲突和路径例外，但它天然无法覆盖长尾 URL、低频爬虫和发布瞬间的缓存不一致。它适合回答“这条规则在样本内是否按预期生效”，不适合回答“全量发布后索引和抓取会怎样变化”。把这两类问题分开，才不会把一次灰度通过当成全量发布的通行证。灰度暴露的例外，需要在全量发布前逐条确认处理方式，而不是等流量放大后再回滚。
