换域名、改目录结构、把 http 升级为 https，这类操作在搜索引擎看来都是“一批 URL 集体换了位置”。很多人以为配好 301 就结束了，实际上跳转只解决了访问该去哪，页面能不能继续被发现、被抓取、被编入索引，还要看后面几个环节有没有跟上。
跳转只是第一步，链路上还有别的环节
一条 URL 从被发现到重新出现在索引里，大致要经过：内链或其他入口指向它、爬虫抓取到新地址、新地址返回正常状态码并渲染出内容、索引里逐步用新地址替代旧地址。301 只解决了“旧地址有人访问时去哪”这一个问题，其余环节任何一处断掉，都会表现为“跳转没问题，但收录迟迟不回来”。
迁移前：把 URL 映射表做扎实
一对一映射优先于批量兜底
最省事的做法是把所有旧 URL 统一跳到首页，这在收录层面代价很大：原本有独立价值的页面会集体失去落点。更稳的做法是先导出站内被抓取和已收录的 URL 清单，逐条给出新地址，形成映射表。
- 能一对一的，尽量不合并；确实要合并的，合并到主题最接近的页面，而不是首页。
- 旧地址已经完全没意义的（例如过期活动页、失效商品页），让它返回 410 或 404 比乱跳更清楚。
- 大小写、带参数、带尾斜杠的变体，在迁移前先收敛，避免把老问题一起搬过去。
避免跳转链和伪跳转
旧地址 A 跳到 B、B 又跳到 C，这种链式跳转会让爬虫在中间多走几步。另外用 meta refresh 或 JS 做的跳转，对爬虫来说不等于 301，很容易被当成页面内容而不是跳转指令。
跳转链条越长，到达目标页的损耗越大，也越容易被中途放弃。
迁移中：让新旧两套体系保持一致
迁移期最怕的是内部信号互相打架：内链指向旧地址、canonical 写着旧域名、sitemap 里新旧混在一起。只要这些地方不一致，爬虫就需要花额外时间判断哪个版本才是你想要的。
需要同步检查的位置
- 站内导航、面包屑、列表页与正文里的内链，尽量替换为新地址。
- sitemap 只保留新地址，并更新其中的时间标记。
- canonical 指向新地址自身，不要再指向旧域名。
- robots.txt 里声明的 sitemap 地址、站点地图索引文件，一并更新。
- 如果有 hreflang、分页 rel 或 RSS，其中的 URL 也要跟着换。
迁移后：用日志和抽样验证效果
迁移完成后，收录的变化通常不是一瞬间发生的，会出现一段新旧并存期。判断是否正常，比盯着 site 指令更可靠的办法是看服务器日志：
- 新域名下爬虫访问量是否在缓慢上升，而不是只在迁移当天来一波。
- 旧域名收到的请求里，301 命中比例是否在逐步下降。
- 是否有大量 404、5xx，或者本该跳转的地址返回了 200 但内容为空。
- 抓取是否落在你希望保留的页面上，而不是被参数页、失效页占满。
再抽一小批迁移前有稳定访问的 URL，逐条检查：打开是否落到正确页面、状态码是否符合预期、canonical 是否自指、内链是否已更新。抽样几十条通常就能发现系统性问题。
几个常见的误判
第一，把“跳转生效”当成“收录完成”，其实索引替换还需要时间。第二，迁移后旧站仍可访问，又希望新站被优先收录，结果两套内容长期并存。第三，看到收录数下降就急着大改，实际上迁移后的波动属于正常过程，应该先看日志和状态码，再决定要不要调整。
迁移的难点不在技术动作本身，而在于旧结构留下的痕迹太多。把映射、内链、sitemap、跳转这几处保持同一口径，剩下的就是按节奏观察，不必用额外手段去催。