死链检查 - 怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f505ab78af8b.html
📄
死链检查 - 怎样取得可复查的状态证据
可复查的状态证据，是指别人拿着你交付的记录，能在不依赖你本人、不依赖当时浏览器缓存的情况下，重新得到同一批链接的同一类状态结论。做死链检查时，不要只交一张“404 链接清单”，而应交付三样东西：待检链接的来源清单、每条链接的请求与响应记录、以及判断为死链的规则说明。三者缺一，复查就会退化成“再跑一次看看”，而不是核验。
先确定要检查哪些链接，来源要可追溯
死链检查的第一步不是发请求，而是固定检查范围。范围来源通常包括：站点地图、站内导航与页脚、正文中的导出链接、以及历史改版留下的旧路径。每一条链接都应记录它来自哪个页面或哪个文件，这样复查时才能判断“漏检”还是“范围本来就没包含”。
建议把待检清单做成表格，至少包含：链接地址、来源页面、发现方式、加入日期。发现方式可以写“站点地图”“正文提取”“人工补充”，不要只写“系统抓取”，否则复查者无法还原筛选逻辑。
请求与响应记录要包含哪些字段
只有“是死链/不是死链”的结论无法复查。每条链接至少应保留以下字段，且这些字段应来自实际请求结果，不能靠推测填写：
- 请求时间与时区，精确到分钟即可，便于对照服务器日志。
- 请求方法，通常是
GET或HEAD；两者结果可能不同，需注明用了哪种。 - 最终 URL，与原始 URL 分开记录，用于识别跳转链。
- HTTP 状态码，例如
404、410、301、302、200。 - 若发生跳转，记录跳转次数与每一跳的状态码。
- 响应中与判断相关的头部，例如
Content-Type、Location。 - 请求失败时的错误类型，例如超时、DNS 解析失败、连接被拒绝。
这些字段合在一起，才能支撑“这条链接当时返回了什么”这一事实。只写状态码而不写请求方法与最终 URL，复查者无法判断 200 是内容页还是跳转后的软 404 页面。
用规则把“疑似”与“确认”分开
死链判断需要事先写清规则，否则同一批数据会被不同的人得出不同结论。一个可执行的规则示例（假设场景，非真实项目数据）：
- 状态码为
404或410，记为确认死链。 - 状态码为
301或302，记为待观察，需继续跟到最终 URL；若最终仍为 4xx，再记为确认死链。 - 状态码为
200，但页面内容为“页面不存在”等提示，记为疑似软 404，需人工确认。 - 请求超时或连接失败，记为未取得状态，不能直接当作死链，应重试并记录重试结果。
规则写清后，复查者才能判断某条记录属于“已定位的原因”还是“仍待验证的可能原因”。例如超时可能来自目标服务器、网络链路或本地出口，不能只凭一次超时就断言链接已死。
责任与验收：谁交什么，怎么算通过
从交付结果倒推，一次可复查的死链检查至少需要三类责任：
- 范围负责人：确认待检清单来源与截止时间，对“漏检”负责。
- 执行负责人：按统一规则发起请求并记录字段，对记录完整性负责。
- 复核负责人：随机抽取若干条记录重新请求，对结论一致性负责。
验收标准可以设为：抽取记录重新请求后，状态码与最终 URL 与原始记录一致；若不一致，需能解释是时间变化、跳转变化还是记录错误。若无法解释，则本次证据不通过。
另外要分清边界：robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录；这些与死链状态是不同层面的问题，不应混在同一份证据里下结论。
下一步：先跑一个小范围样本
第一次接触时，不要直接全站铺开。先选 20 到 50 条链接，按上面的字段和规则完整走一遍，检查记录是否足以让另一个人复现结论。样本通过后，再扩大范围；样本不通过，先补字段和规则，而不是先增加数量。
