死链检查，改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /050a034eb55e.html
📄
死链检查，改版或迁移时应核对什么
改版或迁移时的死链检查，目标不是把旧链接全部保留，而是确认每一个旧地址最终落到哪个可用页面，并把跳转关系、状态码、责任人和验收标准写清楚。核对重点包括：旧URL清单是否完整、跳转目标是否语义对应、是否误用302或跳首页、robots与站点地图是否与迁移方案一致，以及上线后如何抽样验证。
先列出旧URL清单，再决定保留、跳转还是返回410
没有完整旧URL清单，死链检查就无从谈起。可以从服务器访问日志、CDN日志、站点地图、CMS导出记录中汇总历史地址，并标注每个地址的流量、外链和转化价值。处理方案通常分两种：一是保留原路径并直接返回200；二是用301跳转到语义最接近的新页面。若旧页面已彻底下线且无替代内容，可返回410，明确告知搜索引擎该地址已永久移除。
判断条件：有稳定外链或历史流量的旧地址，优先301到内容最接近的新页；仅内部测试、从未公开的地址，可不必保留。若把大量无关旧URL统一跳转到首页，容易被判定为软404，用户也找不到所需内容，这属于需要重点核对的错误。
核对跳转链与状态码，避免多跳和错误指向
迁移后常见问题是A跳B、B再跳C，形成跳转链。每多一跳都会增加抓取成本，也可能在中间环节丢失参数。核对时应逐条记录：旧URL、最终URL、状态码、跳转次数。理想情况是旧URL直接301到最终页，中间不经过其他跳转。
同时要区分301与302。301表示永久迁移，适合改版换址；302表示临时跳转，不适合长期替代。若把永久迁移写成302，搜索引擎可能继续保留旧地址，新地址权重传递也会受影响。还要检查跳转目标是否返回200，若目标页本身是404，等于死链没有修好。
robots.txt、站点地图与死链检查的关系
robots.txt用于限制抓取，不等于可靠的索引移除。若旧URL已在robots中屏蔽，搜索引擎可能无法看到该地址的301，从而无法及时更新索引。站点地图也不保证收录，它只是提交可抓取地址的辅助方式。迁移时应核对：站点地图是否只包含最终可访问的200页面；旧URL是否仍出现在站点地图中；robots规则是否误挡住了需要传递跳转的旧路径。
若使用HTTPS，也不能把HTTPS等同于安全无漏洞或排名保证。它只是迁移中的一个协议变化，仍需单独检查证书链、混合内容与跳转是否从HTTP正确指向HTTPS。
从交付结果倒推责任与验收
死链检查的交付结果应是一份可验证的对照表，至少包含旧URL、处理方式、新URL、状态码、负责人、验收日期。责任划分建议：开发负责配置跳转和状态码；内容或SEO负责确认跳转目标语义对应；运维负责日志与监控；测试负责上线后抽样。
验收时可执行以下步骤：
- 抽取旧URL清单中流量最高的前50条，逐条访问，记录状态码和最终地址。
- 用爬虫工具或脚本批量检查，筛选出404、410、302、跳转链超过两跳的地址。
- 对每一条异常地址，确认是配置遗漏、目标页缺失，还是本应返回410。
- 修复后重新跑一遍，直到高价值旧URL全部返回200或一跳301到200。
适用条件：若站点规模很小，可人工抽查；若URL数量上千，应先用日志筛出有流量的地址，再批量验证。判断结果时，重点看高价值地址是否全部通过，而不是只看全站404总数是否为零。
上线后继续监控，而不是一次性检查
迁移完成后，外链、用户收藏和搜索引擎索引不会立刻全部更新。应在接下来几周内持续查看服务器日志中的404来源，并核对搜索引擎抓取统计。若发现新的死链，按同样流程补跳转或返回410。下一步可以先把旧URL清单和跳转对照表建立起来，再逐条验证状态码，避免只凭感觉判断迁移是否成功。
