如何迁移域名而不让搜索排名下滑

更换域名是少数几个 SEO 项目之一：一个技术上很小的错误，可能很快变得非常显眼。一个缺失的重定向、一条被阻断的抓取路径，或一个被遗忘的 canonical，都可能把一次简单的品牌更名变成数周的排名波动。

一些波动是正常的。搜索引擎需要时间来抓取旧 URL、发现重定向、处理信号，并将新域名稳定地纳入索引。目标不是避免每一次下滑。目标是让迁移变得平淡：一个旧 URL 指向一个等价的新 URL，服务器清晰响应，重要内容不消失。

从清单开始，而不是从重定向规则开始

最常见的迁移失败，是把它当成服务器配置任务。它不是。它是一个信息架构任务，只是最终会落到服务器配置上。

在触碰 DNS 之前，先建立一份重要 URL 清单：

• 获得自然搜索流量的 URL
• 带有外部反向链接的 URL
• 能转化、产生线索或支持营销活动的 URL
• 当前 XML sitemap 中的 canonical URL
• 被外部链接引用的 PDFs、图片和可下载文件
• 可能不出现在当前导航中的高价值历史 URL

为每个旧 URL 指定新域名上的目标地址。在大多数情况下，这个目标应当是意图相同的同一页面。如果 /pricing 变成 https://newdomain.com/pricing，这很简单。如果三个旧产品页面被合并成一个新指南，请有意识地记录这个决定。

避免偷懒的模式：把所有内容都重定向到新首页。这很方便，但会丢掉相关性。搜索引擎和用户都期望目标页面能回答原始 URL 所对应的同一个需求。

尽可能保留 URL 结构

当路径保持稳定时，域名迁移会更容易。从 oldsite.com/blog/example 迁移到 newsite.com/blog/example，比同时更换域名、CMS、slug、文件夹结构和内容要干净得多。

有时重新设计或 CMS 迁移会让 URL 变更不可避免。如果是这样，请把决策拆开：

1. 哪些变化是因为域名变化？
2. 哪些变化是因为站点结构变化？
3. 哪些内容会被删除、合并或重写？

你引入的变量越多，之后诊断问题就越难。如果这次迁移很重要，而当前站点表现良好，可以考虑先迁移域名，之后再重新设计。

使用永久、单跳重定向

对于真正的域名迁移，应使用服务器端 301 或 308 重定向，将旧 URL 指向其新的等价 URL。临时重定向适用于临时场景。JavaScript 重定向、meta refresh 和软重定向信号更弱，也更容易出问题。

你的重定向目标很简单：

• 每个重要旧 URL 都返回永久重定向。
• 每次重定向都直接到达最终目标。
• HTTP 干净地重定向到 HTTPS。
• www 和 non-www 变体处理一致。
• 除非必要，重定向不依赖脆弱的查询字符串行为。

一个糟糕的链路如下：

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

它最终也许会落到正确页面，但速度慢、更难抓取，也更容易掩盖错误。目标是让每个旧变体都以一跳到达最终新 URL。

验证行为时，请检查实际 HTTP 响应，而不是相信浏览器显示的结果。我们的指南 在生产环境中调试重定向和 HTTP headers 的小工具包 在这里很有用，因为浏览器太“礼貌”了：它们会跟随链路，并隐藏混乱的部分。

上线前准备 DNS 和证书

DNS 不会直接转移排名，但糟糕的 DNS 会让迁移看起来像是坏掉了。在上线窗口前降低 TTL 值，让变更传播更可预测。确认新域名拥有用于 Web 流量、电子邮件以及任何必需子域名的正确记录。

你还需要为两个域名准备有效的 TLS 证书。这一点很容易被忽视。迁移后，旧域名仍然需要提供 HTTPS 重定向。如果它的证书过期，用户和爬虫可能在到达新站点之前就遇到浏览器警告。

如果迁移影响电子邮件，不要把它当成事后补充。域名变化经常会破坏 SPF、DKIM、DMARC、MX 记录、跟踪链接和事务性邮件。想复习相关记录，可查看我们面向开发者的指南：MX、SPF、DKIM 和 DMARC。

检查 canonicals、内部链接和 sitemaps

上线后，新域名的表现应当像它一直都是内容的 canonical 归属地一样。

这意味着：

• Canonical 标签指向新 URL，而不是旧域名。
• 内部链接使用新域名或根相对路径。
• XML sitemaps 只包含最终、可索引的新 URL。
• hreflang 注解（如果使用）引用新 URL。
• Open Graph、结构化数据和 alternate 链接已更新。
• Robots.txt 不阻止重要部分。

不要发布一份充满旧 URL 的 sitemap，然后期待重定向来清理它。sitemap 应该是一份你希望被索引的 URL 列表。迁移后，这意味着新域名上的最终 URL。

