网站死链检测：批量页面只有一部分被发现时怎样划分对照组
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2c65f39a0868.html
📄
网站死链检测：批量页面只有一部分被发现时怎样划分对照组
先给结论：当批量页面里只有一部分被死链检测发现，对照组不应按“页面是否报错”来分，而应按“发现路径是否独立”来分。更具体地说，把已发现页面按入口来源分成两组——一组只依赖站点地图或站内链接，另一组同时依赖外部链接、历史访问或日志中真实抓取记录；如果两组在死链命中率上出现明显差异，问题更可能出在发现链路，而不是页面本身。这个划分成立的前提是：两类页面在模板、状态码逻辑和内容类型上基本一致。若已发现页面恰好集中在某个目录、某种参数或某个发布时间段，那么按发现路径分组就会被结构差异污染，结论失效。
为什么按“是否报错”分组会误导
常规做法是把页面分成“检测到死链”和“未检测到死链”两组，再比较差异。这个分法在批量场景下有一个致命问题：未检测到死链的页面里，混着两种完全不同的情况——页面本身正常，以及页面根本没被检测工具访问到。把这两类混在一起，任何对比都失去意义。
更可用的分法是先固定“页面应被访问到”的证据，再谈死链。证据可以来自服务器访问日志中的抓取记录、站点地图提交后的抓取痕迹，或站内链接图里指向该页面的入链。只有确认页面确实被请求过，才能把“没有报死链”解释为页面正常。
按发现路径划分对照组的具体做法
假设你有一批 200 个页面需要检测，其中只有 60 个被工具标记为死链。可以这样分：
- A 组：页面只通过站点地图或站内导航被发现，没有外部链接，也没有日志中的独立抓取记录。
- B 组：页面同时有外部链接、历史访问记录或日志中可确认的抓取请求。
然后分别统计两组的死链命中比例。如果 A 组命中率远高于 B 组，说明发现路径单一的页面更容易被漏检或误判；如果两组比例接近，问题更可能在页面响应本身，而不是发现方式。
这个划分的关键动作是：先从日志或链接图中提取每个页面的“被发现证据”，再按证据类型分组，而不是先看检测结果。做完这一步，你才能决定下一步是补发现路径，还是逐个检查页面响应。
一个会让分组失效的反例
如果 A 组页面恰好全部是同一批旧模板生成的，而 B 组全部是新模板，那么两组的死链差异可能来自模板差异，而不是发现路径。这时按发现路径分组就没有解释力。
判断方法很简单：在分组后，检查每组内部的模板、目录、参数类型和发布时间是否集中。如果某一组明显偏向某一种结构，就需要先按结构再分一层，或者把结构差异作为独立变量排除。否则你看到的“发现路径影响”只是结构差异的伪装。
发现量归零时不要急着下结论
有时你会看到某个来源的抓取量突然归零，于是认为该来源的页面全部有问题。但抓取量归零还有别的合理解释：抓取频率调整、站点地图更新延迟、服务器临时限流，或者该来源本身就不再被引用。单独一个归零信号不能证明死链检测处理正确，也不能证明页面已被移除。
同样，robots.txt 里的抓取限制不等于可靠的索引移除，站点地图提交也不保证收录。这些信号只能作为发现路径的参考，不能替代对页面实际响应的检查。
下一步动作：先补证据，再决定修哪里
完成分组后，优先做一件事：对 A 组中未被标记为死链的页面，手动构造一次独立请求，确认它们是否真的可访问。如果手动请求返回正常，说明检测工具的发现范围有限，下一步应扩大发现路径，比如补充站内链接或检查站点地图覆盖；如果手动请求也失败，说明问题在页面本身，下一步应转向响应状态和内容检查。
这个动作的结果直接决定后续方向：发现路径问题就修发现，页面问题就修页面，两者不要混在一起处理。
