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

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

用死链接检测工具取得可复查的状态证据，核心不是看工具给出的“404 数量”，而是把每一次判定还原成“请求哪个 URL、在什么时间、用什么客户端、收到什么状态码或错误、跳转到哪里”这五项记录，并保留原始响应文件。只有这些记录能被别人独立复现，检测结果才算证据，而不是一次性的截图或口头结论。

常见误解：工具报错不等于链接已死

第一次接触这类工具时，最容易把“工具标红”直接当成死链。实际上一项现象可能有多个解释：目标服务器临时超时、返回 403 拒绝爬虫、返回 429 限流、DNS 解析失败、TLS 证书问题，或者工具自身把软 404 误判为正常页。这些情况的处理方式完全不同，不能只凭一次扫描就断言链接失效。

可复查证据的意义就在于区分“可能原因”和“已经定位的原因”。如果只保存一张汇总报表，别人无法判断到底是目标真的返回 404，还是检测方被拦截。保留原始响应，才能让判断有依据。

一次可复查的检测应记录什么

对每个被判为异常的 URL，至少保存以下字段，并让它们互相对应：

• 完整请求 URL，包括协议、主机、路径和查询参数，不做归一化删减。
• 请求时间，精确到秒，并注明时区。
• 使用的客户端标识，例如 User-Agent 字符串，以及是否跟随跳转。
• 最终状态码，以及跳转链上每一跳的状态码和 Location 目标。
• 原始响应头与响应体片段，或工具导出的原始结果文件。
• 检测所用工具的版本或命令，便于他人用同样条件重跑。

这六项组合起来，才构成一条可复查证据。缺了请求时间或客户端标识，别人重跑时结果不同就无法解释。

可执行步骤：从扫描到固定证据

下面是一套可以直接照做的流程，适用于第一次建立检测记录的场景。

1. 先用工具做一轮全量扫描，导出原始结果文件，不要只截图汇总页。
2. 对每个异常 URL，用命令行单独请求一次，保存完整响应。例如：curl -sS -D headers.txt -o body.txt -L --max-redirs 5 "https://example.com/page"。这里的 -D 保存响应头，-o 保存响应体，-L 跟随跳转。
3. 把工具结果与命令行结果并排比对：状态码是否一致，跳转链是否一致，客户端标识是否不同。
4. 对不一致的条目，换一个客户端标识再请求一次，判断是否为目标站点的反爬策略导致。
5. 把上述文件按“日期 + 主机 + 路径”命名归档，并写一份简短说明，记录每条异常是已定位还是仍待确认。

判断结果时按条件区分：如果两次请求都稳定返回 404，且响应体是目标站点的标准错误页，可以判定为已定位的死链；如果一次 404、一次 200，则更可能是缓存、限流或 CDN 节点差异，需要继续核查，不能下结论。

工具报表之外必须单独核查的几项

有些判断不能只靠状态码。robots.txt 的抓取限制不等于可靠的索引移除，一个 URL 被 robots 禁止抓取，并不代表它已从索引中消失，检测工具也可能因此拿不到真实状态。站点地图不保证收录，把 URL 放进 sitemap 不能作为“链接有效”的证据。HTTPS 只说明传输层加密，不保证页面安全无漏洞，也不构成排名依据。

如果检测涉及不同搜索引擎的收录情况，需要分别核查各自的抓取与索引结果，不能用一个搜索引擎的表现推断另一个。检测工具自身的抓取行为，与搜索引擎的抓取行为也是两件事，前者正常不代表后者会收录。

证据归档后的下一步

拿到可复查证据后，下一步是给每条异常标注处理动作：确认失效的链接记录替换或移除方案；被拦截导致的误报调整检测客户端；跳转链过长的记录最终目标并评估是否直接指向。处理完成后再跑一轮同样的检测，用相同字段对比前后状态，形成可追溯的闭环。