📍 WDQWDWQD987AAAAA:216.73.217.108
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6472f1861e65.html
📄

死链优化：检查前需要准备哪些信息 - 定位404与失效链接的证据清单

检查死链前，至少要先准备好四类信息：失效URL本身、该URL的发现来源、期望的正确去向，以及可复现的访问记录。缺少任何一项，后续判断都容易从“定位原因”滑向“凭感觉改链接”。下面按观察、判断、处理、复查的顺序说明该收集什么、怎么用。

先记录死链的原始表现，而不是只记一个网址

发现一个失效链接时，第一步是把它当时的真实表现记下来。同一现象可能有多个解释，不要急着下结论：

• 返回状态码：是404、410，还是301/302跳到了无关页面，或是200但内容已变成错误页。状态码不同，处理方式完全不同。
• 访问方式：是站内点击、外部来源跳入，还是搜索引擎抓取时命中。三者对应的修复优先级不一样。
• 完整URL：包含协议、域名、路径、查询参数。带参数的URL失效，往往和参数规则或重写规则有关。
• 复现时间与工具：用浏览器直接访问、用命令行请求、用抓取工具检测，结果可能不一致，需要注明用的是哪种方式。

如果只拿到一条“这个链接打不开”的反馈，先自己复现一次，确认现象是否稳定。偶发失败可能是网络或服务端临时问题，不等于死链。

准备发现来源与影响范围，判断优先级

知道死链从哪来，才能判断它值不值得优先修。检查前应整理：

• 站内来源：哪些页面、导航、按钮或站点地图里指向了这个失效URL。来源页面的流量和重要性越高，修复越靠前。
• 站外来源：外部网站、广告、社交媒体或历史邮件中是否还在引用。外部来源无法直接改，通常更适合在服务端做重定向。
• 是否曾被收录：如果该URL曾出现在搜索结果中，处理方式要考虑重定向或返回410，而不是简单删除了事。
• 数量与分布：是单条失效，还是某个目录、某批规则整体失效。批量问题要查规则，不要逐条改。

这一步的产物是一张清单：URL、来源、影响范围、初步优先级。它决定了后面是逐条修还是改规则。

确认期望去向与站点约束条件

修复死链不是把404变成200就行，还要明确“应该去哪里”。检查前需要和内容或业务方确认：

• 该URL对应的内容是否还存在。存在就找当前有效地址，不存在则判断是永久移除还是暂时下线。
• 是否有语义最接近的替代页面。重定向应指向内容相关的页面，而不是首页，否则对用户和抓取都没有帮助。
• 站点是否有统一的重定向规则、URL命名规范或目录结构。批量处理要符合现有规则，避免制造新的冲突。
• robots.txt 是否限制了相关路径。注意：robots.txt 的抓取限制不等于可靠的索引移除，它只影响抓取，不保证页面从索引中消失，两者要分开处理。

把这些确认结果写进清单，每条死链后面标注“目标URL”或“返回410”。没有明确去向的条目，先不要动手改。

准备可复查的记录格式与验证方法

检查完成后要能复查，所以一开始就用可对比的格式记录。推荐每条至少包含：

1. 原始URL与发现时间；
2. 修复前状态码与复现方式；
3. 采用的处置方式（重定向、返回410、修正来源链接等）；
4. 修复后状态码与验证时间；
5. 验证时使用的请求方式，例如命令行请求：curl -I https://example.com/old-page，观察返回的状态码和 Location 头。

复查时重点看两件事：状态码是否已按预期变化；来源页面上的链接是否已指向新地址。如果站点地图中仍保留失效URL，也要同步更新，但要记住站点地图不保证收录，它只是提交线索。另外，HTTPS 不保证安全无漏洞或排名，它和死链修复是两件事，不要混在一起判断。

下一步：拿一个已确认的失效URL，按上面的清单补齐来源、期望去向和复现记录，再决定是逐条重定向还是改规则。