死链查询，怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /17ecf527c798.html
📄
死链查询，怎样取得可复查的状态证据
死链查询的核心不是“打开工具看一眼有没有红叉”，而是为每个可疑 URL 留下带时间、状态码、请求方式和来源的记录，让另一个人或未来的自己能够复现判断。最可靠的做法是：先用站点内部链接和访问日志圈定候选 URL，再用命令行请求逐条抓取响应头，把状态码、最终跳转地址、抓取时间写入表格，最后人工抽查关键页面。只依赖单一在线工具截图，通常无法复查。
先明确什么算“可复查”的证据
可复查意味着证据包含四个要素：具体 URL、请求时间、原始响应、请求上下文。请求上下文包括是否带 User-Agent、是否跟随跳转、是否使用 HEAD 还是 GET。缺少任何一项，别人重新测试时都可能得到不同结果。
判断时注意：同一个 URL 对搜索引擎爬虫和普通浏览器可能返回不同状态，这属于“可能原因”，不是已经定位的原因。要确认差异，需要分别用不同 User-Agent 测试并对比响应头。
用命令行取得原始响应，而不是只看工具结论
以单个 URL 为例，可以执行下面的请求，只取响应头，不下载正文：
curl -I -L --max-time 15 -A "Mozilla/5.0" https://example.com/old-page
参数含义：-I 只请求响应头，-L 跟随跳转，--max-time 15 限制等待时间，-A 指定 User-Agent。把输出中的状态行、Location、Content-Type 复制进记录表。如果站点屏蔽了 HEAD 请求，改用 curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" -L URL，它用 GET 请求并只输出最终状态码和最终地址。
批量处理时，把候选 URL 每行一个写入文本文件，用循环逐条请求，输出追加到日志文件。这样得到的是带时间戳的原始记录，而不是工具生成的汇总数字。
状态码要结合跳转链一起看
常见情况与判断依据：
- 404 或 410：资源不存在。410 表示明确移除，但两者对死链处理都指向同一动作——修复链接或做跳转。
- 301 或 302：发生跳转。必须记录最终落地 URL，并检查落地页是否与原始内容相关。跳转到首页通常不算有效修复。
- 200 但内容为空或为错误页：这是软 404 的常见表现。状态码正常不代表内容可用，需要人工打开页面确认。
- 403、429、503：可能是访问限制或临时故障，不能直接判定为死链。应在不同时间重测，并记录重测结果。
如果一条 URL 出现跳转链，例如 A 跳 B、B 跳 C，要完整记录链条。只记录最终状态码会丢失中间环节，后续复查时无法判断是哪一步发生了变化。
时间和人手有限时的处理顺序
优先处理满足以下条件的 URL：出现在主导航、被较多内页链接、近期有外部来源点击、位于转化路径上。判断依据可以来自访问日志中的请求次数和来源页面，而不是凭感觉排序。
具体步骤：
- 从站点地图、内部链接报告或日志中导出候选 URL 列表。
- 用命令行批量请求，生成带时间戳的原始日志。
- 把 404、410、跳转链异常、软 404 分成四类。
- 先修主导航和转化路径上的问题，再处理长尾页面。
- 修复后对同一批 URL 重跑一次请求，把新日志与旧日志并列保存。
验收信号是：同一 URL 在修复前后的两次请求记录都能找到，状态码变化可解释，且最终落地页内容与原始主题一致。如果只是工具面板上的错误数下降，但拿不出前后两次原始响应，就不算完成复查闭环。
不要混淆抓取限制与索引移除
robots.txt 中的 Disallow 只限制爬虫抓取，不等于把页面从索引中移除，也不等于该 URL 已经失效。站点地图列出 URL 也不保证被收录。做死链查询时，如果发现某 URL 被 robots.txt 屏蔽，应单独记录，不能把它当作 404 处理。要确认索引状态，需要在对应搜索引擎中分别核查，不同搜索引擎的支持情况和结果可能不同。
下一步：选一个你怀疑已经失效的 URL，按上面的命令跑一次请求，把状态行、跳转地址、时间、User-Agent 四项写入表格；然后换一个时间重跑，比较两次结果是否一致。这个对比记录就是后续所有修复动作的起点。
