換網域時，怎麼保留路徑與 UTM 參數

換網域時，最危險的做法是把所有舊網址都導到新首頁。

真正可用的 網域轉址保留路徑，應該把完整 request URI 帶到新網域。也就是說：

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

應該到：

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

如果你的轉址只保留網域、不保留 path 和 query string，使用者要找的頁面會消失，EDM 與廣告追蹤也會斷掉。對 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

所以網域轉址不是 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、名片、社群貼文裡存在很久。把它們全部導到首頁，會浪費很多已經建立的信任。

活動網域整併

很多行銷團隊會有 campaign-brand.com、event-brand.com 這種短期活動網域。活動結束後如果要整併回主站，路徑與 UTM 參數要一起規劃。

EDM、廣告與短網址

EDM、Meta 廣告、Google Ads、LINE 官方帳號、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 變體。