死链接修复方法：小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /da30de2c8cfb.html
📄
死链接修复方法：小流量灰度如何暴露全量发布的例外
灰度只覆盖一部分URL时，全量发布后仍可能出现死链接，原因通常不是修复规则本身错了，而是灰度样本没有覆盖到全量环境里的例外路径。要决定是扩大灰度还是先全量发布，关键看例外是否集中在可枚举的路径类型上，以及回退代价是否低于继续放量的风险。
先看灰度样本漏掉了哪类URL
假设一个内容站把旧栏目 /old-a/ 迁到 /new-a/，灰度只抽取了带数字ID的文章页做301，全量发布后才发现列表页、分页参数和标签聚合页仍指向旧路径。这类例外的共同点是：它们不是内容实体，而是由模板和参数动态生成的入口。
判断方法很直接：把灰度期间实际命中的URL按路径模式分组，再和全量站点地图、内链入口做一次模式比对。如果灰度里只出现 /old-a/123.html，而全量还存在 /old-a/list-2.html、/old-a/?tag=x，那么灰度结论不能直接外推到全量。此时扩大灰度比直接全量发布更稳，因为新增样本能验证模板层是否也走了新规则。
两种修复顺序的取舍条件
发现例外后，常见选择是“先回退全量，再补规则”或“保留全量，用边缘重定向兜住例外”。两者成立条件不同。
- 先回退适合例外路径数量少、但影响核心入口的情况，例如首页导航和栏目列表仍指向旧地址。回退的动作是恢复旧路径可访问或恢复旧模板，代价是已切换的页面要再切一次，可能带来短暂的状态反复。
- 保留全量并补规则适合例外可枚举、且旧路径仍能返回明确目标的情况。动作是把例外模式加入重定向表，再抽样验证。代价是规则表变长，后续维护要防止模式之间互相覆盖。
如果例外无法枚举，比如旧站存在大量由用户生成或历史遗留的拼接参数，回退通常比继续堆规则更可控。反过来，如果例外只是三五个固定模板，补规则的成本明显更低。
用一组可区分原因的证据定位例外
全量发布后看到旧路径返回404，并不等于修复规则失效。需要区分几种原因：
- 服务器配置只在新节点生效，旧节点仍在提供旧规则；
- 重定向规则顺序错误，宽泛规则先命中，把本应保留的路径也送走；
- 页面本身可访问，但站内链接仍写死旧地址，形成内链型死链接；
- 旧路径在robots.txt中被限制抓取，导致无法通过抓取发现真实状态。
这里要提醒一点：robots.txt的抓取限制不等于可靠的索引移除，它只约束抓取行为，不能替代404或301处理；站点地图也不保证收录，提交了新模式不等于旧模式会被尽快替换。把抓取日志、服务器返回码和页面内链分别抽样，才能判断例外属于哪一类。若返回码正常而内链仍旧，问题在模板；若返回码异常而内链已新，问题在重定向层。
一个假设例子：先补规则还是先回退
假设某站灰度覆盖了200个文章页，全量发布后发现旧标签页 /old-a/tag/ 下约30个入口返回404。此时先做一次小范围验证：把其中5个标签页加入重定向规则，观察返回码和内链是否同时转为新地址。如果5个都正常，说明例外模式可枚举，可以继续补完剩余规则；如果其中仍有页面返回旧地址，说明模板或缓存层还有未覆盖的分支，应优先回退全量，避免例外继续扩散。
这个动作的结果会直接决定下一步：验证通过就扩大规则覆盖并再次抽样；验证不通过就停止放量，回到灰度状态排查模板和缓存。整个过程不需要承诺收录或排名变化，只需要确认旧路径不再产生新的死链接入口。
全量发布前应保留的检查点
为了避免灰度结论被误用，发布前至少保留三个检查点：灰度命中的路径模式清单、全量环境里同类模式的清单、以及两者差异的抽样结果。差异部分就是全量发布的例外来源。发布后再用同一组抽样复查返回码和内链，确认例外是被规则覆盖，还是被回退消除。
如果差异集中在少数固定模板，补规则通常足够；如果差异分散在参数、分页和用户生成入口上，回退并重新设计灰度覆盖范围更稳妥。选择哪一种，取决于例外是否可枚举，以及回退造成的状态反复是否在可接受范围内。
