先分清是哪一类改版
换域名、调路径、切协议、合并栏目，表面上都叫“URL 变了”，实际要处理的问题并不一样。先归类，再决定映射策略，能省掉后面很多返工。
- 换域名：整站 URL 前缀变化，需要全量对应，一对一是底线。
- 路径调整：比如 /news/123 变成 /article/123，通常能做规则批量映射。
- 协议或 www 切换：同一内容换了前缀，重点在统一出口，别让两种写法长期并存。
- 栏目合并：多个旧地址指向一个新地址，属于多对一，要挑最相关的那一个作为落点。
把这四类分开列，后面写重定向规则时不容易漏。混在一起处理，规则很容易互相覆盖。
迁移前先把两边的 URL 清单对齐
很多人直接从旧站导出 sitemap 就开始写规则，结果漏掉的往往是 sitemap 里本来就没收录的那批页面——参数页、带尾斜杠的地址、大小写混用的链接。更稳的做法是几个来源交叉：站点地图、服务器日志里被真实访问过的路径、站内链接抓取结果。
然后把旧地址和新地址做成一张对应表，逐条确认。表里至少要标清楚三件事：旧 URL、新 URL、以及这是不是一对多。凡是暂时找不到对应页面的，宁可让它返回 404，也不要先随便指到首页。
301 要一对一，整站跳首页是常见误区
把大量旧 URL 统统重定向到首页，短期看不出问题，长期会让搜索引擎把这些旧地址判成“软 404”一类的结果——目标页和原页面主题对不上，信号也就传不过去。首页也承受不了成百上千个不相关地址的集中指向。
判断标准很简单：用户从搜索结果点进来，看到的内容是否和标题里承诺的接近。差得越远，这次重定向的价值就越低。
如果确实有页面在新站不存在了，直接让它返回 410 或 404 更干净，比硬塞一个不相关的落点要好。
内链和站点地图要跟着一起改
只加服务器重定向、不动站内链接，等于一边告诉搜索引擎“旧地址作废”，一边又继续在站内给它投票。常见的遗漏点包括：
- 文章正文里指向旧地址的超链接
- 导航、面包屑、侧栏推荐位里的写死路径
- 分页、标签页、作者页这类由模板生成的链接
- 站点地图里仍然保留的旧 URL 条目
- canonical、结构化数据里的 URL 字段
这些位置用全站搜索过一遍再上线，比上线后靠日志发现问题快得多。顺带提醒一句：canonical 指向的应该是新地址，如果它和重定向目标不一致，反而会制造新的混乱。
迁移期间盯哪几组数据
改版上线不等于迁移完成，接下来一段时间要看的是替换进度，而不是某一天的收录数字。
- 服务器日志：旧 URL 的抓取是否在减少、返回码是不是稳定的 301；新 URL 的抓取量是否在上升。
- 索引状态：新旧地址在索引里的替换情况，重点看旧地址有没有长期停留。
- 落地页表现：搜索来源的落地页是否已经换成新地址，有没有出现明显断档。
这三组数据要放在一起看。只看索引报告容易得出“还没开始迁移”的结论，其实日志里旧地址的抓取可能早就降下来了。
几个容易踩的坑
- 链式重定向：A 跳到 B、B 又跳到 C，多跳一层就多一次损耗，规则要一次到位。
- 长期用 302：永久性改版就该用 301，302 更像是临时安排。
- 重定向目标本身也失效：跳过去是 404，等于白跳，上线前要逐条验证返回码。
- 一次改太多：URL 结构、模板、内容结构同时大改，出问题时很难定位是哪一步造成的。
重定向什么时候能撤
没有必须撤掉的时间点。只要旧地址还有外部链接指向、还有用户从旧书签或搜索结果进来，保留重定向就是划算的——它的维护成本很低，撤掉之后要恢复却几乎没有办法。与其纠结撤不撤，不如定期检查这些规则有没有继续指向有效页面。