📍 WDQWDWQD987AAAAA:216.73.216.45
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e6286ff16caa.html
📄

死链测试工具：怎样取得可复查的状态证据

用死链测试工具取得可复查的状态证据，核心不是“跑一次报告”，而是把每次检测的输入、原始响应、判定规则和复核记录一起留存。交付时应能回答：谁在什么时间、对哪个版本、用什么规则测了哪些链接，为什么判定为死链，别人如何在不重跑的情况下验证同一结论。

先定义可复查证据的四个组成部分

一份能通过验收的死链状态证据，通常由四块内容构成，缺一块都会导致返工。

• 检测输入：被测链接清单或站点范围、链接来源（页面、站点地图、日志、历史报告）、URL 规范化规则（是否去参数、是否统一大小写、是否跟随跳转）。
• 原始响应：每个 URL 的最终状态码、跳转链、响应时间、检测时间点、请求方法。状态码要记录最终值，而不是只记“成功/失败”。
• 判定规则：明确哪些状态算死链。例如 404、410 通常视为死链；5xx 属于服务端异常，需要复测；403 可能是权限或反爬，不能直接下结论。
• 复核记录：复测时间、复测结果、处理动作（修复、删除、加跳转、忽略）、责任人、验收人。

从交付结果倒推任务与责任

如果最终交付物是“可复查的死链状态报告”，任务就不能只落在执行检测的人身上。可以按下面的分工拆解。

1. 发起方：确认检测范围、时间点和验收标准，例如“本次只覆盖主站文章页，参数化 URL 归并为一个”。
2. 检测执行人：运行死链测试工具，导出原始结果，保留工具名称、版本、配置和运行时间。
3. 复核人：抽取样本复测，重点检查 3xx、403、429、5xx 以及超时项，确认判定规则是否被正确应用。
4. 修复责任人：对确认的死链给出处理方式，并回填处理后的 URL 与状态。
5. 验收人：按约定标准检查证据链是否完整，而不是只看“死链数量是否为零”。

状态码之外，还要记录哪些判断依据

只看状态码容易误判。以下几种情况需要在证据中单独说明。

• 跳转链：A 跳 B 再跳 C，最终 200，但中间有 404 或循环跳转，应记录完整链路，不能只记最终状态。
• 软 404：页面返回 200，但内容为“页面不存在”。这类问题状态码检测不出来，需要结合页面标题、正文特征或人工抽查。
• robots.txt 限制：抓取被限制不等于链接失效，也不等于索引被移除。遇到抓取受限，应在证据中标注“未取得有效响应”，而不是直接判为死链。
• 站点地图中的链接：站点地图不保证收录，里面的 URL 返回 200 也不代表已被索引；它只能作为待测链接来源之一。
• HTTPS 相关：证书有效、协议为 HTTPS 不代表页面没有其他问题，也不保证安全无漏洞或排名。检测时应把证书错误与 HTTP 状态分开记录。

一个可执行的抽样复核方法

假设某次检测报告列出 120 个异常 URL，其中 80 个 404、20 个 5xx、15 个 403、5 个超时。复核时可以这样操作：

1. 从每类异常中各抽 3 至 5 个，用不同时间点或不同网络环境复测。
2. 对 404 和 410，确认是否为稳定状态；若复测变为 200，说明原报告的时间点或环境有影响。
3. 对 5xx，先复测两次；仍失败则标记为服务端问题，交给对应责任人，不直接归入“需删除链接”。
4. 对 403 和 429，检查是否由频率限制、权限或反爬导致；这类结果不能单独作为死链结论。
5. 把复测结果与原始记录并列写入报告，注明“已复核”或“待复核”。

判断标准可以提前约定：复测结果与原始结果一致，视为证据成立；复测结果不同，则需要保留两次记录并说明差异原因。这样即使后续有人质疑，也能沿着时间线回看。

验收时检查什么

验收人不必重跑全部链接，但应确认以下检查项：报告是否包含检测时间与范围；是否保留原始响应而非仅汇总数字；判定规则是否书面化；异常项是否区分了“可能原因”与“已经定位的原因”；修复项是否有回填状态；未处理项是否有明确责任人和期限。缺少其中任何一项，都可能让后续协作重新解释同一份数据，造成返工。

下一步，可以把上述四类证据整理成一个固定模板，在下次检测前先确认模板字段，再运行死链测试工具。这样交付的是可复查的状态记录，而不只是一份链接列表。