Google 6月17日文档更新解读：网站换域名，不能只迁移“看得见的主站”

6月17日，Google Search Central 更新了网站迁移指南。

这次更新讲的是一个很具体的细节：网站换域名时，在 Search Console 使用 Change of Address 工具，不应该只处理一个主域名，还要处理所有相关的域名变体，包括 www、非 www，以及其他子域名。

这句话看起来很技术，但它对应的是网站迁移中很常见的损失来源。

很多网站迁移后，排名、收录、点击、图片流量、品牌搜索结果恢复得很慢，不一定是 Google 没有识别新站，也不一定是新站内容不好，而是旧站的迁移关系没有交代完整。

旧域名过去不只是一个首页，也不只是一个当前正在使用的版本。它可能还包括：

www 版本，非 www 版本，HTTP 版本，HTTPS 版本，语言子域名，博客子域名，移动端子域名，历史落地页，图片资源地址，PDF 文件地址。

这些地址只要曾经被 Google 抓取过、被外部链接指向过、被用户访问过，就可能还留有搜索信号。

网站换域名时，如果只迁移当前主站，忽略这些历史版本和子域名，迁移就容易不完整。

一句话说清楚这次更新：

网站迁移不是把一个域名换成另一个域名，而是把旧站所有重要地址关系，尽量清楚地转交给新站。

---

为什么 Google 要强调 domain variants？

很多人做网站迁移时，会默认认为：

“我的网站现在只用 example.com，那我只迁移 example.com 就可以了。”

但从搜索引擎角度看，事情没有这么简单。

example.com 和 www.example.com，在用户眼里可能是同一个网站，但在技术上它们是不同主机名。www 本身就是一个子域名。

如果一个网站过去同时存在过 www 和非 www 版本，或者历史上没有严格统一重定向，那么两个版本都有可能被 Google 抓取，也都有可能积累外部链接。

比如，有些外链指向：

www.oldsite.com

有些外链指向：

oldsite.com

有些老文章、目录、展会页面、客户案例、PDF 文件里，可能还保留着早期的 URL。

如果迁移时只处理 oldsite.com，却忽略 www.oldsite.com，那么指向 www 版本的历史链接、旧页面、旧索引记录，就可能没有被顺畅迁移到新站。

这就是 Google 这次强调 domain variants 的原因。

它不是在增加一个复杂规则，而是在提醒站长：迁移要覆盖完整，不要只迁移当前最常用的那个版本。

---

Change of Address 工具不是重定向的替代品

这里要先讲清楚 Change of Address 工具的作用。

它不是用来做跳转的。

真正把旧 URL 跳到新 URL 的，仍然是服务器端 301 或 308 永久重定向。

Change of Address 工具的作用，是在你已经完成迁移和重定向之后，通过 Search Console 明确告诉 Google：这个网站已经从旧域名迁移到了新域名。

它更像是一个迁移声明，而不是迁移本身。

所以，正确顺序应该是：

先准备新站。
再做好旧 URL 到新 URL 的对应关系。
然后配置永久重定向。
确认 Googlebot 可以访问这些重定向。
最后再使用 Change of Address 工具提交迁移。

如果没有做好 301 重定向，只提交 Change of Address，迁移不会稳。

如果旧站还返回大量 200 页面，Google 也很难确认这些内容是否真的永久移动了。

网站迁移的核心仍然是 URL 级别的清晰对应关系，而不是只在工具里点一下“换地址”。

---

www 和非 www 不是小事

很多企业网站在早期建站时，www 和非 www 经常没有处理干净。

有的网站两个版本都能打开。
有的网站 HTTP 和 HTTPS 都能访问。
有的网站首页会跳转，但内页没有跳。
有的网站 canonical 写的是一个版本，站内链接却是另一个版本。
有的网站 sitemap 提交了非 www，外链却大量指向 www。

平时这些问题可能不明显，因为 Google 会自己判断 canonical，也会根据重定向和页面内容做规范化处理。

但迁移时，这些历史问题会被放大。

因为迁移不是普通抓取，而是旧站和新站之间的信号交接。

旧 URL 要告诉 Google：我已经永久搬到新 URL。
旧域名要告诉 Google：这个站点已经迁移到新域名。
旧站的内部链接、canonical、sitemap、hreflang、外部链接，也要尽量指向同一个方向。

