先想清楚这次改的是什么
域名更换、目录结构重排、URL 规则变化、协议或 www 前缀切换，这几类改动的处理方式并不一样。比较稳妥的做法是先给这次迁移定性：是整体换址，还是局部调整？影响的是全站地址，还是某个栏目下的页面？把范围写清楚之后再动手，能避免很多漏网的地址。
最麻烦的情况是几件事叠在一起做，比如一边换域名，一边改 URL 规则，同时还调整了栏目结构。这时排查问题时很难判断是哪一步出的错，建议拆开分批推进。
迁移前的准备：把旧地址盘清楚
旧 URL 清单从哪来
- 站内 sitemap 里列出的地址
- 服务器访问日志中出现过的真实访问路径
- 站内链接抓取结果，包括导航、列表页、相关推荐
- 外部平台导出的入站链接清单
只看 sitemap 通常会漏掉一批历史页面，尤其是早期做过调整、后来又没更新的那些地址。日志和站内链接能补上这部分缺口。
建立一对一映射表
- 内容对应的页面互相映射，语义接近的优先配对
- 已经确定删除的页面，单独列出，不要硬塞给首页
- 多个旧地址合并到一个新地址时，只保留一个最终去向
把成批的旧地址统一跳转到首页，对用户和蜘蛛来说都等于“这个页面已经不存在了”，同时首页还会收到一堆内容不相关的信号，得不偿失。
跳转怎么写才不添乱
用 301，尽量一跳到位
跳转链条越长，中间损耗越多。A 跳到 B，B 再跳到 C 这种结构，既让用户多等一次，也让蜘蛛多走一趟。能在配置里直接指向最终地址，就不要保留中间环节。
不要用 302 长期顶替
临时跳转适合短期的灰度或活动，但如果它长期存在，蜘蛛会持续把旧地址当作有效地址来看待，不利于地址的交接。
旧域名和证书别急着放掉
旧域名继续解析、证书继续覆盖、服务器继续返回 301，这个状态建议维持较长时间。中断之后，从旧地址进来的访问会直接进死胡同。
站内自己先改干净
- 导航、面包屑、正文内链里的地址是否已换新
- canonical 是否指向新地址，而不是旧地址
- sitemap 是否已替换，旧地图是否已下线或更新
- 结构化数据、分享卡片、RSS 里的地址是否同步
如果站内链接还指着旧地址，等于每一次点击都要多走一次跳转，蜘蛛发现新地址的速度也会被拖慢。
上线前后的核对
上线前
- 预发布环境确认禁止抓取，或者至少与正式环境隔离
- 检查配置和模板里有没有硬编码的测试域名
- 确认 robots 规则没有顺手把新站整站挡住
上线后
- 抽查一批代表性地址，看跳转是否落到正确页面
- 在访问日志里盯 404 和 5xx 的变化，而不是只看总量
- 观察新地址的抓取情况是否逐步起来
- 确认 sitemap 里提交的地址都能正常打开
迁移后的抓取和索引波动是常见现象，重点看趋势和错误类型，不要因为某一天的数字起伏就急着改规则。
几个容易漏掉的细节
- 地址的大小写和结尾斜杠是否保持统一
- 带参数的旧地址是否也在映射表里
- 图片、样式、脚本等静态资源是否还挂在旧域名上
- 邮件模板、二维码、外部合作页面里写死的链接
这些地方不直接影响主页面，但会在日志里留下大量混杂的请求，给后续排查添麻烦。
把过渡期当成正常阶段
迁移不是一次切换动作，而是一段需要盯着的过渡期。映射表留档、日志定期看、旧域名维持解析，这几件事做到位，地址交接基本就不会出大问题。至于新地址多久被重新抓取、页面何时恢复原有的表现，取决于站点自身情况，能做的是把可控的环节先做对。