网站死链检测，怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /867d3f2984c1.html
📄
网站死链检测，怎样取得可复查的状态证据
可复查的状态证据，核心是让每一次死链判断都能被第三方按同样的输入、同样的规则重新跑一遍并得到一致结果。做法是固定检测对象与请求方式，保存原始响应，记录判断规则与时间，并把结果落到可版本管理的文件里。
先明确什么算“可复查”
可复查不等于“我看到浏览器打不开”。它至少要满足三点：别人知道测了哪些URL，知道用什么方式测的，知道依据什么判定为死链。缺任何一项，结论就只能算个人观察，不能作为改进依据。
适用前提是：你已经有页面或项目，能列出待检测的链接清单，并且能保存文本结果。如果链接来自数据库或模板，先导出成一份纯URL列表，每行一个，作为后续所有步骤的固定输入。
固定检测输入与请求方式
把检测对象和请求方式写进同一份记录，才能避免“换了工具结论就变”。建议记录以下字段：
- URL：完整地址，含协议与路径，不改写、不补全。
- 请求方法：一般用GET；只测资源存在性时也可用HEAD，但要注明，因为部分服务器对HEAD响应不同。
- 跟随跳转：是否跟随3xx，跟随几次。不注明跳转策略，最终状态码会不一致。
- 请求头：是否带User-Agent、Cookie、Referer。
- 检测时间：精确到日期与时段，便于解释临时故障。
这些字段写好后，每次检测沿用同一套，结果才可横向比较。若中途改了User-Agent或跳转策略，应视为新的一轮检测，不能和旧数据混在一起算。
保存原始响应，而不是只存结论
只记“死链：12条”无法复查。应保存每个URL的原始状态码、最终URL、响应时间与错误信息。命令行工具可以输出结构化结果，例如用curl逐个取状态码：
curl -o /dev/null -s -w "%{http_code} %{url_effective}\n" -L 链接地址
把输出重定向到文本文件，例如curl ... >> deadlink-20250101.txt。这样文件本身就是原始证据，别人可以逐行核对。注意-L表示跟随跳转，若你的规则是不跟随，就去掉它，并在记录里写明。
判断规则要落到具体数值：4xx与5xx通常视为死链；3xx在跟随跳转后落到4xx才算死链；超时单独标记，不能直接等同404。不同现象可能有多个解释，比如5xx可能是源站临时故障，也可能是路由配置错误，在未定位前只记录现象，不下唯一结论。
用清单做交叉验证
单一工具的结果可能受网络、限流或缓存影响。可执行步骤是：
- 用同一份URL清单，在两个不同网络环境各跑一次。
- 对比两次结果，把只出现一次异常的URL单独列出。
- 对异常URL手动访问一次，记录浏览器看到的最终状态。
- 把三次结果合并，只把稳定复现的4xx、5xx记为确认死链。
验收信号是：确认死链在多次检测中状态一致，且原始响应文件可被他人重新执行得到相同结果。若某URL时好时坏，应标记为“待观察”，而不是直接删除或改链。
把证据纳入版本管理
每轮检测结果按日期命名，提交到代码仓库或共享文档，保留历史版本。这样当有人问“为什么上个月这条链接被删了”，可以直接调出当时的响应文件。同时记录本轮改动：修复了哪些链接、替换成什么目标、依据哪份检测文件。判断结果是否可信，看的是输入、响应、规则三者是否齐全，而不是看工具名称。
下一步：从现有页面导出URL清单，按上面的字段跑一轮检测，把原始输出保存下来，再决定哪些链接需要修复。