如果这些信号互相矛盾，Google 需要花更多时间判断。

所以，www 和非 www 不是“形式问题”，而是迁移信号是否一致的问题。

---

这次更新真正提醒的是：别漏掉旧站历史

很多迁移问题，出在“只看当前网站”，没有看旧站历史。

比如一个外贸独立站，现在主站是：

https://example.com

但过去几年里，可能还使用过：

https://www.example.com
http://example.com
http://www.example.com
https://en.example.com
https://blog.example.com
https://m.example.com

这些版本现在可能已经不出现在导航里，也可能后台已经不用了，但它们未必完全没有价值。

有些历史页面可能仍有外链。
有些旧文章可能仍有自然搜索点击。
有些图片可能仍在 Google Images 中展示。
有些 PDF 产品资料可能仍被客户访问。
有些旧语言站可能仍被某些国家用户搜索到。

如果迁移时直接关掉这些子域名，或者只让它们跳到新站首页，搜索信号就容易损失。

更好的做法，是把旧站历史尽量查清楚，再决定每一类旧地址应该迁移到哪里。

有价值的旧页面，应该尽量跳到对应的新页面。
已经合并的旧内容，可以跳到最相关的新页面。
确实没有替代价值的旧页面，可以返回 404 或 410。
不要把大量旧 URL 全部粗暴跳到新首页。

首页跳首页，不能代替整站迁移。

---

外贸独立站为什么更容易踩这个坑？

外贸独立站经常会经历域名调整。

比如品牌升级，旧域名换新域名；从产品词域名换成品牌域名；从临时站迁移到正式站；从旧 CMS 迁移到 WordPress；多语言站从子域名改成子目录；或者把多个站点合并成一个品牌站。

这些动作都可能涉及域名迁移。

外贸站还有一个特点：历史资产比较分散。

有些链接来自 B2B 平台资料页。
有些来自展会页面。
有些来自老客户网站。
有些来自行业目录。
有些来自社交媒体主页。
有些来自 PDF 产品目录。
有些来自不同语言版本。
有些来自早期博客子域名。

这些入口不一定都指向当前主域名。

如果迁移时只处理新旧主域名，不处理历史子域名和 www 版本，就容易漏掉过去积累的部分搜索信号。

所以外贸站换域名之前，不能只让建站人员把网站搬过去，还要让 SEO 参与旧站资产盘点。

这个盘点不是为了把流程做复杂，而是为了减少迁移后的不确定性。

---

迁移前最重要的是做一张“旧地址关系图”

很多迁移项目一开始就急着上线新站，这是不稳妥的。

更好的做法，是先把旧站的地址关系梳理出来。

你需要知道：旧站到底有哪些版本，哪些还可以访问，哪些被 Google 收录过，哪些有外链，哪些有点击，哪些只是历史遗留。

这张图不一定复杂，但必须回答几个问题：

旧站有没有 www 和非 www 两个版本？
HTTP 是否全部跳转到 HTTPS？
旧语言站是子域名还是子目录？
过去有没有 blog、news、shop、support、m 等子域名？
哪些旧 URL 有流量或外链？
哪些页面应该迁移到新站对应页面？
哪些页面已经没有保留价值？
新站是否有对应内容承接旧页面？

这些问题回答清楚以后，再做重定向和 Change of Address，迁移会稳很多。

如果这些问题没有回答，迁移后再排查，就会很被动。

---

Change of Address 要按“旧变体”分别处理

这次 Google 更新最直接的实操点，就是 Change of Address 不能只考虑一个旧站属性。

如果旧站有多个重要变体，就要分别确认它们的新去向。

比如旧站有：

oldsite.com
www.oldsite.com
en.oldsite.com
blog.oldsite.com

新站结构变成：

newsite.com
newsite.com/en/
newsite.com/blog/

那么迁移关系就不能只写成：

oldsite.com → newsite.com

还要考虑：

www.oldsite.com 应该跳到哪里；
en.oldsite.com 应该跳到哪里；
blog.oldsite.com 应该跳到哪里。

如果这些子域名在 Search Console 中没有验证，就需要先验证。否则你可能无法在对应属性上提交迁移，也无法看到它们迁移后的数据。

这里有一个容易混淆的地方：

