你从 old.com 迁到了 new.com，配好了 301 重定向，新域名也在正常服务。但 Google Search Console 的老资源还是只跟踪旧域名；或者你把 new.com 加成了资源，它却一直是空的，而新 URL 明明在被抓取。大家容易漏掉的一点：GSC 的资源（property）并不是绑定到你脑子里那个”网站”概念上的，它绑定的是一个具体的 URL 前缀，或者（对 Domain 资源来说）是经过 DNS 验证的所有权。历史效果数据留在老资源里，永远不会迁过去。
最快的修法： 把 new.com 加成 Domain 资源，用 DNS TXT 验证，然后打开老资源 → Settings → Change of address → Update，把目标指向新资源。这会让 Google 在 180 天内把信号合并到新站点。两个资源和 301 重定向都至少保留一年。
你属于哪种情况？
| 现象 | 最可能的原因 | 跳到 |
|---|---|---|
资源切换器里只有 old.com | 新域名从没加过 | 原因 1 |
| 新资源存在但数据为零 | 没验证，或前缀不对 | 原因 2、3 |
www 和非 www（或 http/https）数据缺失 | URL-prefix 只覆盖一个变体 | 原因 2 |
| 老资源没变，新资源填得很慢 | 没提 Change of Address | 原因 4 |
按 locale（/en/、/zh/）的数字不对 | locale 子资源漏了 | 原因 5 |
| 老的历史数据没了 | 老资源被删了 | 原因 6 |
常见原因
按命中率从高到低排。
1. 新域名从没加成资源
你迁了 DNS，但从未在 Search Console 里加 new.com。资源不存在，所以新 URL 在 Google 索引里堆着，你却没有任何面板能看到它们。
怎么判断： Search Console → 左上角的资源切换器。如果只列出 old.com，就把新的加上。
2. 资源类型或前缀不对
你给 https://new.com/ 加了 URL-prefix 资源，但你的站也在服务 https://www.new.com/。URL-prefix 资源只覆盖你输入的那个精确协议、主机和路径，所以另一个变体完全看不到。而 Domain 资源一次性覆盖所有子域（www、m、blog）以及 http 和 https。
已有资源的类型无法转换。如果类型选错了，就再加一个正确类型的资源——两个可以并存。
怎么判断： GSC → 资源设置 → 看类型。如果是 URL-prefix，而你服务了不止一个主机或协议，就加一个 Domain 资源。
3. 新域名所有权没验证
你加了资源但没完成验证（Domain 资源要在 apex 加一条 DNS TXT 记录）。资源出现在列表里，但在验证完成前不会有数据流入。
怎么判断： 打开新资源。如果看到 “Not verified” 或 “Ownership verification failed” 横幅，就完成 TXT 记录那一步。DNS 生效可能要几分钟到几小时。
4. 没提 Change of Address
Change of Address 工具告诉 Google”这个站从 X 迁到了 Y”，并在 180 天内把排名信号转给新站点。不用它，合并会更慢，而且可能让新旧两个版本在索引里互相竞争。
怎么判断： 老资源 → Settings → Change of address。如果显示 “No change of address”，说明你跳过了这一步。
5. 双语 / i18n 子资源漏了
你同时服务 new.com/en/ 和 new.com/zh/。用 URL-prefix 资源的话，每个 locale 都要一个；用一个 Domain 资源则能一次抓全所有 locale。某个 locale 没有资源，就不会产生这个 locale 的 Performance 数据。
怎么判断： 按 locale 拆分的 Performance 看起来不全。改用 Domain 资源，把 new.com 下的全部抓进来。
6. 删老资源时把历史数据弄丢了
你为了”清理”把老资源删了。GSC 没有撤销删除，而且效果数据本来也硬性只保留 16 个月——超过这个期限的点击、展示、CTR、平均排名都会被清除，没有任何恢复途径。
怎么判断： 列表里资源没了，无法恢复。删任何资源前先导出数据；只要数据还在 16 个月窗口内，就按季度导出。
最短修复路径
第 1 步：把新域名加成 Domain 资源
GSC → Add property → 选 Domain（不是 URL-prefix）→ 输入 new.com（不带 https://、不带 www.）。
用 GSC 给你的 DNS TXT 记录验证，加在 new.com 的 apex 上。Domain 资源一次性确认所有子域和协议的所有权——这正是换域名后你想要的。
第 2 步：提交新 sitemap
新资源 → Sitemaps → 输入 sitemap.xml（相对路径，例如解析为 https://new.com/sitemap.xml）。
等状态显示 “Success”。几小时内，新 URL 应该开始出现在 Pages（索引）报告里。
第 3 步：在老资源里提 Change of Address
老资源 → Settings → Change of address → Update → 选新资源作为目标 → 运行验证。
工具会跑迁移前检查，并验证一批你的老 URL 样本（确认那些 301 确实落到了对应的新页面）。出现严重错误会拦住迁移，所以要先修好再重试。要求：
- 你在同一个 Google 账号下拥有两个资源，且都已验证。
- 全站的
301（永久）重定向把每个老 URL 映射到对应的新 URL，包括首页。 - 两个站点的
robots.txt都不能挡住 Google 需要抓取的 URL。
注意这个工具的两个实际限制（截至 2026 年 6 月）：
- 它只对域名级资源生效（
example.com、m.example.com），对example.com/shop/这种路径级资源无效。 - 它不会自动迁移子域。如果你还迁了单独的
www或m.资源，要分别给每一个提 Change of Address。
第 4 步：老资源和重定向至少保留一年
Change of Address 信号的有效期是 180 天，过后 Google 就把新旧站点当作无关站点。所以：
301重定向至少保留 180 天，最好 12 个月——外链仍会打到老 URL、被重定向、把信号传过去。- 老域名注册再续大约一年，免得别人抢注。
- 在这个窗口里老资源还会收到一些残留数据，定期导出存档。
第 5 步：两个资源都监控
迁移后的几周到几个月里：
- 老资源： 随着 Google 转向新站点，流量应该往下走。
- 新资源： 流量应该往上走。
- 盯着老资源的
Pages报告，看有没有老 URL 返回404而不是301——重定向坏掉会卡住信号转移。
第 6 步：怎么确认修好了
- 老资源 →
Settings→Change of address显示迁移处于生效状态（不是 “No change of address”）。 - 新资源 →
Pages报告里新 URL 正在进入 “Indexed”。 - 在搜索里
site:new.com能返回你的页面；接下来几周site:old.com逐渐变少。 - 在新资源里对一个已迁移的页面做 URL Inspection，显示它在新 canonical 下已被收录。
第 7 步：12 个月后决定老资源去留
等 180 天信号早已过期、流量也完全转移之后，老资源就纯粹是历史了。你可以无限期保留它（免费且无害）当参考，也可以导出后删除。如果以后可能要做同比分析，没导出就别删。
容易误判的情况
很多人以为加了新域名就会把数据从老资源”搬过来”。不会。历史数据留在它被记录的地方，只有新资源积累新数据。Change of Address 工具转移的是排名信号，不是你的报告历史。
预防建议
- 新域名一律用 Domain 资源（不是 URL-prefix）——自动覆盖所有子域和协议。
- 切换域名当天就提 Change of Address，别拖几周。
- 迁移后老 GSC 资源保留作存档；过渡期间绝不删。
- 通过 API 按季度导出 GSC 数据；效果数据 16 个月硬性清除，无法恢复。
301重定向和老域名注册都至少保留一年。
FAQ
- Change of Address 会把我的历史点击和展示迁过去吗？ 不会。它转移的是帮助新 URL 排名的信号；你的老效果历史留在老资源里，永远不会复制过去。
- Change of Address 信号能持续多久？ 180 天。过后 Google 就把两个站点当作无关，所以重定向要保留得远超这个期限——最好整整一年。
- 能把两个资源合并成一个吗？ 不能。GSC 没有合并功能。两个都留、分别查，或者以后就靠那个单一的 Domain 资源。
- 它只验证了我几个 URL——有问题吗？ 没问题。工具检查的是一批有代表性的老到新 301 样本。只要它没报严重错误，迁移就会继续。
www和m.版本要分别提 Change of Address 吗？ 如果它们是独立的域名级资源，就要。工具不会自动迁移子域。- 我的新 Domain 资源过了一天还是空的，为什么？ 要么 DNS TXT 验证没完成，要么 sitemap 没提交，要么 Google 还没重新抓取。先确认验证，再重提 sitemap。