面向 SEO 代理商的批次重新導向：如何把遷移對照表安全上線

批次重新導向一旦被當成純技術細節，就會變成遷移風險。對 SEO 代理商來說，redirect map 不只是工程師要匯入的表格，它同時是客戶驗收紀錄、SEO 風險清單、開發交接文件，以及上線異常時的回滾依據。

所以大型遷移不應只存在於試算表、LINE 群組、WordPress 外掛、Nginx 設定或臨時加上的 CDN 規則裡。DNS、CDN、主網域、CMS 或電商平台切換前，這張對照表本身就應該像正式環境設定一樣被審閱。

這篇文章適合處理 SHOPLINE、Cyberbiz、Shopify、WooCommerce、WordPress、自建 CMS、headless commerce 與多品牌網站遷移的 SEO 代理商、技術 SEO、電商與開發團隊。若舊網址仍出現在 LINE 官方帳號、Meta/Google 廣告、EDM、聯盟行銷、合作夥伴頁面或印刷 QR Code，也適用。

代理商等級的工作流

安全的流程不複雜，但不能到上線前才補：

1. 盤點所有仍可能帶來有效流量的 URL 來源
2. 依商業風險與 SEO 風險分類 URL
3. 建立含負責人、審閱狀態與決策備註的 redirect map
4. 匯入前先驗證對照表
5. 上線前匯入 batch，並測試代表性 URL
6. 上線後監控行為，並保留回滾路徑

試算表和遷移文件的差別在於責任歸屬。試算表只是保存列。遷移文件要能說明：誰核准了目的地、為什麼使用這個 HTTP 狀態碼、哪些參數必須保留，以及如果過大的規則誤傷一整組 URL，要如何回復。

從多個來源盤點 URL

不要只從 CMS 或電商後台匯出就認為盤點完成。平台匯出通常整齊，但最容易造成損失的 URL 往往不在裡面：舊廣告、LINE 訊息、EDM、聯盟連結、KOL 內容、合作夥伴頁面、印刷 QR Code，以及 Search Console 裡仍有曝光的舊 landing page。

至少應該整理這些來源：

小型網站可能只需要一份審閱過的 CSV。大型電商或多品牌專案可以依來源保留工作檔，但真正發布的應該只是一份合併後、已驗收的 redirect map。

使用能回答營運問題的 Redirect Map

代理商的對照表不能只有 old_url 和 new_url。這兩欄足以建立重新導向，但不足以讓客戶、SEO、行銷與工程團隊相信這是可上線的決策。

建議使用這類欄位：

old_url,new_url,status,priority,owner,query_policy,rule_type,review_status,notes
https://old.example.tw/pricing,https://new.example.tw/pricing,301,high,marketing,preserve,exact,approved,主要詢價路徑
https://old.example.tw/blog/legacy-guide,https://new.example.tw/resources/guide,301,medium,seo,preserve,exact,needs-review,內容整併中
https://old.example.tw/products/*,https://new.example.tw/shop/*,301,high,ecommerce,preserve,wildcard,approved,商品 path 結構保留

這樣的格式可以回答上線前一定會出現的問題：

• 這是永久遷移，還是暫時活動調整？
• 目的地是否符合使用者意圖，還是只是方便導到首頁？
• query string、UTM、折扣碼與聯盟 ID 是否要保留？
• 規則是 exact、wildcard 還是 regex？
• 商品下架、分類合併、內容刪除的例外由誰核准？
• 哪些列還不適合進 production？

如果這些答案不在對照表裡，團隊就會在上線窗口內重新補判斷。

匯入前先依風險分層

不是每一列都需要同樣深度的審閱。3 萬、6 萬、10 萬筆 URL 的 map，只要把關鍵 URL 和機械式規則分開，就能管理。

很多代理商遷移會在這一步失控。wildcard 可以處理數千筆 URL，但也可能掩蓋十個真正影響營收、外部連結或廣告預算的頁面。wildcard 和 regex 是加速工具，不是取代審閱的工具。

成為路由層前先驗證

