改版或换域名，是收录最容易出问题的动作之一。原因不复杂：搜索引擎手里存的还是旧 URL，你得把“旧地址”一点点换成“新地址”，而且要让抓取、索引、内链这几条线同时跟上。任何一条没交接好，收录就会出现回落、变慢，或者新旧地址混着都存在的情况。
先分清迁移中同时发生的三件事
很多人把迁移当成“换个域名”一步操作，其实它至少包含三层变化：
- URL 变了：旧 URL 全部失效，需要被重新发现，并给出明确的新地址。
- 抓取路径变了：蜘蛛要重新爬新站，新站的 robots、状态码、内链深度都会影响它能爬多快。
- 索引要重建：新 URL 需要重新走一遍评估流程，旧 URL 的索引要先退出，再被替换。
把这三件事混在一起看，就容易得出“换了域名收录就掉”的结论。实际上掉的是旧 URL 的索引，新 URL 还没补上来，中间的空档期本身是正常的。
迁移前：先收敛旧站，再决定搬什么
搬家前把旧站整理一遍，比搬完再救要省力得多。
- 确定新 URL 规则：尽量做到一个旧 URL 对应一个新 URL，路径结构不要大改。层级、目录名、大小写、结尾斜杠都提前定死，避免同一页面在新站产生多个变体。
- 筛选要搬的 URL：旧站里的参数页、会话 ID 页、搜索结果页、空列表页，本来就没必要进索引，迁移时可以直接返回 410，不必一起带过去。
- 检查新站能不能被抓：robots.txt、登录墙、IP 白名单、CDN 拦截，这些在测试环境很常见，上线后忘了关，蜘蛛来了就什么都拿不到。
迁移顺序：从“能被发现”到“能替代旧页”
顺序比速度重要，可以参考下面的推进节奏：
- 先让 301 生效：旧 URL 到新 URL 一一对应，返回真正的 301，而不是 JS 跳转或 meta refresh。跳转链尽量只有一跳。
- 再提交新站 sitemap：sitemap 管的是发现，不是收录，但迁移阶段它能帮蜘蛛更快知道新 URL 的存在。
- 然后切内链：导航、面包屑、相关推荐、正文里的站内链接，都改成新 URL。外链改不了没关系，内链是自己能控制的。
- 最后确认页面级信号：canonical、hreflang、移动版指向，都要同步换成新域名，不要出现 canonical 还指着旧站的情况。
- 旧站保留一段时间：301 保持有效，直到旧 URL 的抓取量明显下降、新 URL 的索引基本稳定，再考虑关停。
几个反复出现的坑
- 全站 301 到首页：这相当于主动放弃已有内容，蜘蛛只能从首页重新发现每个页面，非常慢，也容易被当成软 404 处理。
- 新旧域名同时可访问：两边都返回 200、内容一样，信号被分散，还容易形成重复内容。要么 301，要么明确 canonical，不要“留着看看”。
- 只换域名不改内链：蜘蛛从旧页面进来，发现内链还指向旧 URL，就要反复走 301，抓取效率被白白浪费。
- URL 变体没收敛：带参数、大小写差异、斜杠有无，这三类最容易在迁移时批量产生。迁完后做一次抽样对比，确认每个旧 URL 只指向一个新地址。
迁移期间不要只盯着 site 查询的数字。更值得看的是：旧 URL 的 301 命中量有没有下降，新 URL 有没有被稳定抓取，以及新老页面是否成对出现。这几个指标比一个总数更能说明交接有没有完成。
迁移后怎么观察和收尾
迁移完成后的一段时间，重点看三件事：抓取是否稳定落到新站、新 URL 的索引是否逐步建立、旧 URL 是否在减少。如果新站抓取正常但索引一直不上来，回到内容层面看页面质量，而不是继续加提交入口；如果旧 URL 长时间不退出，检查是不是还被内链或 sitemap 指向。
最后提醒一点：迁移不是一个动作，而是一段交接期。把顺序做对、把 URL 收敛干净、把该关的入口关掉，收录的恢复通常只是时间问题；反过来，顺序做错，后面补救的成本会高很多。