不改网址的网站托管迁移指南

💡 核心摘要：不改 URL 的托管迁移看似只是换服务器或接入 CDN，但仍会影响 Google 抓取。正确流程是先复制并测试新环境，确认 Googlebot 能访问，提前降低 DNS TTL，迁移当天移除测试拦截并更新 DNS，之后同时监控新旧服务器日志，等旧环境流量归零后再关闭。

一、先确认迁移类型

这篇 Google 文档只适用于“不影响用户可见 URL”的托管基础架构迁移，例如更换托管服务提供商、迁移到新服务器，或把网站接入内容分发网络 CDN。

如果迁移会改变域名、路径、协议、子域名或 URL 结构，就不是这条流程。那种情况应按“更改网址的网站迁移”处理，需要 URL 映射、重定向、Sitemap 和更完整的迁移监控。

⚠️ 不要把“换服务器”和“换 URL”混在一起执行。两类迁移的 SEO 风险和操作清单不同。

二、先复制并测试新环境

迁移开始前，应先把网站副本部署到新的托管基础架构上。这个副本可能是静态文件、CMS 数据库导入、应用容器、对象存储资源、CDN 源站配置或后端服务组合。

测试不能只看首页。要打开核心页面、图片、表单、下载文件、登录流程、搜索页、产品页和多语言页面，确认新环境返回内容完整、资源可访问、模板没有缺失。

测试清单

页面：主页、栏目页、详情页、旧内容页
资源：图片、CSS、JS、PDF、视频封面
交互：表单、登录、站内搜索、下载
状态：200、404、重定向、canonical、noindex
性能：首字节、超时、CDN 回源、缓存命中

💡 如果使用临时主机名公开测试，例如 beta.example.com，要给测试站添加 noindex，避免被意外编入索引。

三、确认 Googlebot 能访问

新环境上线前，要确认 Googlebot 可以访问 DNS、服务器、CDN、WAF 和页面资源。很多迁移事故不是内容没搬过去，而是防火墙、DoS 防护、地域规则或安全策略误伤了 Googlebot。

如果使用临时主机名测试，可以在 Search Console 验证这个资源，然后用网址检查工具测试 Googlebot 能否访问新基础架构。正式域名迁移后，也要继续抽查核心 URL。

⚠️ 不要只用自己的浏览器测试。浏览器能访问，不代表 Googlebot 没被 WAF、IP 规则或安全插件拦截。

四、提前降低 DNS TTL

DNS 记录通常会被 ISP 和递归解析器缓存。迁移前提前降低 TTL，可以让 DNS 更新更快传播，减少一部分用户和抓取请求继续落到旧基础架构的时间。

Google 建议在迁移前至少提前一周，把 TTL 调整为较低但保守的值，例如几个小时。不要等迁移当天才改 TTL，因为旧缓存可能仍按原 TTL 生效。

迁移前 DNS 检查

dig example.com
dig www.example.com

💡 TTL 不是越低越好。目标是让迁移窗口更可控，同时避免给 DNS 解析和运维监控带来不必要波动。

五、保留 Search Console 验证

托管迁移后，Search Console 的所有权验证必须继续有效。如果你使用 HTML 文件验证，要把验证文件复制到新网站副本里。

如果验证方式依赖 CMS 模板里的 meta 标记，或依赖 Google Analytics 相关代码，也要确认新 CMS、主题模板和构建流程没有遗漏这些标记。迁移后失去验证，会影响你及时查看抓取和索引信号。

💡 上线前把验证文件和验证标记列入发布检查项，不要迁移后才发现 Search Console 资源失效。

六、迁移当天移除测试拦截

为了防止测试站被索引，很多团队会在新环境使用 robots.txt 全站屏蔽、noindex meta 标记、HTTP X-Robots-Tag: noindex 或 IP 访问限制。

正式开始迁移前，必须移除这些会阻止抓取或索引的临时拦截。随后更新 DNS 记录，让域名指向新的托管服务、CDN 或源站。具体操作应按 DNS 提供商和托管平台文档执行。

上线前抽查

curl -I https://example.com/
curl -I https://example.com/robots.txt

⚠️ 最常见的迁移事故之一，是新环境上线后仍保留测试阶段的 noindex 或 robots 屏蔽。

七、同时监控新旧流量

DNS 传播需要时间。迁移刚开始时，你会看到旧服务器仍有访问流量，新服务器访问逐步上升。这是正常现象，不应过早关闭旧环境。

监控时要同时看新旧服务器日志、CDN 日志、错误率、Googlebot 请求、5xx、超时、抓取频率和 Search Console 报告。也可以使用不同公共 DNS 检查工具，确认多个地区和 ISP 是否已解析到新基础架构。

💡 正常情况下，Googlebot 抓取速度可能先短暂下降，再在几天内稳步恢复，甚至高于迁移前。

八、最后再关闭旧基础架构

只有当旧服务提供商的服务器日志显示访问流量归零，并且你确认用户和 Googlebot 都能从新基础架构正常接收内容时，才关闭旧环境。

关闭前还应保留一段回滚窗口，确保 DNS、CDN、缓存、证书、表单、下载、图片和核心页面都稳定。对大型网站，建议把旧环境至少保留到主要 DNS 缓存完全过期之后。

⚠️ 不要因为新环境“看起来可用”就立即关停旧服务器。仍有用户、ISP 或抓取请求可能命中旧地址。

📌 核心收获

• ✓ 本流程只适用于 URL 不变：更改 URL 时要走单独的网站迁移流程。
• ✓ 新环境要先测试完整：页面、资源、表单、下载、状态码和性能都要检查。
• ✓ Googlebot 访问必须验证：防火墙、WAF、DoS 防护和 CDN 规则都可能误拦。
• ✓ TTL 要提前降低：至少提前一周调整，迁移当天才改通常太晚。
• ✓ 上线前移除测试拦截：robots 屏蔽、noindex 和 IP 限制都要复查。
• ✓ 旧环境等流量归零再关：同时监控新旧日志和 Search Console 数据。

🚀 立刻行动

1. 判断本次迁移是否保持 URL 完全不变；如果会改域名或路径，改用 URL 迁移流程。
2. 在新托管环境部署完整副本，逐项测试页面、资源、表单、下载、状态码和缓存。
3. 用 Search Console 网址检查工具测试 Googlebot 是否能访问新环境或临时主机名。
4. 迁移前至少一周降低 DNS TTL，并记录当前 DNS、CDN、证书和回源配置。
5. 上线前删除测试阶段的 robots.txt 屏蔽、noindex、IP 限制和临时认证。
6. 更新 DNS 后同时监控新旧服务器日志、Googlebot 请求、错误率和 Search Console 报告。
7. 等旧基础架构访问流量归零，并完成核心 URL 抽查后，再关闭旧服务器或旧托管服务。

来源：更改网站托管和搜索引擎优化 | 本文为知识提炼与重新表达