网站死链检测，怎样检查前后环节的依赖
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bdf4893f7a57.html
📄
网站死链检测，怎样检查前后环节的依赖
检查网站死链检测前后环节的依赖，核心是沿着“链接发现—请求抓取—状态记录—结果判定”这条链路逐段验证：先确认待检URL从哪里来，再确认抓取工具实际请求到了什么，最后确认判定规则是否把非死链误判为死链。只要某一段的输入与输出对不上，检测结果就不可信。
先画出检测链路的四段依赖
一次死链检测通常包含四个环节，每一环都依赖上一环的输出：
- 链接来源：从站点地图、页面HTML、日志或数据库导出待检URL列表。
- 抓取请求：对每个URL发起HTTP请求，处理重定向、超时和并发限制。
- 状态记录：保存状态码、最终跳转地址、响应时间等原始证据。
- 结果判定：按规则把哪些状态归为死链，生成待处理清单。
如果只盯着最后一份死链清单，就无法判断错误发生在哪一段。建议在检测开始前就把这四段的输入输出各留一份快照，便于后续对比。
逐段核验输入与输出是否一致
第一段要核对链接来源是否完整。如果来源是站点地图，先确认站点地图本身可访问且格式正确；但站点地图不保证收录，它只是候选URL的来源之一。若来源是页面抓取，要确认抓取时是否执行了JavaScript，否则动态插入的链接会整体缺失。
第二段要核对请求是否真的发出。可以抽取少量URL手动访问，与工具记录对照。常见差异包括：工具请求被robots.txt拦截、被防火墙拦截、超时后记为失败。robots.txt的抓取限制不等于可靠的索引移除，它只约束遵守规则的抓取行为；如果检测工具遵守robots.txt，被拦截的URL会记为未抓取，而不是死链。
第三段要核对状态记录是否保留了重定向链。只记录最终状态码会掩盖中间跳转，例如最终返回200但中间经过一次301到失效地址再跳回，这种链路对用户和搜索引擎都不友好，却可能被判为正常。
第四段要核对判定规则。常见误判是把403、429、超时直接归为死链。这些状态可能只是临时拒绝或限流，需要在不同时间、不同网络环境复测后才能确认。
用一份最小对照表定位断点
可以按下面这个格式做小样本对照，每段记录预期与实际：
URL | 来源 | 预期状态 | 实际状态 | 最终地址 | 判定
假设某URL来源为站点地图，预期200，实际返回301后落到404，最终地址与原始URL不同，判定为死链。这时断点在第三段：重定向链没有被完整记录，导致判定依据不完整。如果实际状态是“未抓取”，则断点在第二段，应先检查robots.txt和访问限制，而不是直接修改页面链接。
适用条件是样本量不必大，10到20个URL即可覆盖不同来源和不同状态类型。判断结果是：哪一段的预期与实际偏差最大，就优先排查那一段，而不是从最终清单反推。
选择检测方式时比较代价
不同检测方式的代价不同，选择依据是站点规模和更新频率：
- 全站爬取：覆盖最全，但耗时和服务器压力最大，适合定期执行而非每次发布后执行。
- 日志分析：反映真实用户和搜索引擎的访问情况，但只能发现已被访问过的链接，无法发现从未被点击的死链。
- 增量检测：只检查新增或修改页面中的链接，速度快，但依赖历史基线准确。
如果站点页面数量大且更新频繁，可以先用增量检测缩小范围，再对重点栏目做全量复核。如果站点较小，直接全量爬取更省心。
下一步：建立可复现的检测记录
选定检测方式后，固定记录每次检测的链接来源、抓取时间、工具版本和判定规则，并保留原始状态数据。这样下次出现争议时，可以直接对比两次记录，判断是链接真的失效，还是抓取环境变化导致的误报。
