📍 WDQWDWQD987AAAAA:216.73.216.190
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /107f9b91b1ae.html
📄

robots txt协议，小流量灰度为何没暴露全量发布的例外

因为灰度通常只覆盖“标准路径”，而全量发布把例外路径也放了出来：同一份robots.txt在灰度环境里可能只对少数目录、少数UA或少数入口生效，全量时却会碰到子域、参数URL、大小写变体、重定向链和多套爬虫身份。你看到的现象不是灰度没用，而是灰度样本没有命中那个例外条件。

先分清两种解释：是规则本身漏了，还是灰度样本没命中

当全量发布后抓取量突然变化，常见有两种解释。第一种是robots.txt规则本身在正式环境写错了，比如Disallow路径少了斜杠、通配符放错位置，或者Allow与Disallow顺序导致预期外的匹配。第二种是规则没错，但灰度只验证了主站主目录，没有覆盖全量才会出现的例外：带参数的列表页、移动子域、旧域名跳转后的路径、CDN回源路径，或者不同爬虫UA读取到的分组不同。

这两种解释的后续动作完全不同。若是规则写错，修一行就可能恢复；若是样本没命中，改规则反而可能误伤本来正常的目录。所以先不要急着改robots.txt，先找能区分两者的证据。

用“路径命中记录”区分两种解释

最直接的证据是比较灰度期和全量期实际被抓取的URL清单，而不是只看抓取总量。把日志按目录、参数、UA、响应码分组，观察全量后新增的抓取集中在哪一类路径。如果新增抓取全部落在灰度从未出现过的路径模式上，且这些路径在robots.txt里的匹配结果与主路径不同，就更偏向“样本没命中”。如果同一批路径在灰度期已被禁止、全量后却仍被大量抓取，且robots.txt内容没有变化，则要检查是否是其他爬虫不遵守该分组，或规则写法本身不生效。

一个可操作的检查是：从日志里抽20条全量后新增抓取的URL，逐条去 robots.txt 里做字符串匹配推演，记录每条是被Allow还是Disallow命中。若20条里有明显比例落在灰度未覆盖的路径模式上，说明灰度范围需要先扩大，而不是先改规则。

灰度要覆盖例外，而不是覆盖流量比例

很多团队把灰度理解成“放1%流量”，但robots.txt的验证对象不是用户流量，而是URL模式和爬虫身份。假设一个站点有主域、移动子域、带参数筛选页和旧路径重定向四类入口，灰度只放了主域首页和栏目页，那么它验证的只是“标准路径可读”。全量后移动子域和参数页同时暴露，例外才会出现。

更稳妥的灰度单位是“路径族 + UA分组”。先列出全量发布后会新增暴露的URL模式，再按模式各抽少量URL做验证。这样即使只验证几十个URL，也能覆盖例外条件。动作上可以先冻结robots.txt修改，只做一次路径族盘点，把盘点结果作为下一轮灰度的输入；如果盘点发现新增暴露的模式在灰度期完全没出现，下一步应是补验证，而不是直接上线新规则。

注意几个容易被灰度掩盖的例外

• 大小写与结尾斜杠：/Private/与/private在部分实现里可能被当作不同路径，灰度若只测一种写法，全量后另一种写法就会漏过。
• 分组与UA：针对特定爬虫写的User-agent分组，灰度时若没有用对应UA请求，就不会暴露该分组是否被正确解析。
• 重定向链：灰度直接访问最终URL，全量时爬虫先碰到301/302，再落到新路径，原规则可能匹配不到重定向后的地址。
• 站点地图与robots.txt的配合：robots.txt限制抓取不等于可靠地移除索引，站点地图也不保证收录。灰度若只看站点地图提交结果，可能误判robots.txt已经生效。

把结论落到下一次发布

如果证据指向“样本没命中”，下一次灰度就按路径族和UA分组重新抽样，并把全量新增暴露的URL模式写成检查项；如果证据指向“规则写错”，再回到robots.txt本身修正匹配表达式。无论哪种，都不要把抓取量归零单独当作处理正确的证明，因为抓取量下降还可能来自发布节奏、缓存、日志采样或爬虫自身调度变化。先确认是哪一类URL在变化，再决定改规则还是改灰度范围，这样全量发布时例外才会提前暴露。