如果只是同一个域名内从 www 改成非 www，比如 www.example.com 改成 example.com，一般不需要用 Change of Address 工具，主要依靠 301 重定向和 canonical。

但如果是换域名，例如 oldsite.com 迁移到 newsite.com，旧站下的 www.oldsite.com、en.oldsite.com、blog.oldsite.com 等变体，也要纳入迁移处理。

这就是这次更新强调的重点。

---

迁移后不要只看新站数据

网站迁移上线后，很多人只盯着新站排名和流量。

这不够。

迁移后，旧站数据同样重要。

你要看旧域名点击是否逐步下降，新域名点击是否逐步上升。
要看旧 URL 是否还在搜索结果中大量出现。
要看新 URL 是否正常被索引。
要看是否有大量 404、重定向错误、canonical 指向旧域名、sitemap 仍提交旧地址。
如果是多语言站，还要看 hreflang 是否更新到新域名。
如果图片搜索原来有流量，还要看图片 URL 是否也被正确处理。

迁移后短期波动是正常的。

但如果几周后旧站仍然有大量页面被索引，新站重要页面迟迟不被收录，或者某个语言版本完全没有恢复，就要回头检查迁移关系是否有遗漏。

很多时候，问题不是全站迁移失败，而是某个变体、某个子域名、某组 URL 没有处理好。

---

不要把换域名、改版和删内容全部叠在一起

网站迁移本身已经是一个比较大的变化。

如果同时换域名、换模板、删大量页面、改 URL 结构、改导航、改内容、改多语言方式，Google 就很难判断变化原因。

迁移后流量下降，到底是域名迁移造成的，还是内容被删造成的？
是 URL 对应关系有问题，还是新模板抓取有问题？
是 canonical 错误，还是重要页面被 noindex？
是多语言 hreflang 改错，还是新站内容质量下降？

如果所有变化同时发生，排查难度会明显增加。

所以更稳妥的迁移策略是：能少改就少改。

先把旧站稳定迁到新域名，让搜索系统建立新旧关系。
等迁移稳定后，再逐步做内容升级、模板调整、导航优化和页面合并。

不是所有项目都能做到完全分阶段，但至少要避免无计划地把所有变化压在同一天上线。

---

企业真正要建立的是迁移责任机制

网站迁移看起来是技术工作，但实际需要多方配合。

建站人员负责服务器、重定向、模板和上线。
SEO 负责旧 URL 盘点、映射、Search Console、sitemap、canonical 和数据监控。
内容人员负责确认旧内容和新内容是否对应。
品牌或运营人员负责旧域名续费、社交资料链接、广告落地页、外部平台资料更新。
管理者要确认迁移时间、风险预案和责任人。

如果迁移只是交给技术人员“把站搬过去”，很容易漏掉搜索资产。

尤其是旧域名续费和重定向保留时间，不要轻视。

Google 通常建议重定向保留足够长时间。对企业来说，如果旧域名有品牌价值、历史外链或客户认知，最好长期保留，不要迁移几个月后就放弃旧域名。

旧域名一旦失控，不只是 SEO 问题，也可能变成品牌和安全问题。

---

这次更新给我们的实际提醒

Google 6月17日这次更新，讲的是一个具体工具细节，但它背后的意思很实用。

网站迁移不能只看当前主域名。

你需要把旧站所有可能参与搜索信号的版本都找出来，包括 www、非 www、HTTP、HTTPS、语言子域名、博客子域名、移动端子域名和历史资源地址。

然后用清楚的重定向、canonical、站点地图、内部链接和 Change of Address 设置，把旧站和新站之间的关系交代清楚。

迁移做得好，不代表完全没有波动。
但迁移关系清楚，恢复通常更容易观察和判断。
迁移关系混乱，后续排查就会很困难。

所以，网站换域名前，不要只问：

新站什么时候上线？

还要问：

旧站有哪些历史版本？
www 和非 www 是否都处理了？
重要子域名是否都验证了？
旧 URL 是否有对应新 URL？
301 是否直接跳到最终页面？
canonical、sitemap、内部链接是否都指向新域名？
Change of Address 是否覆盖相关旧属性？
迁移后谁负责看 Search Console 数据？

这些问题准备好了，再迁移。

很多迁移损失，不是因为 Google 不理解网站搬家，而是因为网站自己没有把“搬家路线”讲清楚。