CMS 遷移屬於少數幾類專案：技術面可以做得毫無差錯，結果卻仍然是一場災難。網站按期上線，外觀更好看，載入也更快，流量卻掉了一半，原因是幾百條網址換了形狀，而沒有人去做那張對照表。技術驗收一項項全過，商業結果卻是負的。

掉掉的流量並不是新平台造成的，而是斷裂造成的：以前能回應的網址現在不再回應，以前認得出來的頁面現在看起來像全新的，多年累積在舊網址上的歷史也失去了去處。而且排名往往不是上線當天就掉下去，而是在接下來的幾週裡慢慢往下沉，所以上線當天看起來一切正常，並不能說明任何事情。

決定結果的只有一個判斷：你要保留 URL 結構嗎？ 如果保留，遷移基本上就是一件內容與範本的工作，風險有限。如果不保留，每一條變動過的網址都需要一條指向其具體對應頁面的重新導向，而這張對照表做得有多完整，決定了這次遷移是悄無聲息地過去，還是變成一筆昂貴的帳。不存在第三種情況：網址全換了，結果還能碰巧沒事。

CMS 遷移到底會弄壞什麼

網址，這是最大的一項。不同平台在路徑、分頁、分類與日期上的慣例各不相同，一旦照單全收新平台的預設設定，網站上的每一條網址都會被悄悄改寫。有時只是分隔方式變了一點，或者日期多了一段少了一段，整個網站就換到了另一套網址體系上。

中繼資料。 多年來一句句寫出來的標題與描述，常常撐不過一次匯出，新平台會改用範本自動產生它們。這一點特別容易漏掉，因為頁面本身看起來完全正常。

結構化資料。 舊平台上由外掛加上去的標記會隨著外掛一起消失，新平台的對應功能很少能輸出一模一樣的結果。我們關於 AI 搜尋引擎如何讀取 Schema 標記 的指南寫清楚了哪些東西必須活下來。

內部連結。 內文裡那些指向舊路徑的絕對連結，遷移之後仍然指著舊路徑。網址一變，這些連結最好的結果也是要多走一次重新導向，最差的結果是在你自己的網站裡撞上一個不存在的頁面。

圖片與媒體檔案。 儲存路徑不一樣，檔名不一樣，還有那些只存在於舊資料庫、根本沒進匯出檔的替代文字。

外掛替你做過的所有事。 多年間陸續設定的重新導向、標準網址規則、訂閱來源格式，以及那些因為只是一個核取方塊而從來沒人寫進文件的功能。

這些都要在遷移之前盤點，而不是之後。舊平台默默替你處理掉的那份清單，永遠比你預想的長。

重新導向對照表決定一切

如果網址會變，這就是唯一真正要交付的東西，而且必須是完整，不是接近完整。

來源清單要從不只一個地方拼出來。檢索線上網站，能找出被連結到的頁面。分析工具與 Search Console 能找出有流量、卻可能已經沒人連結的孤兒頁面。伺服器記錄檔能找出真正被請求的東西，包括從別的網站連過來的那一部分。任何單一來源都會漏，而且漏掉的，往往正是那些年份久、身上掛著外部連結的老頁面，而它們恰恰是最值得保住的一批。

給每一條舊網址指定它具體對應的新網址。不是首頁，也不是分類頁，因為一條指向答非所問位置的重新導向會被當成軟性錯誤處理，幾乎傳不過去什麼價值。Google 關於網站搬遷的說明文件寫明了它期望的對應關係。如果確實沒有任何東西與它對應，那麼回傳一個找不到頁面的回應才是誠實的答案，比一條誤導性的重新導向更好。

使用永久重新導向，把舊網址直接指向最終目的地，讓轉址鏈保持在一次之內。同時記得重新導向規則是按順序評估的，一條寬鬆的規則放在具體規則上面，就會把後者整個吃掉。

然後在上線之前測試這張表，針對全部清單，而不是抽樣。把每條網址最後落到哪裡、回傳什麼狀態碼都記錄下來，上線之後的比對會輕鬆得多。

