换域名、改目录结构、从 http 换成 https、把站点从一台服务器搬到另一台——这些在运营里都算“迁移”。操作本身不难，难的是搬完之后，老地址还能不能把用户和蜘蛛顺利带到新地址。

迁移前：先把资产清单列清楚

动手改 DNS 之前，先花半天把站点上真正有价值的东西盘点一遍。这一步偷懒，后面就要靠日志一点点补。

• 入口清单：首页、栏目页、内容页、专题页各有多少，哪些是主要流量来源。
• 地址清单：从站点地图、服务器日志、后台数据库各导一份 URL 列表。三份对不上很正常，对不上的部分往往就是容易漏掉的部分。
• 外链清单：找出被外部引用最多的页面，这些地址迁移后必须能正常打开。
• 资源清单：图片、CSS、JS、字体、接口域名。很多“页面打开是空白”，其实是资源路径没跟着换。
• 索引相关文件：站点地图和 robots.txt 要在迁移当天一起更新，别只改站内链接。

迁移执行：重定向尽量一对一

老地址到新地址的 301 映射表，最理想的状态是一对一。最怕的是把所有老页面统一跳到首页：用户点进来发现不是自己要找的内容，蜘蛛也会认为这个地址和内容对不上。

• 能一对一的就一对一；确实没有对应内容的，再退而求其次跳到最接近的栏目页。
• 别用 302 代替 301，也别让跳转跳完再跳一次。链条越长，用户和蜘蛛的耐心掉得越快。
• 目录级迁移可以用规则批量处理，但一定要抽查几条，确认规则没把不该动的地址也卷进去。
• 迁移期间先别急着上大批新内容，让蜘蛛先把搬家这件事处理完。

新旧地址对照表要留档

把映射表存成 CSV，放进版本管理或共享文档里。以后排查“某个老链接为什么跳错了”，有这张表就不用靠猜。

迁移后：用日志和工具验证

• 翻服务器日志里老地址的响应码：如果还是 200，说明重定向压根没生效；如果是 404，说明漏配了。
• 观察新地址的抓取量，通常需要几天到几周才会逐步起来，不用一两天没动静就慌。
• 抽查典型页面：图片是否正常、表单能否提交、https 下是否还有混合内容告警。
• 检查站内链接，看看还有多少指向老域名，能改的尽早改。

几处容易被忽略的细节

• 邮件、App 推送、印在物料上的老域名，短期改不了，重定向就得一直保留着。
• 备案、证书、CDN 回源配置要跟着域名一起更新，漏一个就可能出现访问异常。
• 提前准备好回滚方案：DNS 改回去要多久，迁移前的文件和数据库备份放在哪。
• 别把迁移和改版安排在同一时间做。两件事叠在一起，出了问题很难判断是谁的锅。

迁移不是一次操作，而是一段观察期。留出两到四周，盯日志、盯索引、盯错误率，再宣布搬家完成。