网站迁移真正麻烦的地方，往往不在技术动作本身，而在于迁移前后那些零碎细节是否都被照顾到。换域名、改目录结构、从 HTTP 迁到 HTTPS、把站点搬到新服务器，这些操作都会让原本已经建立起来的抓取路径发生变化。蜘蛛之前记住的是一套地址，迁移之后它面对的可能是另一套，中间如果没有做好衔接，之前积累的链接关系、抓取频率和收录结果都会出现一段明显的回落。
下面这份清单按迁移前、迁移中、迁移后三个阶段整理，适合在动手之前逐条过一遍。
迁移前：先把现状盘清楚
迁移前最重要的工作是留档。不少人迁移完成后才发现，旧站的 URL 结构没有完整记录，日志也被覆盖，想比对都无从下手。
- 导出完整 URL 清单：从站点地图、抓取日志、后台内容列表三个来源各导一份，取并集，避免遗漏只有外链没有内链的页面。
- 记录当前状态码分布：哪些页面返回 200，哪些本来就该是 301，哪些本来就该是 404。迁移后要能对照检查。
- 保存近期抓取日志：迁移前两周的日志能反映蜘蛛真实的抓取节奏和高频页面，是迁移后判断是否恢复正常的基准。
- 标出高价值页面：把流量集中、外链较多的页面单独列出来，迁移后优先复核这些地址。
新旧 URL 映射：尽量做到一对一
映射表是迁移的核心。最省事但也最伤站的做法，是把旧站所有地址统一 301 到新站首页。这种做法等于把大批页面合并成一个，原本分散在各页的链接关系会一起堆到首页，其余页面要重新被重新发现一轮，恢复周期会被明显拉长。
映射表要满足的几个基本要求
- 尽量一对一，旧页面 A 指向新页面 A，而不是全部指向首页或栏目页。
- 目标地址直接写最终地址，不要 A 到 B 再到 C 这样串联，减少连锁跳转。
- 页面确实下线的，指向最相关的上级分类或有替代关系的内容；完全没有替代的，老老实实返回 404，不要用状态码 200 的空页面糊弄过去。
- 映射表做完后批量抽查，用工具验证状态码，而不是靠肉眼核对几行。
迁移过程中容易漏掉的几处
- robots.txt：新站上线时常常沿用了测试环境的配置，里面写着全站禁止抓取。上线后第一件事就是确认这份文件是给正式环境用的。
- 站点地图：sitemap 里的地址必须换成新域名，并且能正常返回 200。旧域名的 sitemap 可以保留一段时间，但内容要指向新地址。
- canonical 标签：模板里的 canonical 如果是写死的旧域名，迁移后会指向一个已经跳转的地址，等于自我否定。
- 内链与相对路径：检查站内链接用的是绝对地址还是相对地址，绝对地址需要整体替换。
- HTTPS 与证书：如果迁移同时涉及协议变更，确保证书覆盖新旧域名，页面里没有混合内容，否则蜘蛛在握手阶段就会止步。
- CDN 与缓存：迁移后缓存里可能还存着旧版本页面，必要时主动刷新，避免蜘蛛抓到过期内容。
迁移后：验证与观察期
迁移完成不等于结束，接下来两到四周是观察期，重点看三件事。
- 状态码抽查：随机抽几批新旧地址，确认 301 落点正确，没有出现 302 混用、循环跳转或跳到 404 的情况。
- 抓取日志：观察蜘蛛访问的地址是否逐渐转向新域名，旧地址的访问量是否在下降，新地址是否开始出现稳定的抓取频率。
- 站内搜索与外链：站内搜索入口要更新为新地址；外部链接无法直接控制，但可以主动联系几个重要的合作站点更新链接。
迁移期间出现波动是正常现象，关键是波动之后能不能回到原来的水平。如果四周后抓取量仍明显低于迁移前，就要回头检查映射表和 robots 是否还有遗留问题。
一份简化的动手顺序
- 导出旧站 URL 清单并留档近期日志。
- 制作一对一映射表并批量验证落点。
- 在新环境完成服务器、证书、缓存、CDN 的准备。
- 选一个低流量时段切换，同时更新 robots 与 sitemap。
- 切换后立刻抽查状态码，逐项复核 canonical、内链和入口配置。
- 进入观察期，按周比对日志与抓取数据。
迁移这件事没有太多技巧，靠的是把每一步都做完整。清单越长，事后临时想起来补的可能就越少。