搜索引擎抓取规则：旧内容下线前，小流量灰度怎样暴露全量发布的例外

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

搜索引擎抓取规则：旧内容下线前，小流量灰度怎样暴露全量发布的例外

有条件的结论是：如果灰度只覆盖“新入口不再链接旧内容”这一层，而全量发布还包含站点地图、robots.txt、旧链接跳转和外部合作页四类动作，那么灰度通过并不能证明全量安全。灰度真正的作用不是验证规则本身，而是提前暴露那些只在“全量同时生效”时才出现的例外。反例是：当旧内容本身仍被外部页面直接引用，且这些引用不经过你控制的入口时，灰度流量再干净，全量发布后旧 URL 依然可能被持续请求。

灰度验证的不是抓取规则，而是发布动作的边界

很多团队把灰度理解成“先放一部分流量试试抓取是否正常”，但抓取规则的生效方式与页面渲染不同。它依赖爬虫按自己的节奏重新访问，而不是按你的发布比例分配。因此灰度阶段观察到的请求量下降，可能只说明新入口没再指向旧内容，并不说明旧 URL 已经退出。

要区分这一点，可以在灰度里做一次对照：只改入口链接，不动站点地图和 robots.txt，观察旧 URL 的请求来源。如果请求仍来自站点地图或外部引用，说明全量发布时单纯删链接不够；如果请求明显集中在你控制的新入口，才说明入口层是主要来源。这个动作的结果直接决定下一步是继续扩大入口层灰度，还是先处理站点地图和外部引用。

哪类例外只在全量时出现

灰度通常只覆盖一个变量，而全量发布往往同时改多个变量。以下例外在灰度中容易被掩盖：

这些例外的共同点是：它们不随灰度比例缩放，而随“发布动作是否同时生效”出现。因此判断灰度是否有效，要看它是否覆盖了全部发布动作，而不是看流量大小。

用一组可区分原因的证据定位例外

当全量后旧 URL 请求没有按预期下降时，不要急于回滚。先按来源分组，看请求的 Referer 或访问路径属于哪一类：

  1. 来自站点地图：检查地图是否仍列旧 URL，以及 lastmod 是否被误更新。
  2. 来自站内其他页面：检查内链、导航、分页和推荐模块是否还有残留入口。
  3. 来自外部域名：检查合作页、转载页和社交平台的历史引用。
  4. 无 Referer 的直接请求：可能是历史书签、缓存或爬虫重访，需要结合访问频率判断，不能仅凭一次请求归因。

这里要提醒一种常见误判：请求量归零不能单独证明处理正确。它也可能只是爬虫暂时降低了访问频率，或你的日志采样窗口太短。反过来，请求量没有归零也不代表处理失败，可能只是外部引用尚未更新。把请求来源和发布动作对齐，才能区分这两种解释。

一个注明假设的短例子

假设某站要把一批旧活动页下线，保留其中仍被引用的三个页面。灰度方案是：新导航不再链接旧活动页，观察一周。灰度期间旧 URL 请求下降，团队认为可以全量。全量时同时做了三件事：从站点地图删除全部旧活动页、给旧目录加 robots.txt 限制、把旧 URL 跳转到新活动首页。

发布后一周，旧 URL 请求没有继续下降，反而出现新的请求路径。排查发现：被保留的三个页面中，有两个被外部合作页直接引用，而 robots.txt 限制让爬虫无法重新抓取这些页面确认跳转，导致旧 URL 在结果中的状态更新变慢。这个例子的假设是：外部引用确实存在，且 robots.txt 限制覆盖了需要保留的页面。它说明灰度只验证了入口层，没有验证“保留部分”与“退出部分”在同一次发布中的冲突。

下一步动作：把灰度拆成可独立回滚的两层

如果灰度只覆盖入口层，全量发布时应把动作拆成两层：第一层是入口和站点地图的同步调整，第二层是跳转和抓取限制。两层之间留出观察窗口，先确认第一层生效，再决定第二层是否需要以及覆盖哪些路径。

具体动作是：在灰度中单独关闭站点地图对旧 URL 的列出，观察请求来源是否变化。如果请求明显减少，说明站点地图是主要来源，全量时可以优先处理；如果没有变化，说明外部引用或历史缓存占主导，此时应保留旧 URL 的可抓取状态，用跳转或内容替换来处理，而不是用 robots.txt 一刀切。这个动作的结果会直接改变你对“退出”手段的选择，也决定保留页面是否需要单独排除在限制之外。

图1 图2
nginx