换域名、加 www、从 http 迁到 https，这类操作在站点运营里很常见。不少人以为把 301 配好，索引里的旧地址就会自动换成新地址。实际过程更像一次地址簿的替换：蜘蛛需要重新发现新地址、重新抓取，再判断两个地址指向的是不是同一个页面，中间会有新旧并存的阶段。

一、先把新旧 URL 的映射关系列出来

跳转规则写得再漂亮，如果映射本身是乱的，结果也是乱的。迁移前建议先导出一份当前被访问、被链接的 URL 清单，逐条确认它应该去往哪个新地址，形成尽量一对一的关系。

• 列表页、详情页这类有规律的 URL，可以用规则批量映射，但规则要覆盖到分页、筛选参数等边界情况。
• 首页、栏目页、临时活动页这类没有规律的 URL，逐条登记，别指望规则自动兜住。
• 只被站内链接引用、外部没有入口的页面同样要照顾到，它们也是蜘蛛曾经走过的路径。
• 已经下架、本来就不该出现在索引里的旧地址，让它返回 404 或 410，而不是硬塞一个跳转。

二、跳转本身要干净

跳转是这次迁移里最容易做错的一环，常见问题有几类：

• 跳转链太长：旧地址跳到中间地址，再跳到最终地址，甚至跳三四次。链条越长，越容易在某一环被中断，后续判断落点也更麻烦。
• 用 JS 或 meta refresh 代替 301：这些方式对用户可用，但对蜘蛛来说信号弱得多，不如服务端直接返回 301 来得明确。
• 把临时跳转当永久跳转用：302、307 表达的是“暂时”，长期使用会让旧地址的去留变得含糊。
• 把不相关的页面互相跳：为了保住旧地址的表现，把 A 页面跳到完全不相关的 B 页面，用户和蜘蛛都会被绕晕。

目标其实很简单：旧地址收到请求后，用一次 301 指向新地址，新地址返回 200。

三、让新地址自己站得住

跳转只解决“从旧到新”这一段。新地址能不能被稳定收录，还要看它自身的信号是否一致。

• 站内链接全部改为指向新地址，不要继续链向旧域名；内部链接还指着旧地址，等于在告诉蜘蛛旧地址仍然重要。
• canonical、sitemap、RSS、结构化数据里的 URL 一并更新，避免同一个页面出现两套地址。
• 提交新域名的 sitemap，旧 sitemap 可以保留一段时间，但内容要逐步收敛到新地址。
• 确认没有遗留的 robots.txt 规则、访问限制或安全策略，把新域名的抓取挡在门外。

四、旧域名别急着关

迁移完成后立刻停掉旧域名，是很容易踩的坑。旧地址上的跳转需要继续存在一段时间，因为在迁移之前就已经存在的链接、收藏和外部引用，不会因为你换了域名就同步更新，蜘蛛也需要时间把旧地址重新走一遍。

另一个方向相反的坑是：为了“让旧站彻底退出”，把旧域名整个用 robots.txt 屏蔽，或者干脆让它解析失败。这样做的结果是蜘蛛读不到跳转，也就无法把旧地址和新地址关联起来，索引替换反而会更慢。

旧域名在过渡期的作用是“指路”，不是“继续运营”。跳转保留到旧地址的访问量明显下降之后，再考虑下线。

五、观察重点放在“替换”而不是“数量”

迁移期的索引数据会有波动，盯着总收录数涨跌很容易误判。更有意义的观察方式是把注意力放在具体地址上：

• 抽样一批新地址，看它们是否已经能被抓取、是否进入索引。
• 抽样一批旧地址，看返回的是不是 301，落点是不是预期的新地址。
• 看新域名的抓取量是否在逐步上升，而不是只有首页被反复访问。
• 借助后台的索引状态报告，确认新地址是否被识别为规范地址。

整个替换过程通常以周为单位推进，站点规模、外链结构、旧地址数量都会影响节奏。与其追求“一次换干净”，不如保证每一步都是确定的：映射清楚、跳转干净、信号一致、旧地址保留到位。

如果迁移一段时间后，新地址被抓取却迟迟不进入索引，或者旧地址长期停留在索引里，可以回头检查两件事：跳转是否真的返回 301，以及新地址上是否存在重复内容或质量问题。这两个方向排查完，多数情况能找到线索。