外贸站迁移HTTPS或换域名时，AI可见性为什么容易断层

外贸站迁移 HTTPS 或换域名时，AI 可见性容易断层，不是因为“AI 平台惩罚迁移”，而是旧 URL、重定向、canonical、sitemap、内链、索引和爬虫准入信号都要重新对齐。哪一层断了，搜索和 AI 候选来源都可能暂时看不稳。

先把边界说清楚：AI可见性断层 不是 Google、OpenAI、Perplexity 或 Anthropic 的官方报告指标。

这里说的断层，是外贸站迁移后可能出现的一类现象：

• 旧产品页还能打开，但新页面没进索引；
• 新域名上线了，旧域名没有稳定 301；
• sitemap 还在提交旧 URL；
• canonical 仍指向旧站；
• 多语言页 hreflang 混用 HTTP 和 HTTPS；
• WAF 迁移后把 crawler 拦掉；
• AI 搜索或回答系统暂时找不到原来可用的公开页面。

这些问题合在一起，才会让“可见性”看起来断了一截。

不是玄学，是迁移信号没接上。

Google把这些都看成站点迁移

Google 官方把下面这些情况都归入带 URL 变化的 site move：

• HTTP -> HTTPS；
• 域名变化，比如 example.com 到 example.net；
• 多个域名或主机名合并；
• URL 路径变化，比如 /products/a/ 改成 /en/products/a/。

对外贸站来说，这些变化经常同时发生：

http://example.com/product-a/
    -> https://www.example.com/en/products/product-a/

表面看只是升级 HTTPS 或换域名。
搜索系统看到的是：协议变了、主机名变了、路径变了、语言目录也变了。

如果旧 URL 到新 URL 没有一一对应，后面所有信号都会变乱。

为什么AI可见性会跟着波动

AI 搜索或 AI features 通常不会凭空理解“你换了站”。

更稳的说法是：它们依赖公开 URL 能被访问、搜索系统能重新发现和处理、页面有资格进入候选来源。尤其在 Google AI Overviews / AI Mode 里，Google 官方说 supporting link 需要页面已被索引，并且有资格在 Google Search 展示 snippet。

所以迁移时会出现一个链条问题：

旧URL消失
-> 旧信号需要通过重定向传到新URL
-> 搜索爬虫重新抓取
-> 索引和canonical重新处理
-> 搜索展示和AI features候选重新稳定

如果链条中间断了，AI 可见性就可能断层。

注意，这不是说“换域名一定掉 AI 排名”。
更准确的说法是：迁移会引入重新抓取、重新索引、重新判断的过程，期间搜索可见性可能波动。

最常见的断层点

这些问题单独看都不大。
迁移时一起出现，就会让可见性突然掉下去。

换域名时最重要的是URL映射

换域名不是“把首页跳过去”就完事。

对外贸企业，最重要的是页面级映射：

https://old.example.com/products/stainless-steel-valve/
-> https://www.example.com/products/stainless-steel-valve/

https://old.example.com/case-studies/chemical-plant-valve-project/
-> https://www.example.com/case-studies/chemical-plant-valve-project/

https://old.example.com/faq/
-> https://www.example.com/faq/

不要把所有旧 URL 都 301 到新首页。

旧产品页应该跳新产品页。
旧案例页应该跳新案例页。
旧 FAQ 应该跳新 FAQ。
确实没有对应内容，再考虑跳到最相关分类页或返回合理状态。

301重定向和canonical不是一回事

迁移时经常有人说：“我 canonical 指过去了，还需要 301 吗？”

需要分清：

Google 官方说，永久重定向是告诉 Google Search 和用户正确新位置的强信号；Googlebot 会跟随重定向，索引管道会把重定向作为目标 URL 应成为 canonical 的信号。

Canonical 是信号，不是跳转。用户访问旧 URL 时，它不会自动去新 URL。

所以迁移时常见组合是：

旧URL -> 301/308 -> 新URL
新URL rel=canonical -> 新URL自己
sitemap -> 只列新URL
站内链接 -> 只指向新URL

这四个方向要一致。

HTTPS迁移别用错工具

HTTP -> HTTPS 迁移看起来简单，但很多外贸站会错在细节。

该做的是：

• 配好 TLS 证书；
• HTTP 页面永久重定向到 HTTPS；
• sitemap 使用 HTTPS URL；
• canonical 使用 HTTPS URL；
• hreflang 使用 HTTPS URL；
• 站内链接改成 HTTPS；
• 图片、PDF、脚本等资源也避免混用 HTTP；
• Search Console 里验证相关属性并观察索引。

不该做的是：把 HTTP -> HTTPS 当成换域名去提交 Change of Address。

Google 的 Change of Address 工具适合域名或子域迁移，不适用于 HTTP -> HTTPS、同域路径变更、www / non-www 互换等场景。

一个Nginx重定向示例

下面只是示例，真实配置要按你的服务器结构测试。

