URL 轉址管理：網站搬家、網域轉移與批次 301 的 Edge 工作流

很多團隊搜尋 301 轉址、網站搬家、網域轉移、URL 轉址 時，真正想解決的不是一條設定，而是一次風險很高的上線。舊網址不能 404，SEO 不能斷，廣告和 EDM 的 UTM 不能掉，QR Code 已經印在包裝或活動物料上，App 下載導流還要分 iOS、Android 和桌面。

單條轉址很容易。困難的是規則散在 Nginx、Apache、CDN、WordPress、Shopify、WooCommerce、客製 CMS、短網址工具、SEO 試算表和廣告後台裡。誰最後生效？path 有沒有保留？query parameter 會不會被吃掉？出了問題要找誰回滾？

URL 轉址管理平台要處理的是這個營運層。它不只是短網址工具，而是把網站搬家、網域轉移、批次 301、臨時活動 302、裝置/地區路由、驗證、監控、分析和回滾放進一個可審查的控制面。

UrlEdge 將規則放在控制台管理，並發佈到 Cloudflare-backed edge。SEO、行銷、電商、工程和代理商可以在同一層協作，不需要每次都碰 origin server、CMS plugin 或應用程式部署。

轉址何時變成基礎設施

幾條轉址可以靠主機或 CMS 撐住。正式搬站不行。

Google 的 redirect 文件把轉址視為告訴使用者和搜尋引擎「資源已搬到新位置」的訊號。實際上，這個訊號需要一張可驗證、可維護的 URL map。

先判斷：你需要一條轉址，還是一套管理層？

如果只是把一個舊頁面導到新頁面，主機設定或 CMS plugin 可能就夠了。UrlEdge 要處理的是更常見也更危險的情況：規則很多、團隊很多、上線後還會變。

這也是為什麼這篇應該當主品類文章，而不是短網址文章。短網址只是其中一種應用；網站搬家、網域轉移、批次 301、參數保留和回滾，才是 UrlEdge 的核心場景。

Redirect map 不該只有舊 URL 和新 URL

只有兩欄的表格不夠。每條規則都應該描述行為。

這些欄位能避免「表格看起來完成，但實際流量出現 chain、loop、掉參數或去錯頁」。

網站搬家要保留舊 URL 的意圖

把所有舊 URL 都導到首頁很快，但通常不是好做法。舊 URL 代表使用者原本要找的內容。

實務流程：

1. crawl 舊站。
2. 加上流量、外鏈、轉換、營收和活動狀態。
3. crawl 新站或 staging。
4. 將重要 URL 對到最接近的目的地。
5. 標記高風險 URL。
6. 用 Bulk URL Management 匯入。
7. 用 Redirect Checker 驗證。
8. 用 Broken Link Monitor 持續監控。

搬家不是 CSV 匯入完成就結束。舊流量、搜尋引擎、廣告點擊和 QR 掃描都抵達正確頁面，才接近完成。

網域轉移不是只做 forwarding

網域轉移需要決定：

• 是否保留 path
• 是否保留 UTM 和 query
• root、www、HTTPS、subdomain 是否一致
• 國家/地區網域要導到本地站還是全球站
• 這是永久搬移還是臨時活動

註冊商 forwarding 適合幾乎沒有流量的舊域名。只要還有 SEO、廣告、EDM、QR、聯盟或直接流量，就需要可驗證、可監控、可回滾的轉址層。

UTM 和夥伴參數是業務要求

頁面能開，不代表轉址正確。很多問題發生在參數被吃掉之後。

對行銷和電商來說，UTM、優惠碼、creator code、partner ID、sub ID 是歸因契約，不是小細節。

為什麼放在 Edge

轉址發生在目標頁載入之前。如果所有舊 URL 都先打到 origin 或 CMS，再由它回 redirect，這件事發生得太晚。

Edge 的好處：

• request 到 origin 前就回應
• 舊站下線後，舊域名仍可工作
• 不用 deploy 應用也能發佈規則
• 將 SEO/行銷規則從應用程式碼分離
• 用 server-side analytics 看國家、裝置、規則和狀態
• 依 snapshot 回滾

應用內邏輯仍可放在應用裡。但網站搬家、網域轉移、活動連結、QR、App fallback、舊 URL 清理，通常更適合專門的 Edge 層。

上線前 QA 與上線後監控

上線前檢查：

• 預期 HTTP status
• 最終目的地
• 沒有 loop
• chain 盡量短
• path 和 query 保留
• root、www、HTTPS、subdomain
• 國家、語言、裝置規則
• owner approval
• rollback route

上線後繼續監控。Landing page 會下線，商品會合併，CMS plugin 會新增一跳，廣告目的地會被改掉。只做上線前 QA 不夠。

UrlEdge 的位置

UrlEdge 適合放在「轉址需要快，也需要治理」的位置。

可用於：

• Redirect Management
• Bulk URL Management
• Permanent 301 Redirects
• Temporary 302 Redirects
• Redirect Checker
• Geo Redirects
• Device Targeting
• Advanced Redirect Rules
• UTM Builder
• Link Firewall

價值不是「多做幾條跳轉」，而是每條規則都知道誰批准、做什麼、如何驗證、如何回滾。

常見錯誤

所有情境都用 301

永久搬移適合 301/308。活動、測試、臨時 fallback 通常更適合 302/307。

全部導首頁

省時間，但失去使用者意圖，也讓遷移訊號模糊。

放任 redirect chain

多次改版後，舊 URL 可能經過多個中間 URL。盡量直接指向目前最終目的地。

忘記參數

使用者看起來沒問題，報表已經壞了。

FAQ

什麼是 URL 轉址管理？

它是跨網域、路徑、活動、App 和團隊建立、審查、發佈、驗證、監控與回滾 redirect 的流程。

這和短網址工具一樣嗎？

不一樣。短網址只是應用場景之一。轉址管理還包含網站搬家、網域轉移、批次 301、參數保留、路由、監控與治理。

什麼時候用 301？

永久搬移用 301 或 308。活動、測試、臨時目的地用 302 或 307。

參考資料

• Google Search Central：重新導向和 Google 搜尋
• Google Search Central：涉及網址變更的網站遷移
• MDN：HTTP 重新導向
• Cloudflare Docs: URL redirect parameters