死链处理方法：批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /85d42dc60b88.html
📄
死链处理方法：批量页面只有一部分被发现时怎样划分对照组
先给结论：不要按“已发现”和“未发现”直接分组，而要按“处理动作是否已经施加”分组，再在两组内部各自标记发现状态。因为批量页面只被部分发现时，发现与否本身可能由链接位置、目录层级、站点地图提交时间等混杂因素造成，直接对比会把“处理效果”和“页面本身更容易被抓”混在一起。下面用一个假设情境把决策过程走完。
假设情境：一次批量清理只覆盖了部分目录
假设某站点有一批历史页面需要做死链处理，运营先对/old-a/目录下的页面统一替换了失效内链、补上了跳转，而/old-b/目录暂时没动。一段时间后，日志显示两个目录都只有一部分页面被抓取和发现。此时若直接比较“已发现页面”和“未发现页面”的死链数量，得到的差异无法归因于处理动作，因为两个目录的链接深度、被引用次数本来就不同。
正确做法是把“是否已施加处理”作为分组主轴，得到处理组和未处理组；再在每组内部记录发现状态。这样，处理组内部的发现差异、未处理组内部的发现差异，都可以作为背景噪声的参照。
分组前先固定三个变量，否则对照组不成立
- 入口来源：页面是从导航、正文内链、站点地图还是外部链接被发现的。不同来源的抓取节奏不同，混在一起会干扰判断。
- 目录层级：同一批页面若分布在深浅不同的路径，抓取机会本身就不均等。
- 处理动作的时间点：替换内链、加跳转、提交站点地图的时间若不一致，发现窗口就不可比。
这三个变量固定后，对照组才有意义。如果无法固定，退一步的做法是按目录或按模板分层，在每一层内部再分处理组和未处理组，而不是跨层直接比较。
用“处理动作”而非“发现状态”做主轴的具体操作
第一步，列出所有待处理页面的清单，标注每页是否已经执行死链处理动作。第二步，为每页记录当前发现状态，来源可以取自日志或抓取记录。第三步，交叉形成四格：已处理且已发现、已处理未发现、未处理且已发现、未处理未发现。
关键动作是：先比较“已处理且已发现”与“未处理且已发现”两格，看死链相关指标是否随处理动作变化；再用“未处理未发现”这一格估计“如果没被发现，指标会是什么样”。如果处理组的优势只在已发现页面里出现，而在未发现页面里消失，就要怀疑差异来自抓取机会而非处理本身。
这个动作的结果会直接影响下一步：若差异集中在发现状态而非处理动作，应先解决可发现性问题，而不是继续扩大死链处理范围。
发现状态本身可能是结果，不是原因
批量页面只被部分发现时，一个常见误判是把“被发现”当成处理有效的证据。实际上，被发现可能只是站点地图重新提交、外部链接增加或抓取配额临时变化的结果。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，所以发现状态的变化需要结合入口来源一起看。
如果某组页面在提交站点地图后被发现比例上升，但死链指标没有同步改善，说明发现增加并未带来预期处理效果，此时应检查处理动作是否真的作用到了这些页面，而不是继续加提交频率。
什么时候可以缩小对照范围，什么时候必须扩大
当处理组和未处理组在目录层级、入口来源、时间窗口上都接近时，可以缩小到单目录内部对照，结论更干净。当两组在这些变量上明显不同，就必须扩大对照范围，按层分层后再比较，否则任何差异都无法归因。
假设某次处理只覆盖了/old-a/，而/old-b/未覆盖，且两个目录的入口来源不同，此时正确做法是先按入口来源分层，再在每一层内比较处理组和未处理组。若某层内样本太少，就只把它当作观察，不当作结论。
对照组划分的目的不是证明处理有效，而是排除发现状态带来的干扰。划分完成后，下一步应优先处理那些“已处理但未发现”的页面，确认它们是否因为入口缺失而未被抓取，再决定是否扩大死链处理范围。
