死链检测，批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /589909379c35.html
📄
死链检测，批量页面只有一部分被发现时怎样划分对照组
先给结论：当站点地图、站内链接或抓取日志只暴露了批量页面中的一部分时，不要把这部分直接当成“有问题的页面”，而要把它当作一个待验证的样本，再从未被发现的部分里按同构条件抽出对照页。对照组的作用是回答“差异来自死链本身，还是来自页面类型、入口位置或模板结构”，而不是证明谁对谁错。下面用你手上的一份页面清单来演示怎么落地。
先确认“只有一部分被发现”是哪一种遗漏
同样表现为“只发现一部分”，原因不同，对照组的设计也不同。先做一次区分：
- 入口遗漏：这些页面没有任何站内链接指向，只能靠站点地图或外部链接进入。此时对照组应优先选“有站内入口、其余条件相同”的页面。
- 模板遗漏：同一批页面由同一模板生成，但只有部分被列出。对照组应选同模板、同层级、同发布时间的页面。
- 抓取遗漏：页面本身可访问，但抓取预算被消耗在别处。对照组应选抓取频率相近的页面，而不是结构最相似的页面。
判断依据可以先看一个动作：把待测页面按“是否有站内链接”“是否在站点地图中”“是否与已知死链同模板”三个字段各标一次。如果三个字段的分布高度一致，说明遗漏更可能是入口问题；如果分布分散，则更可能是模板或抓取问题。这一步的产出会直接决定下一步抽哪一组对照，而不是先修再猜。
把页面清单转成可比较的分组表
假设你手上有一份 400 条的 URL 清单，其中 60 条被标记为“疑似死链并已被发现”，其余 340 条未被发现。不要直接比较这 60 条和 340 条，因为两组在页面类型上大概率不可比。可行做法是给每条 URL 补三个字段：页面模板、距首页点击深度、最近一次站内链接出现位置。然后按模板分组，在每组内部各取“被发现”和“未被发现”的页面。
一个注明假设的短例子：假设这 400 条里有 200 条属于商品详情模板、150 条属于分类模板、50 条属于帮助中心模板。如果 60 条被发现页面中 55 条来自商品详情模板，那么直接拿全部 340 条做对照就会把模板差异误读成死链差异。正确做法是只在商品详情模板内部比较，再单独看分类和帮助中心模板是否出现同类现象。这个动作的结果是：你得到的是“同模板内的差异”，而不是“跨模板的平均值”，下一步的修复范围也随之收窄。
对照组要回答的两个具体问题
对照组不是越多越好，它只需要回答两个问题：
- 被发现页面和未被发现页面，在响应状态上是否真的不同？ 如果两组返回的状态码分布接近，那么“被发现”更可能来自入口或抓取路径，而不是死链本身。
- 差异是否稳定出现在同一模板或同一目录下？ 如果只在某个目录出现，优先检查该目录的链接生成规则；如果跨目录出现，优先检查全站导航或站点地图生成逻辑。
这里要说明一个容易混淆的点：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。因此，当你看到某批页面“未被发现”时，不能仅凭站点地图里没有它们就断定它们被排除；同样，也不能仅凭站点地图里有它们就断定它们会被处理。对照组的意义在于把“是否出现在站点地图”与“是否可被抓取”分开观察。
用一次小规模对照决定修复顺序
具体动作可以这样安排：从同一模板中选 10 条被发现页面和 10 条未被发现页面，分别记录三项：返回状态码、是否有站内链接指向、是否在站点地图中。记录完成后，先看两组在哪一项上出现最大差异。
- 如果差异集中在“是否有站内链接”，下一步优先修入口，而不是改页面内容。
- 如果差异集中在“返回状态码”，下一步优先确认这些 URL 是否真的指向已删除资源，再决定是恢复还是重定向。
- 如果三项都没有明显差异，说明当前样本不足以区分原因，应扩大同模板样本量，而不是直接全站处理。
这个动作的结果会改变你下一步的优先级：入口问题影响的是发现路径，状态码问题影响的是访问结果，两者的修复成本和验证方式不同。把对照结果写进同一张表，后续复查时才能判断修复是否真的改变了分布，而不是只看总量有没有变化。
什么时候对照组方法不适用
如果批量页面总量很小，比如不足 30 条，分组后每组可能只剩个位数，对照结论会非常不稳定。此时更实际的做法是逐条检查，而不是强行分组。另一种情况是页面之间差异极大，比如同时包含静态页、带参数的动态页和需要登录才能访问的页面，这时应先按可访问性拆成不同批次，再在批次内部做对照。跨搜索引擎的支持情况需要分别核查，不要用一组对照结果直接推断所有环境。
把上面的步骤连起来：先判断遗漏类型，再补字段分组，然后在同模板内取对照，最后用一次小规模记录决定先修入口还是先修状态。每一步的产出都应能直接指向下一步的动作，而不是停留在“已检测”这个状态。
