SEO 迁移清单之所以存在，是因为损害都发生在安静的环节。新服务器能工作，页面能加载，三周后展现量却掉了，没人说得清是哪一步出了故障。大多数情况下，是四种完全不报错的故障之一。
我们自 2017 年起就在不同主机之间迁移网站，其中天问网络的一个项目一次性把 49 个外贸网站从托管主机搬到了自建 VPS。域名相同，服务器不同，总成本下降了一半以上。下面是如果换成别人自己动手，我们会交给他的那份清单。
首先，说清你做的是哪种迁移
每次迁移的风险并不相同，方案里应当写明这次属于哪一种。
- 换主机。域名相同、URL 相同，只换服务器。风险最低。主要危险是 DNS 生效时间、邮件，以及仍在提供旧站内容的缓存。
- 换域名。风险最高。每个 URL 都会变，每条外链都指向别处，你需要在 Search Console 里做地址更改。
- 换平台。重建 CMS 通常会同时改变 URL 规则和页面模板，即使外观设计照搬也一样。
- 改 URL 结构。增加或去掉语言前缀、把 http 换成 https、改变结尾斜杠或目录层级。即使内容和服务器都不动，这也是一次迁移。
动手前先确定类别，因为它决定了后面哪些步骤是必须做的，哪些只是良好习惯。
迁移前：冻结、盘点、留基线
基线是最容易被人跳过、事后又后悔的部分，因为没有它你就无法判断某个变化是不是迁移造成的。从 Search Console 导出最近 16 个月的数据：查询词、页面、国家、设备。保存当前的 sitemap 并统计 URL 数量。记录哪些页面承载着你在意的展现量。
对文件和数据库做完整备份，并在环境还在眼前时把配置记下来——PHP 版本、数据库版本、启用的插件及其版本、cron 条目、邮件配置。这份清单是你新环境要对照重建的目标，也是回滚时的参照。
然后在切换前 24 小时冻结发布。迁移过程中发布的文章可能只进了旧数据库，这会让你莫名其妙地搭进去一个下午。
还有一项也属于这里。如果网站把备份副本放在网站根目录内，迁移前先清掉。我们曾在某个主题目录里发现 36 个 .backup 文件，全都可以被公开下载。迁移正是停止把它们再发布到新服务器的自然时机。
URL 映射表就是迁移本身
如果换域名或 URL 规则变了，从旧 URL 到新 URL 的映射就是最重要的一份产物。切换前用表格把它做出来，每个旧 URL 一行，且只有一个目标地址。能保持不变的 URL 就保持不变——迁移后最安全的 URL 就是从未变过的那个。
必须改变的 URL，用一次 301 直接跳到最终目标。两三次跳转的链条会浪费抓取预算、稀释信号。永久迁移不要用 302。注意那些会让映射出错的细节：结尾斜杠、大写字母、分页和筛选 URL 上的查询字符串，以及带 www 和不带 www 的形式。Google 关于迁移网站并更改 URL的指南很短，做映射前值得读一遍。
先清缓存，再测跳转
这是我们栽过的坑。缓存返回的 200 不算通过测试。如果服务器缓存或 CDN 还存着旧响应，所有检查都会通过，而每个用户看到的仍是旧站。先清服务器缓存和 CDN，然后再测。
用脚本测整份清单，而不是抽查五个 URL。跟随跳转，记录每一跳的最终 URL 和状态码。你要的输出是一张表：每个旧 URL 都一跳到达预期目标，最后返回 200。
四种静默出错的故障
这些都不会报错。每一种都让我们或客户白白搭进过时间。
1. 被冻结的 sitemap 文件
有些 SEO 插件把 sitemap 缓存成文件，在定时器到期前一直提供这个文件。后台界面显示绿色对勾，但它提供的文件已经好几周没更新；文件名里往往不含 “sitemap” 字符串，在文件系统里搜也搜不到。解决办法是迁移后删掉缓存文件让它重建，然后在 Search Console 里确认 sitemap 的下载日期和 URL 数量是最新的。别信插件的对勾，去读时间戳。
2. 没跟着搬过来的 cron
换主机会重建环境，定时任务很容易被落下。如果配置里禁用了 WP-Cron，又没有系统 cron 接手，定时文章就会永远停在“已定时”状态，而且没有任何提示。验证方法很简单：安排一篇一分钟后发布的测试文章，看它会不会发出去。
3. Canonical 和 hreflang 还指向旧 URL
在多语言网站上，这些标签是自动生成的，而生成的标签在迁移后可能又生成旧 URL。逐个语言版本检查 canonical 是否自指、hreflang 是否互指，并确认集合里每个 URL 都返回 200。Google 关于多地区网站的文档具体说明了这些标签必须如何配对。
4. 不再收到的表单和邮件
即使网站本身没问题，DNS 和邮件记录也是迁移的一部分。换域名时，表单可能提交成功却发不到任何地方。换主机时，如果网站通过另一个地址访问，绑定域名的反垃圾密钥可能不再通过验证。我们审计过一个站，它的表单已经静默失败了 12 天，因为 reCAPTCHA 密钥注册在另一个域名下；在有人发现之前，已有 207 次付费点击落到上面。用手机发一条真实的测试消息并确认收到，迁移后发一次，一周后再发一次。
DNS、TTL 和证书
至少在切换前 24 小时把 DNS TTL 降到几分钟，让切换能快速生效。在新服务器验证通过、TTL 完全过期之前，让旧服务器继续运行并保持在线。不要在切换当天就取消旧主机；它是你的回滚方案。
切换前先在新主机上签发 TLS 证书，并提前决定用哪个主机名作为规范名。然后让其他形式都跳转到它。服务器位置对国际定向来说是个很弱的信号——Google 看的是域名、hreflang 设置和内容本身，而 CDN 让位置几乎无关紧要——所以不要让选哪个机房的决定压过迁移方案。
迁移后：按固定顺序验证
下面的顺序能按故障原本会让你措手不及的先后次序抓住它们。
- 每个映射 URL 的 HTTP 状态。一跳、目标正确、最后返回 200。
- robots.txt 和 sitemap。确认两者都能加载，然后在 Search Console 里检查 sitemap 的真实下载日期并重新提交。
- Canonical 和 hreflang。自指、互指、全部返回 200。
- 渲染。JavaScript、CSS 和字体都能加载；移动端布局和原来一致。
- 速度。测量重要页面的首字节时间。换主机是修复基础设施故障最省钱的时机——在我们其中一个站上，给 nginx 加一层缓存把 TTFB 从 2.14 秒降到 0.067 秒。
- 表单和邮件。用手机发一条测试消息到收件箱，然后再检查垃圾邮件文件夹。
- 如果换了域名，在 Search Console 里做地址更改。这是必须步骤，不是可选项。
做好重新抓取会延迟的准备，别指望立刻恢复
迁移后的抓取关注度并不均衡，它既取决于网站的历史，也取决于新服务器。2026 年 9 月 22 日，我们在同一台机器上检查了自己名下的三个站点。其中一个首页前一天刚被抓取过，那一周发布的页面已经收录。另一个上次抓取是十天前，sitemap 是十四天前，期间发布的三个新页面 Google 还不知道——“Google 无法识别此 URL”。同一台服务器、同一天，结果却不同。
所以不要在第三天就给迁移下结论。用四到六周观察两个数字：按 URL 类型分的收录率，以及新主机的抓取统计。如果收录率在下降而跳转映射没问题，先去找意外的 noindex、robots.txt 屏蔽，或指向旧域名的 canonical，再动别的。如果收录率持平且跳转都能解析，那迁移就是成功的；剩下的只是让页面被重新抓取的常规工作。
真正会坏的是什么，多久能看出来？
可见症状出现的次序相当一致。几个小时内，跳转或证书问题会以报错的形式暴露。一天内，邮件和表单会现形，通常是因为有人没收到消息。一周内，随着抓取在新主机上稳定下来，sitemap 和 canonical 的故障开始产生影响。收录和展现量的变化最慢，而人们最先慌的恰恰是它们。
所以这条时间线就是把清单倒过来读。先修立刻会坏的东西，再盯需要几周才显现的东西。如果跳转报错和一点点展现量下滑出现在同一个早上，它们不是同一件事，把它们当成一件事，正是团队开始同时改动三个变量的开端。
回滚通道保留 30 天
至少保留一个月的旧服务器、旧 DNS 记录和迁移前的数据库。在切换前就把回滚命令写好，而不是等第一声警报之后。如果收录率崩了，一天内又找不到原因，把 DNS 指回去是正当操作，而把路径提前写下来，能让它成为一个决定，而不是一场慌乱。
关于新主机的配置，有一条我们付出代价才学到的经验。一台单核 1 GB 的机器跑三个 WordPress 站不稳定，原因不是站点数量，而是 PHP 内存上限被设成了 1024 MB——比这台机器的内存还大。把它改成 256 MB，并把 PHP worker 从 6 个减到 4 个，就恢复正常了。单个 PHP 进程实测占用 80–124 MB，所以这种账很容易往宽松的方向算错。
一页版清单
| 阶段 | 必须做 | 证明它做到了的验证 |
|---|---|---|
| 迁移前 | 导出基线、完整备份、环境清单、冻结发布 | 基线文件带日期并存放在服务器之外 |
| 迁移前 | URL 映射表，每个旧 URL 一个目标 | 每一行都有目标地址和状态 |
| 迁移中 | 调低 TTL、签发证书、保持旧服务器在线 | 切换前证书已在新主机上生效 |
| 迁移后 | 清缓存，然后端到端测试跳转 | 脚本验证一跳 301 直达最终 200 |
| 迁移后 | 重建 sitemap 缓存，核实真实下载日期 | Search Console 显示今天的日期和正确的数量 |
| 迁移后 | Canonical、hreflang、表单、邮件 | 测试消息已收到；标签自指 |
| 迁移后 | 如果换了域名就做地址更改 | Search Console 确认提交成功 |
| 四周后 | 收录率和抓取统计与基线对比 | 按 URL 类型分的收录率持平或上升 |
每一项背后的规律都一样：配置看起来没问题，网站行为却不对。要验证结果，而不是设置。迁移后浮现的收录问题，和我们检查普通网站时问的是同一批——见12 点审计和我们对自己归档站做的收录测试。两者都收在研究索引里。
关于 SEO 迁移的问题
最重要的一步迁移是什么？
只要有 URL 变化，就是 URL 映射表。每个旧 URL 一行，且只有一个最终目标，在切换前做好。能保持不变的 URL 就保持不变。其次，在测试跳转前先清缓存，这是能抓住最多静默故障的一步。
换主机后排名为什么掉了？
常见原因有：跳转解析错误、sitemap 仍在提供缓存文件、canonical 或 hreflang 标签用旧 URL 重新生成、表单或邮件线路停止投递。症状出现的时点很有帮助：报错在几小时内出现，邮件在一天内，收录问题要几周。
迁移后要多久才能恢复？
抓取关注度并不均衡，取决于网站的历史。在同一台服务器、同一天，我们见过一个首页前一天刚被抓取、新页面已收录，另一个上次抓取是十天前、新页面 Google 还不知道。用四到六周盯收录率。
切换后应该马上取消旧主机吗？
不应该。至少保留 30 天的旧服务器、旧 DNS 记录和迁移前的数据库。如果收录率崩了，一天内又找不到原因，把 DNS 指回去是正当操作，而写好的回滚路径能让它成为一个决定，而不是一场慌乱。
本文作者及核实方式。作者刘宇，天问网络创始人（河南天问网络科技有限公司，2017 年 5 月 3 日注册；中国郑州；UTC+8）。天问网络自 2017 年起为 B2B 制造商搭建并维护 WordPress 外贸网站、做 Google SEO，目前维护 30–40 个客户站点以及自己的研究域名。本页每个数字都来自我们运营的站点实测，或链接到它的出处。我们不承诺排名或询盘数量。联系方式：WhatsApp +86 135 2681 6415。
本页由英文版机器翻译，尚待人工审核。