切換之前

檢索並封存舊站。 一份完整的紀錄，包含每一條網址的標題、描述、標準網址、狀態碼與字數。這是你的比對基準線，事後再也補不出來。

匯出內容並逐項核對。 要數數量，而不是只確認匯出跑完了。分類遺失、自訂欄位掉落、文章被截斷，這些都很常見，而且都不出聲：匯出程式會安安靜靜地跑完，然後回報成功。

放在被封鎖的環境裡預演。 一個會被建立索引的測試站台，等於把整個網站複製了一份放出去，這個問題比你原本要解決的那個更嚴重。

檢查新範本輸出的東西和舊範本一致。 標題、描述、標準網址、結構化資料，如果你在經營多語言網站，還要包括 hreflang，我們的多語言 SEO 指南裡談過這一段。

安排好時間點。 不要放在最忙的旺季之前，也不要放在星期五。切換之後你需要連著幾個工作日的完整注意力，而且要有能當場發布和修改的人，不是只在旁邊看著的人。

切換之後

頭四十八小時比接下來的一整個月更重要，因為在這段時間裡，還能修的錯誤依然便宜。

盯住伺服器記錄檔裡找不到頁面的回應。這是找出對照表遺漏了哪些網址最快的辦法，而且它是從真實請求裡找出來的，不是從你的假設裡推出來的。提交新的 Sitemap，然後確認檢索真的在發生，而不是預設它在發生。

和基準線的檢索結果做比對。之前可以被建立索引的每一條網址，現在要麼能回應，要麼會重新導向到一個具體的地方。兩樣都做不到的，就是一個破口，值得在它變成永久性的排名損失之前補上。

要預期到一段下滑。就算遷移做得漂亮，幾週之內的波動也是正常的，因為新網址需要被重新檢索、重新評估，而這個過程要按週算，不是按天算。不正常的是持續下跌而且不回升，而這幾乎總能追回到兩件事上：漏掉的重新導向，或者指向某個籠統頁面的重新導向。

重新導向要永久保留。它們不是過渡措施，而是把多年累積的連結和你現在的頁面接起來的唯一東西。一年之後把它們撤掉，等於把當初那次損失原樣再做一遍。

Mecanik 把這類遷移當作網站開發工作的一部分來承接。模式一直是同一個：換平台本身是例行公事，好結果和壞結果之間的全部差別，都落在那張對照表做得有多完整上。

常見問題

為什麼換了 CMS 之後流量會下滑？ 幾乎總是因為網址變了，而重新導向對照表不完整。舊網址不再回應，多年累積的連結與檢索歷程就失去了去處。造成損失的很少是平台本身，而是新舊網址之間的那道斷裂。

換 CMS 的時候應該保留 URL 結構嗎？ 只要能保留就保留。保留結構會把遷移壓縮成一件內容與範本的工作，風險有限。改動結構則意味著每一條變過的網址都需要一條指向其具體對應頁面的重新導向，而這套對照做得有多完整，決定了遷移是悄無聲息地過去，還是變成一筆昂貴的帳。

需要重新導向的網址清單從哪裡來？ 從多個來源來，因為任何一個來源都會漏。檢索線上網站能找出被連結到的頁面，分析工具與 Search Console 能找出有流量但可能已成孤兒的頁面，伺服器記錄檔能找出真正被請求的東西，包括來自外部連結的請求。單一來源漏掉的，往往是那些身上掛著外部連結的老頁面。

可以把舊頁面重新導向到首頁嗎？ 不可以。一條指向答非所問位置的重新導向會被當成軟性錯誤處理，幾乎傳不過去什麼價值。給每一條舊網址指定它具體對應的頁面；確實沒有對應內容的地方，回傳找不到頁面的回應比一條誤導性的重新導向更誠實，也更有用。

遷移用的重新導向要保留多久？ 永久保留。它們不是過渡措施，而是多年累積的外部連結和你現在頁面之間唯一的連接，所以一年之後把它們撤掉，等於原樣重現這次遷移本來要避免的那場流量損失。