死链优化，改版或迁移时应核对什么
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /409a171bafa9.html
📄
死链优化，改版或迁移时应核对什么
改版或迁移时做死链优化，核对重点不是“有没有404”，而是三件事：旧URL是否被完整记录、每个旧URL是否有了明确的去向、新站是否让搜索引擎和用户都能顺利到达这个去向。缺少任何一项，原本能正常访问的页面都可能在改版后变成死链，已经积累的入口价值随之流失。
先核对旧URL清单是否完整
死链优化的第一步是拿到完整的旧URL集合，而不是凭记忆挑几个重要页面。可以从这些来源汇总：
- 服务器访问日志中的历史请求路径
- 旧站可抓取的内部链接和导航结构
- 已提交或已存在的站点地图文件
- 外部链接工具或站长平台中显示的被链向URL
核对时要注意带参数的URL、大小写不同的URL、带与不带结尾斜杠的URL是否被当成不同地址。如果旧站有分页、筛选、打印页等功能性URL，也要判断它们是否值得保留去向。清单不完整，后面的跳转规则就会漏掉大量真实入口。
再核对每个旧URL的去向是否成立
有了清单后，逐个确认旧URL映射到的新地址。常见去向有三类，适用条件不同：
- 内容仍存在：跳到新站中主题最接近的页面，优先一对一，避免全部指向首页。
- 内容已合并：跳到合并后的目标页，并确认目标页确实覆盖了旧页的核心信息。
- 内容已下线且无替代：返回410或保留404，不要为了消灭404而跳到无关页面。
这里要区分“可能原因”和“已经定位的原因”。某个旧URL返回404，可能是跳转规则没写、规则写错、目标页本身又失效，也可能是服务器配置未生效。不要看到404就断定是某一种原因，应逐项验证。
核对跳转实现方式与生效范围
跳转应尽量使用服务器端的301重定向，让搜索引擎把旧URL的权重和用户请求一起导向新地址。核对时检查：
- 重定向是否返回301而非302或JS跳转
- 是否形成A跳B、B又跳C的跳转链
- 是否出现循环跳转
- 目标页是否返回200
- 大小写、斜杠、参数版本是否都覆盖到
可以用命令行工具逐个请求旧URL，查看响应状态和Location头。也可以写一段脚本批量检查清单中的URL。判断结果是：状态码为301且Location指向预期新页，才算通过；返回200说明跳转没生效，返回404说明规则缺失，返回302则要确认是否只是临时安排。
核对搜索引擎与用户两侧的可达性
跳转正确不代表搜索引擎一定能发现新地址。需要分别核查：
- 新站是否允许抓取，
robots.txt是否误封了重要目录 - 站点地图是否更新为新URL，但站点地图不保证收录，只能作为发现渠道之一
- 旧站站点地图是否还指向已失效地址
- 新站内部链接是否还有指向旧URL的残留
- 用户从搜索结果、外部链接、书签进入时是否都能到达有效页面
注意，robots.txt的抓取限制不等于可靠的索引移除，它只阻止抓取，不保证旧页面从索引中消失。HTTPS也不保证安全无漏洞或排名提升，它只是传输层的基本要求。不同搜索引擎对跳转和索引的处理方式需要分别核查，不能用一个平台的结果推断全部。
改版迁移后的持续核对步骤
迁移完成后，按下面的顺序执行一轮检查：
- 导出旧URL清单，标记每个URL的预期去向。
- 批量请求旧URL，记录状态码和最终落地页。
- 把实际落地页与预期去向比对，列出不一致项。
- 修正跳转规则，再跑一遍批量检查。
- 在新站抓取一轮，确认没有新的内部死链。
- 过一段时间后复查日志，看是否还有旧URL返回404。
适用条件是：你已经完成或即将完成改版迁移，且旧站有可获取的URL记录。如果旧站已经无法访问、日志也已丢失，就只能从外部链接和搜索引擎索引中尽量还原，覆盖范围会受限，这时更要优先保证已知高价值入口的去向正确。
下一步建议先导出旧URL清单，做一次批量状态检查，把返回404或302的旧URL单独列出来，再决定每一条是补跳转、改目标页还是保留404。
