站点换域名、把 /product/ 改成 /p/、把带参数的动态地址改成静态路径，这些动作在开发侧可能几天就完成了，但对搜索引擎来说，看到的是成千上万个旧地址突然失效、一批新地址凭空出现。收录能不能顺利迁移，主要取决于一件事：新旧 URL 的对应关系是否清晰、稳定、可长期维持。

先把映射表做出来，再动线上

很多迁移事故的根源是边改边想。比较稳妥的做法是先导出一份旧 URL 清单（sitemap、服务器日志、索引报告里都能拿到），然后逐条标注处理方式：

• 保留：URL 不变，只是内容更新。
• 迁移：内容搬到新地址，旧地址 301 到新地址。
• 合并：多个旧地址内容相似，统一指向一个新地址，形成多对一。
• 下线：确实不再提供，返回 410 或 404，不要硬跳到首页。

映射表的价值在于它能在上线前被检查：有没有同一个新地址被几十个旧地址指向、有没有旧地址跳到了完全不相关的页面、有没有新地址在表里出现两次但对应内容不同。

跳转怎么设：301 是默认答案，但要用对

永久迁移用 301，临时调整用 302 或 307，这一点没有争议。真正容易出问题的是跳转的形态：

• 避免链式跳转：旧地址 A 跳到 B，B 又跳到 C，蜘蛛要多走一步，信号也被稀释。映射表里应直接写成 A 到 C。
• 不要全站跳首页：把失效的深层页面统一 301 到首页，对用户和搜索引擎都等于「这个页面没了」，还可能被当成软 404 处理。
• 跳转目标要相关：商品下架就跳到同类目列表，而不是全站首页，用户和蜘蛛都更容易理解。
• 跨域要确认解析与证书：HTTPS 证书、DNS、CDN 配置没到位时跳转可能中断，蜘蛛抓到的是错误页而不是 301。

站内信号要一起改

跳转只是兜底，真正决定新 URL 能不能被顺利接管的，是站内还有多少地方指向旧地址：

• 全站内链和导航，尤其是硬编码在模板里的绝对地址。
• sitemap 要换成新地址，并在迁移后重新提交。
• canonical、hreflang、og:url 以及结构化数据里的 URL。
• RSS、站内搜索、分页组件、面包屑、分享按钮带的链接。

如果这些还停留在旧地址，就会出现「新 URL 已经在跳转链条末端，站内所有入口却还指向旧 URL」的局面，新地址很难积累到足够的抓取和点击。

容易漏掉的几类地址

下面这些往往不在 sitemap 里，但确实会被访问，迁移时最容易被忘：

1. 图片、PDF、附件的直链，常被外部页面引用。
2. CSS、JS 里写死的资源或接口路径。
3. 结构化数据、站点验证文件、广告落地页里的 URL。
4. App 深链、二维码、邮件模板、线下物料上的短链。
5. 外部网站上的旧链接，这部分你控制不了，只能靠 301 兜住。

分批迁移还是整体切换

整体切换的优点是映射关系简单，缺点是一旦出错影响面大。分批迁移（比如按目录或按语言站点切分）可以在小范围内验证跳转、日志和收录反应，再逐步推广。无论选哪种，都建议保留旧域名或旧路径的可访问状态至少几个月，并且不要在同一时间做跳转、大改版和内容重写三件事。

迁移之后看什么

迁移完成不等于结束，接下来几周要盯的是过程指标而不是结果指标：

• 日志里新 URL 的抓取量是否逐步上升，旧 URL 是否逐步下降。
• 跳转是否稳定返回 301，有没有出现 5xx 或超时。
• 索引报告里新 URL 的数量变化，以及旧 URL 是否在减少。

如果旧 URL 的抓取量一直不降、新 URL 迟迟没有抓取，通常说明站内入口或外链还没跟上，而不是搜索引擎没发现这些地址。

收录迁移的本质不是把旧地址改掉，而是让新地址在链接、sitemap、日志三个层面都被稳定地看见。