robots.txt规则小流量灰度暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e1d6423fd8a2.html
📄
robots.txt规则小流量灰度暴露全量发布的例外
小流量灰度之所以会暴露全量发布的例外，是因为灰度只覆盖了部分抓取路径，而全量发布面对的是所有爬虫、所有路径和所有时间窗口的叠加。灰度里“看起来生效”的 robots.txt 规则，很可能只是恰好没有被例外路径触发。要判断问题，先区分两种解释：规则本身没有表达完整意图，还是规则表达完整但执行环境存在差异。前者要靠规则核对，后者要靠请求日志和响应状态区分。
灰度通过不等于全量安全：两种解释先分开
第一种解释是规则语义缺口。灰度期间只验证了少数抓取入口，例如首页和几个栏目页，但全量发布后爬虫会顺着历史外链、站内搜索参数、分页和旧路径继续抓取。如果 robots.txt 里只写了 Disallow: /search，而实际参数形态是 /search?q= 或 /s?keyword=，灰度时没有请求到这些形态，就不会暴露问题。
第二种解释是执行环境差异。规则文本相同，但灰度节点与全量节点的解析顺序、大小写处理、缓存版本或部署目录不同。例如灰度环境读取的是测试域名下的 robots.txt，全量环境读取的是正式域名下的文件；或者灰度期间 CDN 缓存了旧版本，全量发布后缓存刷新，规则才真正生效。此时问题不在规则文本，而在“谁在什么时间读到了哪一份文件”。
用请求日志和响应状态区分解释
先取灰度期间和全量发布后同一路径的抓取记录，按三列核对：请求 URL、返回状态、是否被允许抓取。若灰度期间该 URL 从未出现，而全量后大量出现且返回 200，说明是覆盖范围不足，不是规则失效。若灰度期间同一 URL 返回 200，全量后返回 403 或 404，则要检查规则是否被正确部署，以及服务器是否在 robots.txt 之外做了额外拦截。
一个可用的区分动作是：把灰度期间和全量后的 robots.txt 响应体做逐字节比较，同时记录 HTTP 状态码和 Last-Modified。如果响应体不同，优先查部署和缓存；如果响应体相同但抓取行为不同，优先查爬虫身份和路径覆盖。这个动作的结果会直接决定下一步：文本不同就修发布流程，文本相同就修规则表达。
把分歧转成可核对的项目
多个角色对同一事实有不同理解时，不要争论“规则有没有生效”，而是把分歧拆成可核对项。可以建立一个最小核对表：
- 灰度覆盖了哪些 URL 形态，全量又新增了哪些形态；
- robots.txt 的获取时间、响应状态和内容哈希；
- 被限制路径的实际请求记录，以及返回状态；
- 规则中使用的通配符和结尾匹配是否符合目标爬虫的语法支持。
每一项都要求给出可复现的证据，而不是口头结论。例如“全量后收录下降”不能直接归因于 robots.txt，因为抓取限制不等于索引移除，站点地图也不保证收录。请求量归零同样不能单独证明处理正确，它也可能是爬虫调度、服务器拦截或路径本身没有外链导致。
一个假设例子：灰度只测了首页
假设某站灰度期间只让爬虫抓取首页和三个栏目页，robots.txt 写了 Disallow: /tmp/。全量发布后，历史遗留的 /tmp/export?type=all 被外部链接重新触发，爬虫开始大量请求。此时如果只看灰度报告，会认为规则正常；但全量日志显示该路径持续返回 200。核对后若发现规则文本没有覆盖带参数的 /tmp/ 路径，就需要补充更精确的匹配；若规则文本已经覆盖但服务器仍返回 200，则要检查是否有反向代理或应用层绕过了 robots.txt 的判断。
这个例子的重点不是某个具体数字，而是说明：灰度通过只能证明被覆盖的路径没有触发例外，不能证明全量路径都安全。下一步动作取决于核对结果——规则文本缺口就改规则，执行环境差异就改部署和缓存策略，两者都不成立时再考虑抓取限制之外的索引和展示问题。
