死链处理方法，检查前需要准备哪些信息
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /266bc30f7a52.html
📄
死链处理方法，检查前需要准备哪些信息
处理死链之前，最该准备的不是工具账号，而是一份能复现问题的证据清单：至少要知道死链出现在哪个页面、指向什么地址、返回什么状态、从什么时候开始、影响哪些入口。缺少这些信息，直接改链接或提交删除，很容易把“暂时打不开”误判成“永久失效”，也可能删掉本应保留的旧地址。
先分清“死链”与“打不开”
一个常见误解是：只要链接点开报错，就当成死链删掉。实际上，同一个现象可能有多种原因。服务器临时故障、网络超时、权限限制、地区差异、抓取被限制，都可能让访问失败，但地址本身并未失效。真正需要处理的死链，通常指目标资源已经不存在或永久迁移，返回状态明确为 404、410 一类，或者长期无法恢复。
因此检查前要准备的，是能区分“可能原因”和“已经定位原因”的材料。比如只看到浏览器提示错误，只能算现象；如果同时记录了 HTTP 状态码、响应头、发生时间和复现步骤，才更接近可判断的证据。
检查前应收集的基础信息
- 死链的完整地址：包含协议、域名、路径和查询参数，不要只记首页或短链。
- 发现位置：来自站内导航、正文、站点地图、外部平台还是用户反馈，位置不同，处理优先级不同。
- HTTP 状态码与响应头：区分 404、410、301、302、403、500、超时等，状态码是判断资源是否存在的重要依据。
- 首次发现时间与频率：偶发一次和持续多天，处理方式不同。
- 影响范围：是单个页面、一个栏目，还是全站大量链接。
- 是否已有替代地址：旧内容是否迁移到新路径，决定用重定向还是保留失效提示。
如果站点有多个语言版本或多个子域，还要分别记录，因为同一路径在不同环境下可能结果不同。
用可复现的步骤确认状态
准备信息时，不要只看一次浏览器结果。可以按下面步骤做一次最小复现：
- 用无痕窗口或退出登录后访问该地址，排除登录态和缓存影响。
- 用命令行查看响应状态，例如：
curl -I https://example.com/old-page。把返回的状态码和 Location 响应头记下来。 - 换一个网络环境或设备再试一次，确认是否为本地网络问题。
- 如果页面由脚本跳转，查看跳转前后两个地址，避免把前端跳转误认为服务器重定向。
判断结果时：返回 301 或 302 且指向有效新地址，通常说明迁移已配置；返回 404 或 410，才更接近内容已移除；返回 403、500 或超时，应先排查权限、服务器和网络，而不是直接删除链接。
容易被忽略的边界信息
检查前还要准备与抓取和索引相关的信息，但不要把限制手段当成移除手段。robots.txt 可以限制抓取，却不等于可靠的索引移除；站点地图列出地址，也不保证被收录。若死链涉及 HTTPS，证书有效也不代表页面一定安全或一定被保留。不同搜索引擎对状态码和移除请求的支持情况并不相同，需要分别核查，不能用一个平台的结果推断全部。
另外，如果旧地址曾经有外部链接或用户收藏，删除前要评估是否设置重定向。没有替代内容时，返回 410 比返回 404 更明确地表达“已永久移除”，但两者对用户的实际体验差异有限，关键仍是不要让访问者落到无说明的错误页。
把信息整理成一张可核对清单
实际执行时，可以把每条死链整理成一行记录：完整地址、发现位置、状态码、响应头、首次发现时间、影响页面数、是否有替代地址、处理动作、复查日期。这样做的目的不是追求格式统一，而是让下一次检查能直接对比：状态码是否变化，重定向是否生效，旧地址是否仍被引用。
下一步，先挑一条影响最明确的死链，按上面的清单补齐信息，再决定是修复、重定向还是保留失效状态。不要在没有状态码和替代地址的情况下批量删除链接。
