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

死链修复工具怎样取得可复查的状态证据 - 交付前先统一记录口径

可复查的状态证据，指的是任何人拿到你的记录，都能在相同条件下重新发起一次检查，并得到可对照的结果。对死链修复工具而言，证据不是“我点过一遍都正常”，而是把检查时间、请求地址、返回状态、跳转链和判断依据一起留下来。多人协作时，先约定记录格式，再动手修，返工最少。

先区分三类状态，别把工具界面当结论

死链修复工具通常给出三种信息，混在一起就会产生争议：

• 工具自身的抓取结果，例如某链接返回 404、超时或连接被拒。
• 服务器实际返回的响应，需要单独请求确认。
• 页面在浏览器里的最终呈现，可能经过多次跳转。

可复查的证据要落在第二类上。工具结果是线索，不是结论。比如工具报 404，可能是目标页确实不存在，也可能是服务器临时拒绝、请求头不被接受、或抓取频率过高被限流。这三种解释对应的处理方式完全不同，所以记录里必须写清“观察到什么现象”，而不是直接写“已确认死链”。

一条合格证据应包含哪些字段

无论用表格还是工单，建议每条记录至少包含以下内容，字段名可以按团队习惯调整：

1. 原始链接与最终链接，两者都保留，便于看出跳转是否合理。
2. 请求方法与请求时间，精确到分钟即可，用于判断是否为瞬时故障。
3. HTTP 状态码，以及如果发生跳转，完整跳转链的顺序。
4. 检查方式，例如命令行请求、浏览器开发者工具、或工具导出结果。
5. 结论与处理动作，例如“改为新地址”“删除入口”“保留观察”。

这里的关键是让状态码和链接成对出现。只写“首页有死链”无法复查，写“某入口链接在指定时间返回 301 到新地址，新地址返回 200”才能被别人验证。

用命令行留下可复核的原始记录

以 curl 为例，下面的写法会输出状态码和跳转链，适合贴进工单：

curl -sSIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/old-page

其中 -I 只取响应头，-L 跟随跳转，-w 输出最终状态码和最终地址。如果只想看跳转过程，可以加 -v 观察每一跳。注意：假设某链接返回 301，而最终地址返回 404，那么这条记录应同时保留两个状态，结论是“跳转目标已失效”，而不是“原链接正常”。

适用条件：服务器允许 HEAD 请求时用 -I 更快；若对方对 HEAD 返回 405，改用 -o /dev/null -w 配合 GET 再取一次。判断结果时，只要状态码与链接对得上，证据就成立；若两次请求结果不同，说明存在不稳定因素，应记录为“待复测”而非直接下结论。

验收信号：别人能否独立复现

交付前做一次交叉检查，让另一位同事按你的记录重跑其中三条链接。如果对方得到相同状态码和相同最终地址，证据合格；如果出现差异，先排查请求时间、请求头、网络出口是否一致，再决定是否需要补充说明。以下情况应视为不合格证据：

• 只有截图没有链接文本，无法复制重试。
• 只写“已修复”，没有修复前后的状态对照。
• 把 robots.txt 的抓取限制当成链接失效的证据，两者不是一回事。
• 用站点地图是否包含某地址来判断链接是否有效，站点地图不保证收录，也不代表链接可访问。

另外，HTTPS 只能说明传输层有加密，不代表页面一定可访问或内容正确，检查时仍要看状态码和最终地址。不同搜索引擎对同一地址的处理也可能不同，若结论要用于搜索侧，需分别核查，不能互相替代。

多人协作时的最小流程

把流程压到三步即可执行：第一，检查人只负责填写原始状态，不写处理建议；第二，修复人根据原始状态决定动作，并回填修改后的状态；第三，验收人随机抽三条重跑，确认前后状态可对照。这样责任清楚，返工点集中在状态不一致的记录上，而不是整批重查。

下一步，挑出你手上最近一批死链记录，按上面的字段补全三条，交给同事复跑一次。能复现的留下，不能复现的标为待查，再决定是否继续扩大检查范围。