换域名时，怎么保留路径与 UTM 参数

换域名时，最危险的做法就是把所有旧 URL 都导到新首页。

真正可用的 域名跳转保留路径，应该把完整 request URI 带到新域名。也就是说：

old-brand.com/pricing?plan=pro&utm_source=email

应该到：

new-brand.com/pricing?plan=pro&utm_source=email

如果你的 redirect 只保留域名、不保留 path 和 query string，用户要找的页面会消失，EDM 和广告 tracking 也会断掉。对 SEO、活动成效、客服体验都不是小问题。

如果这次换域名是整站搬家的一部分，请先看 网站迁移跳转检查清单，再回来处理本文这个细节。

「保留路径与参数」到底是什么

大家说「域名导流」时，可能指的是很不一样的东西。

只导首页

所有请求都到新首页：

old-brand.com/* -> new-brand.com/

这很简单，也最容易出事。因为它把用户原本要看的页面信息丢掉了。

保留路径

域名后面的 path 保留下来：

old-brand.com/blog/post-1 -> new-brand.com/blog/post-1

多数网站迁移、品牌改名、内容站重整、文件站换域名，都需要这种做法。

保留查询参数

活动与追踪参数也保留下来：

old-brand.com/pricing?utm_source=email -> new-brand.com/pricing?utm_source=email

如果这些参数被跳转层移除，GA4、广告平台、CRM、affiliate 报表都可能开始失真。

为什么 DNS 不够

这是最常见的误解。

DNS 的 CNAME、A record 只是告诉网际网络「流量要送到哪里」。它本身不会替浏览器回传 HTTP 301 或 302，也不会自动帮你保留 path、query string 或 canonical host。

如果你想让用户和搜索引擎到另一个 URL，你需要 HTTP redirect layer 来决定：

• 回传哪个状态码
• 目的地是哪个 host
• 是否保留路径
• 是否保留 query parameters
• 是否强制 HTTPS
• 是否只转特定 path 或全部 wildcard

所以 domain redirect 不只是 DNS 任务，它本质上也是 routing 任务。

如果你还不确定这次变更是永久还是暂时，先读 301、302、307、308 跳转差在哪，不要先上 302 之后忘了改。

最安全的域名搬家模式

对多数永久搬家来说，基准做法是：

1. 先选定最终 canonical hostname
2. 强制 HTTPS
3. 把每个有意义的旧 path 导到新域名上的对应 path
4. 保留重要 query parameters
5. 尽量维持一跳到最终目的地

好的例子：

http://old-brand.com/docs/api?ref=partner
  -> https://new-brand.com/docs/api?ref=partner

不要变成：

http://old-brand.com/docs/api
  -> https://old-brand.com/docs/api
  -> https://www.new-brand.com/docs/api
  -> https://new-brand.com/docs/api

后者会留下跳转链，也让 QA、SEO 和性能都变难看。

哪些情境最需要保留路径

品牌改名或公司更名

旧品牌网址通常还会在新闻稿、合作页、履历、PDF、名片、社交贴文里存在很久。把它们全部导到首页，会浪费很多已经建立的信任。

活动域名整并

很多 growth 或 marketing 团队都会有 campaign-brand.com、event-brand.com 这类短期活动域名。活动结束后如果要整并回主站，路径与 UTM 参数要一起规划。

EDM、广告与短网址

EDM、Meta 广告、Google Ads、WhatsApp、微信服务号或企业微信、KOL 合作链接常常带很多参数。跳转只要洗掉一次，报表就会开始对不上。

商品页与分类页导流

电商换平台或换域名时，用户常常直接落在商品页，不是首页。保留路径能让旧商品链接继续找到最接近的新目的地。

文件与知识库

文件用户通常是搜索错误讯息、API 名称或功能教学后进入深层页。把所有 docs 请求导到首页，等于让用户重找一次答案。

一个干净的 wildcard forwarding 模型

最容易理解的模型是：

source:      old-brand.com/*
destination: new-brand.com/$1

意思是：

• 拿到 slash 后面的所有内容
• 放到新域名相同位置
• 保留原本请求形状

例如：

如果也保留 query string：

/pricing/enterprise?utm_source=partner

就仍然会是：

/pricing/enterprise?utm_source=partner

如果你的导流计划现在会经过两三个 host 才到最终页，先修掉。可以参考 怎么找出跳转链与跳转回圈。

上线前先做 4 个检查

1. 先确认最终目的域名

请先选定唯一标准：

• new-brand.com
• 或 www.new-brand.com

不要边搬边决定。这正是 http -> https -> www -> final 这类跳转链出现的原因。

2. 决定状态码

如果是永久搬家，通常用 301。

如果只是短期活动或暂时导流，才用 302。

状态码不是 SEO 仪式感，它是在告诉搜索引擎、浏览器与后续维护者：这条规则的意图是什么。

3. 明确处理 query string

不要假设每个供应商都会自动保留参数。请拿真实活动 URL 测。

curl -I 'https://old-brand.com/pricing?plan=pro&utm_source=email'

确认 Location header 里有你预期的 path 和 parameters。

4. 根目录与深层页都要测

很多跳转只测 / 会成功，深层页才失败。

请至少测：

• /docs/api
• /blog/post-slug
• /pricing/enterprise
• /old-category/product-123
• 带 utm_ 的活动页
• 旧短网址与 QR Code 目的地

HTTPS 和 SSL 也是跳转的一部分

最糟的搬家状况之一是：

• 跳转规则其实写对了
• 但旧域名 HTTPS 没有正常终止
• 用户在还没被转走之前就看到凭证或安全警告

跳转流程从第一个 request 就开始，不是从你的规则有机会执行才开始。这也是自动 SSL 很重要的原因。

UrlEdge 免费跳转服务 支持自动 HTTPS 与 wildcard forwarding，适合不想在 Nginx、Apache 或 app middleware 里手动堆规则的团队。

常见错误

只转首页

这是最典型的「首页看起来正常」上线事故。真实用户不会只拜访 /。

忘记 root domain 和 www

你需要同时想清楚：

• old-brand.com
• www.old-brand.com
• scope 内的 subdomains

把活动参数洗掉

即使 SEO 暂时看起来没坏，活动归因也可能一夜之间变得不可信。

做出多段跳转链

保留路径的价值，会被多层 host bounce 抵消掉一部分。尤其在行动网络、App 内浏览器和海外访客身上更明显。

HTTP 与 HTTPS 规则分散处理

如果旧 host 无法干净处理 HTTPS，用户可能先看到安全错误，根本到不了你的新网址。

一个实用的 UrlEdge 设置顺序

典型永久搬家可以这样做：

1. 连接旧域名
2. 启用 HTTPS
3. 建立 wildcard redirect rule
4. 保留 path
5. 保留必要 query parameters
6. 用 跳转检查工具 测前几十个高价值页面
7. 上线后用 analytics 和 404 监控补例外

这种做法特别适合品牌改名、活动域名整并、电商迁站、文件站改域名，以及希望低程序码完成域名导流的团队。

FAQ

裸域名可以跳转并保留路径吗？

可以，只要你的跳转层支持 root-domain forwarding 和 path preservation。这是很常见的搬家设置。

Query string 一定要全部保留吗？

不一定。重点是明确决定。活动、追踪、affiliate、功能性参数通常要保留；垃圾参数可以删，但不要不小心删。

Wildcard forwarding 适合所有搬家吗？

不适合。当新旧路径结构大致相同时，wildcard 很好用；如果信息架构大改，高价值 URL 仍需要一对一 mapping。

可以在全量改 DNS 前先测吗？

可以，也应该。先用 staging 或 controlled host 测，再抽样验证真实 path、UTM、HTTPS 与不同 host 变体。