改版、换域名、调整目录结构，这类操作在规划阶段常被当成设计或开发任务，真正容易出问题的部分却在迁移细节上。页面能不能打开是一回事，搜索引擎和用户能不能顺着原来的路径找到新地址，是另一回事。
改版前先盘清家底
动手之前，至少要有一份旧站的完整视图。缺了这一步，后面做映射时只能靠记忆和猜测。
- URL 清单：从服务器日志、sitemap、站内链接中汇总全站可访问地址，去重后统计总量。
- 流量分布：哪些页面带来了大部分自然搜索访问，哪些几乎没人看，重定向的优先级并不相同。
- 外部链接：被外部引用的页面尽量保持地址不变，或者做长期有效的跳转。
- 索引基线：记录各目录大致的收录量级，作为上线后的对照参照。
- 技术配置：robots.txt、sitemap、结构化数据、规范链接、CDN 与缓存规则，逐项列出来。
URL 映射表是迁移的核心
新站上线之后，旧地址必须能找到新地址。映射表不是给开发看的草稿，而是要在上线前完成评审的正式清单。
- 按模块逐个对应，能一对一就一对一，能保持不变的尽量不变。
- 确实合并或删除的页面，跳转到最接近的上级栏目或替代页，不要全部丢到首页。
- 跳转使用 301，避免多次跳转串联，一条链路上不要超过一次。
- 跳转规则写成可维护的配置文件或数据表，别散落在各处代码里。
- 上线后用脚本抽检，随机抽查几百条旧 URL，确认返回状态和最终落地页都正确。
上线顺序同样关键
不少人习惯一上线就同时替换 robots.txt、sitemap 和全站链接，结果一旦出问题，很难判断是哪一步引起的。
- 先在测试环境验证，确认新站可正常抓取，没有被误屏蔽的目录。
- 上线时保持旧站跳转可用，至少保留一个完整的观察周期。
- sitemap 更新为新地址，提交后观察抓取情况，再逐步清理旧记录。
- robots.txt 的改动放在最后，确认无误后再放开抓取限制。
上线后要盯的几组数据
- 服务器日志中新旧地址的访问比例，以及 301 命中量是否在缓慢下降。
- 抓取错误和 404 的数量变化，尤其注意原栏目下的路径。
- 核心页面的索引与展示情况，与改版前的基线做对比。
- 页面加载时间、TTFB 等基础指标，改版容易顺带引入性能回退。
观察建议以周为单位，短期波动属于正常现象，重点看趋势是否稳定，而不是盯着某一天的数字下结论。
常被忽略的几个细节
改版不只是换个外观，地址、链接、跳转、索引这些看不见的部分，往往比视觉变化影响更持久。
- 站内链和导航仍指向旧地址，靠跳转兜底，白白浪费一跳。
- 绝对地址里写死了旧域名，出现在图片、CSS、JS 或接口调用中。
- sitemap 里还混着旧域名，或者包含大量重定向地址。
- 移动端与桌面端使用了不同的跳转规则，同一页面出现两条链路。
- 备份文件被放进站点根目录，结果被外部访问到。
准备一个能落地的回滚方案
再充分的准备也可能遇到意外。回滚方案要写清楚触发条件、执行人、操作步骤和时间窗口，并尽量在上线前实际演练一次。保留旧站的可访问版本一段时间，是比较稳妥的做法。
改版本身没有错，问题在于把迁移当成收尾工作。提前把清单列出来，按步骤执行并记录结果，整个过程会可控得多，出现异常时也能更快定位原因。