死链检查方法_怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /00014d76e423.html
📄
死链检查方法_怎样取得可复查的状态证据
死链检查方法的核心不是“跑一次工具看红点”，而是留下能复查的状态证据：每个URL在什么时间、用什么方式、得到什么HTTP状态码或页面特征，以及这个结果能否被另一个人用同样条件复现。只有具备时间、请求条件、响应结果和判断依据，才算可复查。
先明确什么算可复查的状态证据
可复查意味着别人拿到你的记录后，能重新发起同一请求并得到可比较的结果。它至少包含四项信息：
- 目标URL：完整地址，包括协议和路径，不只写域名。
- 请求条件：请求方法、是否跟随跳转、User-Agent类型、是否带Cookie或登录态。
- 响应结果：HTTP状态码、最终跳转到的URL、响应时间。
- 记录时间：精确到日期，必要时到分钟，因为服务端状态会变化。
缺少任何一项，证据的复查价值都会下降。例如只记录“这个页面打不开”，无法判断是404、500、超时还是被防火墙拦截，也无法复现。
用命令行取得原始状态证据
最直接的方式是用 curl 发起请求并保留响应头。下面是一个可执行的例子，假设要检查 https://example.com/old-page：
curl -I -L -o /dev/null -s -w "%{http_code} %{url_effective} %{time_total}\n" https://example.com/old-page
参数含义：-I 只取响应头，-L 跟随跳转，-o /dev/null 丢弃正文，-w 输出状态码、最终URL和总耗时。判断结果时：
- 输出以
200开头，说明当前可正常访问。 - 输出以
301或302开头且最终URL与目标不同，说明发生了跳转，需要确认跳转目标是否有效。 - 输出以
404或410开头，说明资源不存在，是典型死链信号。 - 输出以
5xx开头，说明服务端出错，可能是暂时故障，需要稍后复查。 - 没有状态码或超时，说明连接层面失败，可能是DNS、网络或服务不可达。
适用条件：命令行方式适合逐条核查或小批量抽查，不适合直接替代全站抓取。它取得的是单次请求证据，不能证明其他时间或来自其他网络的访问结果相同。
批量检查时如何保留可复查记录
批量检查需要把结果落成结构化文件，而不是只看屏幕。可以用脚本读取URL列表，逐条请求并写入CSV，字段建议包括：URL、状态码、最终URL、响应时间、检查时间、检查方式。
一个简单的思路是：准备一个每行一个URL的文本文件，用循环逐条执行前面的 curl 命令，把输出追加到结果文件。这样每条记录都对应一次真实请求，复查时可以按时间排序，对比同一URL在不同日期的状态变化。
验收信号：结果文件中每一行都能对应到一条URL，状态码字段非空，检查时间可排序，最终URL与原始URL不一致时能看出跳转关系。如果某条记录只有“失败”两个字，没有状态码和时间，就不满足可复查要求。
区分“可能原因”与“已经定位的原因”
同一个现象可能有多个解释，不要看到404就直接断定页面被删除。404可能是：
- URL确实已删除或从未存在。
- 大小写敏感导致路径不匹配。
- 服务端路由配置错误。
- 请求被重写规则改写到了不存在的路径。
要定位原因，需要补充证据：查看服务器访问日志中该请求的记录，确认请求是否到达应用；对比同一路径在不同大小写下的响应；检查重写规则是否命中。只有这些证据指向同一解释时，才能说“已经定位”。否则只能写“可能原因”，并列出下一步验证动作。
把状态证据与索引状态分开看
死链检查取得的是访问状态证据，不等于搜索引擎索引状态。一个URL返回200，不代表它已被收录；返回404，也不代表它会立刻从索引中消失。要判断索引情况，需要分别到不同搜索引擎的站长平台或搜索结果中核查，不能把HTTP状态码当作收录结论。
另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。这些是不同层面的信号，检查死链时应聚焦于请求与响应本身，避免把无关信号混入证据链。
下一步怎么做
先选10条已知或怀疑有问题的URL，用 curl 命令逐条取得状态码、最终URL和时间，写入一个CSV文件。然后换一台网络环境不同的机器，对同一批URL重复一次，对比两次记录是否一致。如果一致，这份记录就可以作为可复查的状态证据；如果不一致，说明请求条件或网络路径存在差异，需要先补齐请求条件再继续扩大检查范围。
