robots.txt写法：灰度只封一小段，为何全量发布仍被抓

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

robots.txt写法：灰度只封一小段，为何全量发布仍被抓

灰度发布时只对一小段路径加了 Disallow，线上抓取量看起来正常；等到全量发布、把同一段规则扩展到全站目录，抓取量却突然上升，甚至出现大量你本想退出的旧 URL。这不是规则没生效，而是灰度阶段暴露的样本太小，掩盖了规则与真实 URL 结构之间的例外。要判断是"规则写错"还是"灰度没覆盖到"，需要先分清两种解释，再用能区分它们的证据去验证。

两种解释：规则错位，还是灰度漏掉了例外

第一种解释是规则本身没匹配到真实路径。robots.txt 的 Disallow 是前缀匹配，Disallow: /old-section/ 只挡住以该字符串开头的 URL。如果旧内容实际分布在 /old-section-v2/、/archive/old-section/ 或带参数的形式 /old-section/?page=2，灰度时你只挑了几条看起来符合前缀的样本，自然"验证通过"，全量后其余变体就漏了出来。这不是灰度失败，是灰度样本选错了。

第二种解释是灰度确实覆盖了，但全量发布改变了站内链接结构。灰度期间旧路径可能仍被导航、站点地图或内链引用，爬虫顺着这些入口进来，抓取量被"规则挡住"和"链接引导"两股力量抵消，看起来平静；全量发布时你同时改了模板或推送了站点地图，链接指向的入口变多，抓取量上升反映的是链接变化，而非规则失效。

能区分两种解释的证据

关键在于：如果规则正确、只是链接变多，那么被请求的 URL 应该仍然落在 Disallow 覆盖的前缀内，只是请求频次上升；如果规则错位，被请求的 URL 会明显落在你写的前缀之外，且这些 URL 在灰度样本里从未出现过。

一个假设例子：前缀扩展时的漏网

假设你要退出一批旧版帮助页，灰度时只对 /help/old/ 加了 Disallow，抽了 5 条该目录下的 URL 验证，全部未被抓取，于是全量时把规则改成 Disallow: /help/。但旧版页面里有一部分实际路径是 /help/legacy/，并不以 /help/old/ 开头，灰度样本里没有它，全量后它照样被抓。这里的动作是：把规则从具体子目录放宽到父目录后，重新按真实 URL 清单抽样，而不是沿用灰度时那 5 条。结果会告诉你，放宽前缀是解决了漏网，还是把仍有价值的 /help/current/ 也一起挡了——后者需要在父目录规则下用 Allow 单独放行。

灰度该覆盖什么，才算对全量有意义

小流量灰度的价值不在于"跑通流程"，而在于样本要能代表全量后的 URL 分布。做 robots.txt 灰度时，至少要让样本覆盖：目标前缀的边界情况（刚好等于前缀、前缀加斜杠、前缀加参数）、同一批内容的不同入口路径、以及规则放宽后会新纳入的路径。只测几条整齐的 URL，等于没测边界。

另外要记住，robots.txt 的抓取限制不等于可靠的索引移除。即使规则写对、爬虫停止抓取，已被收录的旧 URL 仍可能因外部链接而保留在结果中，需要配合页面本身的处理。站点地图也不保证收录，它只是提示，不能当作"已退出"的证据。不同搜索引擎对通配符和 Allow/Disallow 优先级的支持并不一致，规则里用到 * 或 $ 时，要分别核查目标搜索引擎的说明，而不是假设行为统一。

下一步动作与判断顺序

  1. 先取全量后的被抓 URL 样本，标出哪些命中 Disallow 前缀、哪些没有。这一步决定你走"修规则"还是"查链接"。
  2. 未命中的，回到真实 URL 清单，把前缀边界和变体补进规则，再重新抽样验证。
  3. 已命中却仍被请求的，去查内链、站点地图和跳转入口，判断是否需要同时清理链接，而不是只改 robots.txt。
  4. 规则放宽后，确认是否有仍有价值的目录被误挡，必要时用 Allow 精确放行，并再次抽样确认放行路径可被抓取。

把"抓取量上升或下降"单独当作规则对错的证据并不可靠，它可能来自链接变化、发布节奏或缓存，需要结合 URL 是否命中前缀、入口来自哪里一起判断。灰度真正要验的是规则的边界覆盖，而不是流程是否走完。

图1 图2
nginx