server {
    listen 80;
    server_name old.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name old.example.com;

    ssl_certificate /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;

    return 301 https://www.example.com$request_uri;
}

如果路径也改了，不要只用 $request_uri 硬跳。要做页面级规则或映射表。

比如：

rewrite ^/product/(.*)$ https://www.example.com/products/$1 permanent;
rewrite ^/case/(.*)$ https://www.example.com/case-studies/$1 permanent;

上线前至少抽查核心页面。

curl -I http://old.example.com/products/stainless-steel-valve/
curl -I https://old.example.com/products/stainless-steel-valve/
curl -I https://www.example.com/products/stainless-steel-valve/

你要看到的是：

旧HTTP -> 301 -> 新HTTPS对应页
旧HTTPS -> 301 -> 新HTTPS对应页
新HTTPS -> 200

sitemap要换成新URL

迁移后，sitemap 继续提交旧 URL，是很常见的断层点。

新 sitemap 应该只列你希望搜索结果展示的新规范 URL。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/products/stainless-steel-valve/</loc>
    <lastmod>2026-08-13</lastmod>
  </url>
  <url>
    <loc>https://www.example.com/case-studies/chemical-plant-valve-project/</loc>
    <lastmod>2026-08-13</lastmod>
  </url>
</urlset>

不要在新 sitemap 里混入：

• HTTP URL；
• 旧域名 URL；
• 测试域名 URL；
• 被 noindex 的 URL；
• canonical 指向旧站的 URL；
• 不能返回 200 的 URL。

对多语言站，还要同步检查 hreflang 里的 URL 是否也改成新地址。

迁移前后的检查清单

迁移前

迁移中

迁移后

日志里要看什么

迁移后，只看流量是不够的。先看核心 URL 的技术状态。

grep -Ei 'Googlebot|bingbot|OAI-SearchBot|PerplexityBot|Claude-SearchBot' /var/log/nginx/access.log \
  | awk '{print $1, $7, $9, $12}' \
  | head -n 50

重点不是“有没有访问”，而是：

• 旧 URL 是否被请求；
• 旧 URL 返回的是 301 还是 404；
• 新 URL 是否返回 200；
• crawler 是否被打到首页；
• crawler 是否遇到 403；
• 访问的是核心产品页，还是无意义参数页。

如果你看到大量旧产品 URL 返回 404，就说明迁移映射有问题。
如果你看到新站返回 403，就要查 WAF / CDN。
如果你看到旧 URL 全部跳首页，就要补页面级映射。

IndexNow可以做什么

如果你关注 Bing / Copilot 相关生态，IndexNow 可以作为补充通知机制。

它的作用是向参与搜索引擎通知 URL 新增、更新或删除。
但它不是抓取保证，也不是索引保证，更不是 AI 引用保证。

一个简化请求长这样：

curl -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{
    "host": "www.example.com",
    "key": "YOUR_INDEXNOW_KEY",
    "keyLocation": "https://www.example.com/YOUR_INDEXNOW_KEY.txt",
    "urlList": [
      "https://www.example.com/products/stainless-steel-valve/",
      "https://www.example.com/case-studies/chemical-plant-valve-project/"
    ]
  }'

可以用，但别神化。

不要马上关旧站

迁移完成后，旧域名和旧 URL 的重定向还要保留并持续监控。

Google 官方也提醒，站点迁移完成需要 Googlebot 访问旧站和新站上的 URL；速度没有固定频率，取决于站点规模、服务器速度和重新抓取处理。

所以外贸站迁移后不要做这几件事：

• 旧域名马上停；
• 旧 URL 全部返回 404；
• robots.txt 挡住旧站；
• 删除旧站 Search Console 验证；
• 只看首页，不抽查核心产品页；
• sitemap 继续提交旧 URL；
• canonical 还指旧域名。

尤其不要用 robots.txt 阻断旧 URL 来“加速迁移”。旧 URL 需要能被抓取，搜索系统才能看到重定向。

最后的判断

迁移不会天然毁掉 AI 可见性。
真正危险的是迁移后信号不一致。

对外贸站来说，最要命的不是“换了 HTTPS”或“换了域名”，而是：

• 旧产品页没有对应新页；
• 301 跳错；
• 新页 noindex；
• canonical 指旧站；
• sitemap 还是旧 URL；
• 多语言关系断了；
• crawler 被 WAF 拦了；
• 搜索系统还没重新处理完。

把这些信号接上，AI 搜索可见性才有机会跟着恢复。
接不上，就算页面内容还在，也可能暂时从搜索和 AI 候选来源里断掉。

参考资料

• Google: How to move a site with URL changes
• Google: Redirects and Google Search
• Google: What is canonicalization
• Google: Build and submit a sitemap
• Google: AI features and your website
• Google Search Console Help: Change of Address tool
• Google Search Console Help: URL Inspection tool
• Bing: How to add IndexNow to your website
• IndexNow: Documentation