网站死链修复：怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2050944fa7cc.html
📄
网站死链修复：怎样取得可复查的状态证据
可复查的状态证据，是指任何人都能用同一请求、同一时间范围和同一判断标准重新得到相同结论的记录。对网站死链修复来说，它至少要包含请求的完整 URL、请求时间、HTTP 状态码、重定向链、最终落点，以及判断“这是死链还是正常跳转”的依据。只截一张 404 页面图不够，因为无法复查；只凭抓取工具里一个红色标记也不够，因为工具可能把超时、被拦截或临时故障都归为错误。
先确定要证明的是哪一类“死链”
“死链”在日常沟通中常混指几种不同情况，证据形式也不同。先分类，才能决定采什么证据。
- 硬 404 / 410：请求返回 404 或 410。证据核心是状态码和响应头，而不是页面文案。
- 软 404：URL 返回 200，但内容实际是“页面不存在”。证据要同时保留状态码和页面正文特征。
- 跳转链失效：原 URL 有 301 或 302，但链中某一跳指向 404。证据必须记录完整跳转链，不能只记起点和终点。
- 连接层失败：DNS 解析失败、TLS 握手失败或连接超时。这类现象不能直接断言为 404，需要单独标注为“未取得 HTTP 响应”。
把这几类混在一起，会让后续修复决策失真。例如，把超时当 404 去删链接，可能删掉本来正常的页面。
用可重复的命令行请求留下原始记录
最容易被复查的证据，是带时间戳的原始请求输出。以下命令只作为方法示例，域名需替换为你要检查的实际地址。
curl -sS -o /dev/null -D - -L --max-redirs 10 -w '\n%{http_code} %{url_effective} %{time_total}\n' https://example.com/old-page
这条命令会输出响应头、重定向过程和最终状态码。-L 表示跟随跳转，--max-redirs 10 限制跳转层数，避免陷入循环。%{url_effective} 是最终落点，%{time_total} 是总耗时。把输出保存为文本文件，并记录执行时间，就形成了一条可复查证据。
判断时注意：如果最终状态码是 200，但 %{url_effective} 与请求 URL 不同，说明发生了跳转，应检查跳转是否指向相关页面。如果最终状态码是 404，且跳转链中无循环，可判定为硬死链。如果命令返回连接错误而没有状态码，应记录为“未取得 HTTP 响应”，再单独排查 DNS、TLS 或网络问题。
批量检查时保留逐条结果，而不是只留汇总数字
批量工具适合发现候选问题，但汇总数字不能替代逐条证据。选择工具时，比较三个条件：是否输出每个 URL 的状态码、是否显示重定向链、是否区分超时与 404。只给“错误数”的工具，复查价值低。
可以执行的步骤是：
- 从站点地图、内部链接或服务器日志中导出待检查 URL 列表，并记录导出时间。
- 对每个 URL 发送请求，保存状态码、最终 URL、响应时间和请求时间。
- 把结果按状态码分组，单独标出 3xx、4xx、5xx 和无响应四类。
- 对 4xx 和 5xx 逐条人工确认，排除临时故障和访问限制造成的误报。
- 把确认后的清单与原始输出一起存档，注明检查日期和使用的请求方式。
适用条件是：页面数量较多、需要向他人说明修复依据。代价是需要保存原始文件，不能只保留一张汇总表。如果只是临时查看单个链接，命令行单次请求已经够用。
区分“可能原因”和“已经定位的原因”
同一个现象可能有多个解释，证据的作用是缩小范围，而不是提前下结论。
- 返回 404：可能是页面已删除，也可能是路径拼写错误，还可能是服务器配置把请求导向了错误目录。只有检查服务器路由或文件记录后，才能说已经定位。
- 返回 403：可能是权限限制，也可能是防护规则拦截了检查请求。403 不等于死链，需要换请求方式或查看服务器日志再判断。
- 返回 200 但内容为空：可能是软 404，也可能是页面正常但内容尚未加载。要结合页面正文和模板特征判断。
- 跳转后回到原 URL：可能是循环跳转。需要记录每一跳，不能只看最终状态码。
另外，robots.txt 的抓取限制不等于可靠的索引移除，它只约束抓取行为；站点地图不保证收录；HTTPS 也不保证页面安全无漏洞或排名提升。这些都不能当作死链修复的状态证据。
把证据整理成可复查的修复记录
一条完整的修复记录至少包含：原 URL、检查时间、请求方法、状态码、重定向链、最终落点、判断结论、修复动作、修复后复查时间与复查结果。修复动作可以是更新链接、设置 301 跳转、恢复页面或移除入口，具体取决于原页面是否还有等价内容。
复查时使用与首次检查相同的请求方式和判断标准。如果首次用命令行、复查只用浏览器目测，结论就不可比。若状态码从 404 变为 301，再变为 200，应记录整条链，而不是只写“已恢复”。
下一步可以选一个已确认的死链，用上面的命令行请求保存原始输出，再按记录格式补全修复前后两次检查，形成第一条可复查样本。