驗證應該做兩次：匯入前的靜態檢查，以及規則在 staging、preview 或受控環境運作後的行為檢查。

匯入前先檢查：

• old_url 是否重複
• destination 是否為空或格式錯誤
• protocol 或 hostname 是否錯誤
• 舊 URL 是否已經經過另一個 redirect
• destination 是否回傳 404、410、5xx 或非預期 redirect
• wildcard 是否與 exact rule 重疊
• regex 是否太寬或沒有 anchor
• query string 行為是否會破壞活動報表

匯入後要測實際行為，不只是語法。用 Redirect Checker 測代表性 URL；大型遷移則 crawl 全部 batch。

QA 的目標不是「有 redirect」。目標是「舊 URL 能以預期狀態碼到達最合適的新 destination，沒有 chain、沒有 loop，也沒有遺失重要參數」。

像 Release 一樣規劃上線日

代理商專案的上線日不是善後。團隊需要知道誰看哪些訊號、什麼時候判斷、誰可以暫停、修正或回滾。

回滾不一定是撤回整個遷移。很多時候是關閉某個 batch、還原上一個 snapshot，或用優先級更高的 exact rule 覆蓋錯誤 pattern。重點是這條路要在上線前就決定好。

代理商最容易浪費時間的錯誤

匯入沒有決策的列

如果某一列沒有負責人或審閱狀態，不要把它藏在 batch 裡。標記為未解決，等有人核准目的地後再進 production。

把下架內容全部導到首頁

首頁看起來安全，因為它通常能正常回應。但對使用者體驗和遷移連續性來說常常很弱。下架商品可能更適合導到替代商品、分類頁、客服文章或清楚的停售說明頁。

讓多個層級同時擁有同一條 redirect

客戶環境可能同時有 Nginx、Apache .htaccess、Cloudflare、SHOPLINE、Shopify、WordPress、SEO 外掛與 app middleware。若代理商不先決定哪一層負責遷移 redirect，debug 會變慢，責任也會模糊。

忘記活動與聯盟參數

redirect 在 crawler 裡看起來正確，也可能破壞報表。請用 utm_source、utm_medium、utm_campaign、折扣碼、聯盟 ID、LINE 活動參數，以及客戶 stack 實際使用的 query 來測試。

UrlEdge 的位置

當 redirect map 太重要，不適合藏在 server config 或 CMS 外掛裡時，UrlEdge 更適合。基本流程如下：

1. 建立並核准 map
2. 用 Bulk URL Management 匯入規則
3. 用 Redirect Checker 驗證高風險 URL
4. 把已審閱 snapshot 發布到 edge
5. 監控流量並保留 rollback

永久遷移可搭配 Permanent 301 Redirects。如果 inherited stack 裡有多層舊 redirect，整理時請搭配 Redirect Chains and Loops。若遷移包含換域名，也請參考 不遺失 path 與 UTM 參數的網域重新導向。

價值不只是 redirect 在 edge 上執行。對代理商來說，真正的價值是讓遷移工作變得可審閱、可測試、可發布，而且必要時可復原。

FAQ

每次遷移都要用 301 嗎？

不一定。永久 URL 遷移通常使用 301 或 308。臨時活動調整更適合 302 或 307。狀態碼應該反映商業意圖，而不是設定習慣。

多少條 redirect 開始不適合手動設定？

沒有通用數字。警訊是：審閱、負責人、驗證、analytics 和 rollback 已經比語法本身更重要。這時專用 workflow 會比多處手動修改更安全。

舊 redirect 需要長期保留嗎？

重要遷移 URL 應長期保留。外部連結、舊 EDM、印刷 QR Code、合作夥伴文件和使用者書籤，都可能在遷移很久後繼續帶來流量。

一條 wildcard 能取代大型 CSV map 嗎？

有時可以。當新舊 path 結構明確對齊時，wildcard 很有效。高價值頁、下架商品、合併分類，以及需要判斷最佳目的地的情況，仍應保留明確 mapping。

參考資料

• Google Search Central: Site move with URL changes
• Google Search Central: Redirects and Google Search
• MDN: Redirections in HTTP