死链处理：检查前需要准备哪些信息
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5411e088d239.html
📄
死链处理：检查前需要准备哪些信息
开始死链处理之前，最需要准备的不是工具，而是三类可核对的信息：一份完整的待检查URL清单、每条URL的来源与重要性标记、以及当前站点可用的访问与抓取条件。缺少这些信息，后续的检查结果往往只能告诉你“某个链接打不开”，却无法判断它该修复、该跳转还是该删除。
先整理一份可逐条核对的URL清单
死链处理的对象是具体URL，不是页面标题或栏目名称。清单至少要包含完整地址，包括协议、域名、路径和查询参数。查询参数不同的地址可能返回不同状态，不能只保留主路径。
- 来自站内导航、文章正文、图片或按钮的链接。
- 来自XML站点地图、历史提交记录或后台导出的地址。
- 来自外部合作方、旧版页面或用户反馈中提到的地址。
- 已经设置过跳转的地址，需要记录跳转目标。
如果清单里混入了测试域名、本地地址或已经废弃的临时路径，要先标注出来。它们不是线上死链，检查时容易产生噪声。假设某篇文章里写的是 http://example.com/old-page，而站点早已启用HTTPS，那么真正需要确认的是新协议下该路径是否仍然有效，而不是直接把它当成死链。
记录每条链接的来源和业务重要性
同一个404地址，出现在主导航和出现在三年前的文章末尾，处理优先级完全不同。检查前应给每条URL补充来源字段，例如“导航”“正文”“页脚”“外部引用”“站点地图”。同时标注它是否承担转化、报名、下载或核心内容入口的作用。
判断依据可以按下面这个顺序：
- 是否有其他页面持续链接到它。
- 是否有外部来源或用户收藏可能仍在访问。
- 是否对应已下架的产品、活动或旧版页面。
- 是否存在内容相同或相近的替代页面。
这些信息决定了后续动作。有替代页面且内容接近，通常优先考虑301跳转；没有替代内容但仍有访问价值，可以考虑恢复或新建页面；既无内容也无入口价值，才适合让服务器正常返回404或410。
确认当前可用的访问与抓取条件
检查死链前，要确认你能否稳定访问目标站点，以及搜索引擎能否正常抓取。需要准备的信息包括：服务器是否允许你的检查工具访问、是否存在防火墙或频率限制、robots.txt是否限制了相关路径、站点地图是否可访问。
这里有一个常见误区：robots.txt禁止抓取，不等于页面已经从索引中移除。它只是限制抓取行为，已经收录的地址仍可能出现在结果里。站点地图也一样，它帮助发现地址，但不保证收录。检查时应把“可抓取”和“可索引”分开记录。
如果站点使用HTTPS，也不要因为协议是HTTPS就认为没有安全问题。证书有效只说明传输层身份和加密状态，和页面是否存在漏洞、是否被恶意篡改是两件事。检查死链时只需确认证书没有导致访问中断即可，不必把它当成安全审计。
准备状态码、跳转链和页面内容的对比依据
检查时不能只看“能不能打开”。要记录HTTP状态码、跳转经过的每一跳、最终落地页的标题和主要内容。常见情况包括：
- 返回404或410，表示地址不存在或已删除。
- 返回301或302，表示发生了跳转，需要继续看最终地址。
- 返回200但页面内容是错误页或空白页，这属于软404，需要单独标记。
- 返回403或429，可能是访问被拒绝或请求过于频繁，不一定是死链。
跳转链尤其重要。A跳到B、B又跳到C，这种多跳会拖慢访问，也可能让用户和搜索引擎困惑。检查前应约定记录格式，例如“原地址→状态码→跳转目标→最终状态码”。有了统一格式，复查时才能对比处理前后的变化。
处理之后如何复查
每处理一批死链，都要用同一份清单重新检查。复查重点不是“有没有返回200”，而是：
- 原地址是否按预期跳转到最相关的新地址。
- 跳转目标是否返回200，且内容与用户预期一致。
- 站内是否还有旧地址残留，需要同步替换。
- 站点地图和内部链接是否已经更新。
如果某条地址被判定为应该删除，复查时确认它返回的是404或410，而不是跳转到首页。把所有死链都跳首页，短期看似减少了404，长期会让用户和搜索引擎无法判断原内容去向，也容易掩盖真正需要修复的问题。
下一步可以从清单中挑出十条最重要的地址，先完成一轮“记录状态码—判断处理方式—修改—复查”的闭环。跑通这个小流程后，再扩展到全量清单，会比一开始就大规模扫描更容易控制结果。