还要注意 canonical 矛盾。一个页面从旧域名重定向到新域名，但 canonical 又指回旧域名，会发送混合信号。搜索引擎通常能处理一些不一致，但你不应该要求它们这样做。

不要在上线当天改变一切

迁移本身已经是足够大的事件。如果可能，避免把它与大规模内容删减、模板重写、导航变化、JavaScript 渲染变化或新的性能特征合并在一起。

这不是迷信。这是调试纪律。如果上线后排名下降，你需要知道原因是重定向映射、抓取访问、内容变化、渲染变慢、结构化数据缺失，还是其他因素。

让初始上线尽可能接近旧站点。等新域名稳定后，再以较小批次进行更大的编辑和设计改动。

告诉搜索引擎发生了什么变化

在 Google Search Console 中验证旧域名和新域名。然后，当迁移是域名级别变更且内容正在迁移到新域名时，使用 Change of Address 工具。上线后提交新的 sitemap。

这不能替代重定向。它是对重定向的支持。搜索引擎仍然需要可抓取、持久的重定向，才能理解 URL 级别的映射。

对于 Bing 和其他搜索引擎，在可用时使用它们的站长工具。也要更新你能控制的位置：社交资料、商家列表、广告目标地址、邮件页脚、文档、合作伙伴链接，以及联合发布内容中的 canonical 引用。

外部链接不会全部被更新，这没关系。但最重要的那些应该更新。如果某个主要合作伙伴、应用市场、文档门户或媒体页面链接到旧域名，请请求他们更新。

上线后监控正确的事项

迁移后的前几天应该主动监控，而不是庆祝。

检查：

• 旧域名和新域名上的服务器日志抓取活动
• 404 和意外的 5xx 错误
• 重定向链和循环
• Search Console 中的索引状态
• Sitemap 发现和处理情况
• 自然搜索着陆页和查询模式
• 依赖旧 URL 的转化路径
• Analytics 过滤器和引荐排除设置

预期会有报告噪音。有些分析工具如果配置不当，会把新域名视为一个新属性。有些仪表板会把旧域名流量与新域名流量直接比较，让迁移看起来比实际更糟。

搜索可见度可能会波动几周。你不希望看到的情况是，高价值旧 URL 被反复抓取但没有正确重定向，或者新页面被发现却被标记为旧域名的重复页面。

性能也不应被忽视。如果新域名上线时使用了更重的模板、损坏的缓存或未优化的资源，用户可能会把迁移感受为变慢。如果你在检查中使用 Lighthouse，请带着优先级来阅读；我们的文章 如何阅读 Lighthouse 报告而不恐慌 解释了如何区分有意义的问题和噪音。

长期保留旧域名

不要在迁移“生效”后让旧域名过期。尽可能长时间地保持注册、保持证书有效，并保持重定向运行。实践中，这通常意味着多年。

旧链接会继续存在于博客文章、书签、文档、PDFs、电子邮件和社交帖子中。重定向是历史足迹与新域名之间的桥梁。过早关闭它们会破坏用户路径，并浪费累积的信号。

也要保留一份重定向映射和上线记录。六个月后，当有人问为什么某个历史 URL 会有特定行为时，你会庆幸自己做了记录。

<!-- tool-cta:start -->

💡 试试这个： 切换完成后，通过 Redirect Checker 跟踪你的旧 URL，以确认每个旧 URL 都只经过一次 301 跳转就解析到正确的新页面。

<!-- tool-cta:end -->

一份合理的迁移检查清单

上线前：

• 在 Search Console 中验证两个域名。
• 抓取当前站点并导出重要 URL。
• 建立一对一重定向映射。
• 降低 DNS TTL。
• 为旧域名和新域名准备 TLS 证书。
• 更新 canonicals、内部链接、hreflang、结构化数据和 sitemaps。
• 在 staging 或受控环境中测试重定向。

上线当天：

• 部署重定向。
• 确认 HTTP 到 HTTPS 的行为。
• 从每种模板类型中抽样测试重要 URL。
• 提交新的 sitemap。
• 在适当时使用 Change of Address 工具。
• 关注服务器错误、重定向循环和被阻止的资源。

上线后：

• 监控抓取错误和索引报告。
• 在可行时更新重要外部链接。
• 按着陆页意图比较流量，而不只是比较域名总量。
• 无限期保持重定向在线。
• 等迁移稳定后，再进行无关的重新设计或内容实验。

域名迁移并非没有风险，但它是可管理的。排名通常是在迁移发送不清晰信号时受损：缺失的重定向、变化的内容、矛盾的 canonicals、被阻止的爬虫，或被遗忘的旧域名。给搜索引擎和用户一张清晰的地图，迁移就会少很多戏剧性。