站点换域名、把 http 换成 https、把主站从子目录搬到独立域名，都会碰到同一件事：旧地址已经在索引里，新地址还没有。这段过渡期最怕两件事——旧地址继续被抓取端当成有效页面，新地址迟迟进不了索引；或者两边都在，同一份内容在索引里挂着两套地址。
迁移不是一次性动作，而是一个按顺序推进的过程。下面这几步的先后关系，往往比每一步做得多精细更重要。
先把旧地址和新地址的对应关系列成一张表
动手改配置之前，先从一个完整的 URL 清单开始。来源可以是站点地图、服务器访问日志、搜索后台的索引报告，取并集去重。
- 能一对一对应的页面：旧地址 → 新地址。
- 已经下架、不打算保留的页面：标注为不再提供，而不是随手指到首页。
- 带参数的地址、大小写变体、结尾斜杠变体：先归一，再进映射表。
- 确实没有对应页面的分类页、标签页、筛选地址：单独列出来，决定是保留还是收口。
这张表决定了后面 301、canonical、内链到底指向哪里。表没整理好，后面每一步都会带着错误往下传。
301 是主力，别用 JS 跳转或 meta refresh 顶替
服务器层的 301 是迁移里最可靠的信号，它明确表达“这个地址永久换了地方”。常见的替代做法各有问题：
- JS 跳转：抓取端要先执行脚本才知道去哪，等于多了一道不确定性，迁移期容易原地卡住。
- meta refresh：信号弱于 301，也不带永久迁移的含义。
- 302 / 307：表达的是临时跳转，长期挂着会让旧地址一直被视为有效。
如果新旧站由不同系统承载，优先在旧站这一层做 301，不要指望新站自己把流量接过去。
重定向要一步到位，别铺成长链
迁移时最容易出现的链条是：旧 http 地址 → 旧 https 地址 → 新域名 http → 新域名 https。每多一跳，抓取端要花的成本就多一分，判断最终地址的时间也往后拖。
做法是让所有历史形态的地址都直接跳到最终唯一的目标地址，一条链路只走一步。改完之后抽一批地址实测，跟着跳转走一遍，确认最后一跳落在正确的页面上，而不是落在 404 或者首页。
canonical、内链和站点地图要一起更新
301 只解决“从旧地址到新地址”的问题，页面自身的信号还得同步换过去。否则索引可能已经记着新地址，页面里的自指 canonical 却还写着旧域名，两边互相矛盾。
- 页面内的 canonical 改成新域名下的自身地址。
- 站点地图重新生成，只放新域名下可访问的地址。
- 站内链接全量替换为新域名，避免正文和导航里还留着旧地址。
- 如果旧站还在线，不要在旧站里继续加新内容。
这几项的顺序是先改页面信号，再提交新站点地图。反过来的话，新地图里的地址在抓取时还会被 canonical 指回旧域名。
旧地址不要保留可访问的副本
有些迁移为了“过渡稳妥”，把旧站原样保留着，只在入口加一层 301。问题在于，只要旧地址还能返回完整页面，它就依然可能被当成独立有效地址反复抓取。更稳的做法是旧站只保留跳转能力，内容不再对外提供。
如果个别页面确实下架不保留，返回 404 或 410 比统一指到首页更合适。把大量失效地址都指到首页，会让首页收到一批无意义的信号。
迁移期的回查顺序
- 抽查一批旧地址，确认状态码和最终落点符合映射表。
- 抽查新地址，确认自指 canonical 和页面内链接都是新域名。
- 看站点地图是否只包含新域名地址，提交后观察抓取进展。
- 在索引报告里对比新旧地址的出现情况，重点关注两套地址同时存在的页面。
迁移期不要一边改一边删旧站。顺序是：映射表整理完 → 新站内容可访问 → 301 上线 → 页面信号更新 → 旧站收口。中间任何一步没做完就进入下一步，后面的回查都会变得很难判断。
整个过程里，判断标准不是旧地址掉了多少，而是最终地址是否稳定、可达、信号一致。映射清晰、跳转干净、信号统一，索引里的地址替换通常只是时间问题；反过来，映射含糊或者链条过长，等待期会被拉长，而且不容易看出卡在哪一步。