UrlEdge
回到部落格
2026年5月17日 UrlEdge Editorial3 min read

www、apex 與 wildcard forwarding：怎麼做才不傷 SEO

host normalization 看起來簡單，但 root、www、subdomain、path 和 query string 一旦各有規則，就很容易出現 redirect chain。先決定 canonical host 才是重點。

apex、www 與 wildcard subdomain 匯聚到單一 canonical host 的 host normalization map

host normalization 看起來像一個小小的 DNS 工作。但一旦進到 migration 或 rebrand，它很快就變成 URL policy 的問題。

品牌想用 apex domain。舊站還在用 www。產品、docs 或 campaign 可能在 subdomain 上。agency 會把 wildcard forwarding 寫進遷移表。廣告連結還要保留 path 與 UTM。這些決策分開做，最後通常就是 redirect chain。

重要的問題不是 www 和 apex 誰永遠比較好。重要的是：哪個 host 要當 canonical，以及其他 variant 要怎麼跟上。

如果這是更大 migration 的一部分，先看 Website Migration Redirect Checklist。這篇只聚焦 host layer。

host 也是 URL policy 的一部分

example.tw、www.example.tw 與 *.example.tw 在操作上不是同一件事。

  • apex 在 marketing 上通常更乾淨。
  • www 在舊 stack 很常見。
  • subdomain 可能是 product、docs、support 或 store。
  • wildcard 適合很多 host 都要走同一條 rule 的情境。

重點是，不要讓這些 variant 靠運氣跑。

Host normalization map for apex, www, and wildcard subdomains

在 launch 前先決定 canonical host

先回答這些問題：

問題為什麼重要
網站是在 apex 還是 www 上決定使用者看到的 canonical URL
哪些 subdomain 是 alias不是每個 subdomain 都該合併
path 要不要保留SEO、bookmark、deep link 都靠它
query string 要不要保留UTM、coupon、ID 可能會消失
是否有 temporary exceptioncampaign 與 launch 可能需要不同規則

如果這些答案不清楚，幾個 layer 會一起開始幫忙。

DNS 不會解決全部

DNS 只告訴 traffic 去哪，不會直接決定可見 URL 的變化。

乾淨流程：

http://www.old-brand.example/pricing?utm_source=email
  -> https://new-brand.example/pricing?utm_source=email

脆弱流程：

http://www.old-brand.example/pricing
  -> https://www.old-brand.example/pricing
  -> https://old-brand.example/pricing
  -> https://new-brand.example/pricing

單一 hop 比較容易測試，也比較容易維護。

Wildcard forwarding 適合結構還對齊的時候

當 path 結構沒有大改時，wildcard rule 很有用。

old.example.tw/* -> new.example.tw/$1

適合情境：

  • 需要保留大量舊 URL
  • path 結構變化不大
  • 不想每個頁面都寫一條 rule
  • 舊 subdomain 真的就是 alias

如果資訊架構變化很大，重要 URL 還是要明確 mapping。

保留 path 和 query

改 host 不等於刪掉 request context。

http://old.example.tw/docs/api?ref=partner&utm_source=newsletter

如果結構允許，最後應該到：

https://new.example.tw/docs/api?ref=partner&utm_source=newsletter

這對以下情況都很重要：

  • SEO page
  • documentation
  • paid campaign
  • affiliate link
  • 使用者 bookmark

path 或 query 一旦消失，redirect 看起來對了，價值卻掉了。

避免 chain

最常見的錯誤是把責任拆開：

  • HTTP 到 HTTPS 在一個 layer
  • www 到 apex 在另一個 layer
  • domain migration 在 CDN 或 hosting
  • app 又加一條 canonical rule

結果就是 http -> https -> www -> final。

如果你的 stack 已經長這樣，下一步看 Redirect Chains and Loops。

做 launch matrix 測試

發布前測試真實變體。

TestExample
Apex roothttps://example.tw/
www roothttps://www.example.tw/
Deep pathhttps://example.tw/pricing
Deep path with queryhttps://example.tw/pricing?utm_source=email
Old host with pathhttps://old.example.tw/blog/post-1
Wildcard subdomainhttps://docs.example.tw/guide

Launch QA matrix for canonical host, path preservation, query preservation, and redirect hops

確認：

  • final host 正確
  • path 有保留
  • query 有保留
  • status code 符合意圖
  • 沒有多餘 hop

UrlEdge 適合放在哪

UrlEdge 很適合把 host normalization 當成 routing policy 管理，而不是零散 snippet。

重點是有一個地方負責 canonical host、variant、path、query 和 status code。

FAQ

一定要用 apex 代替 www 嗎？

不一定。兩者都可以。重點是選一個 canonical host，然後讓其他 variant 乾淨地跟上。

wildcard subdomain 可以用一條 rule 嗎？

可以，只要結構仍然對齊。如果變化很大，重要 URL 還是要明確 mapping。

只靠 DNS 可以嗎？

不行。DNS 不能取代使用者看得到的 HTTP redirect policy。

campaign parameter 要保留嗎？

通常要，除非你有明確理由刪掉。丟失的 attribution 很難再找回來。

參考

先把 canonical host 定下來

把 root、www、wildcard subdomain 與自動 HTTPS、path preservation 一起管理。

試用 Free Redirect Service

相關文章

查看全部