死链处理方法：怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /690fbef4bc9d.html
📄
死链处理方法：怎样取得可复查的状态证据
要取得可复查的状态证据，核心是让每一次死链判断都能被第三方按同样的地址、时间和方法重新验证。做法是先用HTTP状态码和响应头记录当前结果，再保存重定向链、页面正文特征与抓取时间，最后把证据整理成带时间戳的清单。只有能重复得到同一结论的记录，才算可复查；仅凭一次浏览器打开失败或工具里的红色提示，不足以作为处理依据。
先明确什么算可复查的状态证据
可复查意味着别人拿到你的记录后，能独立重复检查过程。它至少包含四项：被检查的完整URL、检查发生的日期时间、使用的请求方法或工具类型、观察到的原始结果。原始结果不是“打不开”三个字，而是状态码、响应头中的Location、最终落地URL以及页面标题或正文片段。
判断标准可以这样记：如果换一个人、换一台网络环境正常的机器，按记录重做一次，得到相同状态码和相同落地地址，这份证据就成立；如果两次结果不同，说明它受缓存、地区、登录状态或时间影响，需要补充条件说明。
第一步：用状态码和响应头固定当前事实
对每个待查URL发起一次请求，记录返回的状态码。常见情况包括：
404或410：资源当前不可用，属于典型死链信号。301或308：永久重定向，需记录Location指向哪里。302、303、307：临时重定向，不能直接当作永久处理依据。200：请求成功，但仍要检查页面内容是否已变成无关页或空壳页。5xx：服务器端错误，可能是暂时故障，不宜立即判定为死链。
记录时把响应头中的Location、Cache-Control和服务器时间一并保存。若使用命令行，可执行curl -I -L 完整URL，其中-I只取响应头，-L跟随重定向；把输出原样粘贴到证据表，不要只写结论。
适用条件是公开可访问的页面。若页面需要登录、地区限制或特定User-Agent，应在记录中写明这些前提，否则复查者会得到不同结果。
第二步：把重定向链和落地页内容一起留档
单个状态码往往不够。一个URL可能先返回301，再跳到另一个302，最后落到一个200的无关页面。只记录第一步，会误判为“已修复”。
可执行的检查项：
- 记录完整跳转链，每一步的URL和状态码都写入清单。
- 记录最终落地页的标题、H1和一段正文摘要，确认它与原链接主题是否一致。
- 若落地页返回
200但内容是首页或搜索页，标记为“软404嫌疑”，单独复核。 - 对同一URL间隔一段时间再查一次，确认状态是否稳定。
验收信号是：跳转链每一步都有明确状态码，最终页面主题可判断，且两次检查结果一致。若第二次结果变化，应保留两次记录并注明检查时间，而不是删掉旧记录。
第三步：区分可能原因与已经定位的原因
看到404只说明当前请求未找到资源，不等于已经知道原因。可能原因包括内容被删除、URL拼写变化、服务器配置改动、大小写敏感、参数被过滤等。已经定位的原因，必须能通过对比证据排除其他解释。
例如，假设某旧文章地址返回404，而站内新地址返回200，且旧地址没有配置跳转。此时可以说“旧地址未设置重定向”，这是已定位；但不能直接断言“内容已永久删除”，因为也可能只是路径规则未覆盖。把“可能”和“已定位”分列两栏，能避免把猜测写进处理结论。
把证据整理成可交接的清单
一份够用的死链证据表可以包含：URL、检查时间、请求方式、状态码、重定向链、最终URL、页面标题、备注。每次处理前后各存一份，处理后再复查同一批URL，用状态码变化作为验收依据。
需要注意，robots.txt中的抓取限制不等于可靠的索引移除，它只约束抓取行为，不能替代状态码证据；站点地图也不保证收录，不能因为URL写进站点地图就认为它有效。若涉及具体搜索引擎的收录状态，应到对应搜索引擎的官方工具中分别核查，而不是用一份记录推断所有引擎。
下一步：选十个已知有问题的URL，按上面的字段建立第一版证据表，先完成一轮状态码与跳转链记录，再决定哪些需要设置重定向、哪些保留为410、哪些继续观察。
