SEO 遷移檢查清單之所以存在，是因為損害都發生在安靜的地方。新伺服器運作正常、頁面載入正常，三週後曝光卻掉了，而且沒有人說得出是哪個步驟壞了。大多數時候，它是四種完全不會產生任何錯誤訊息的失敗之一。
自 2017 年起，我們就一直在主機之間搬遷網站，其中包含天問網路的一個專案：一次作業就把 49 個外銷網站從管理式主機搬到自建 VPS。同樣的網域、不同的伺服器，總成本下降超過一半。下面這份檢查清單，就是我們會交給想自己動手的人的東西。
首先，說清楚你在做哪一種遷移
每一次搬遷的風險都不一樣，計畫裡應該寫明這次是哪一種。
- 換主機。 同一個網域、同樣的 URL、不同的伺服器。風險最低。主要危險是 DNS 生效時間、郵件，以及仍在提供舊站內容的快取。
- 換網域。 風險最高。每個 URL 都會改變，每個反向連結都指向別處，而且你需要在 Search Console 做「變更地址」的步驟。
- 換平台。 重建 CMS 通常會同時改變 URL 樣式與頁面範本，即使外觀設計是照抄的也一樣。
- URL 結構變更。 新增或移除語言前綴、把 http 改成 https、改變結尾斜線或目錄層級。即使內容和伺服器都沒動，這也算一次遷移。
開始之前先講清楚是哪一類，因為這決定了後面哪些步驟是必須的、哪些只是好習慣。
搬遷前：凍結、盤點、建立基準
基準資料是大家最常跳過、事後最後悔的部分，因為沒有它，你根本分不清變化是不是遷移造成的。從 Search Console 匯出最近 16 個月的資料：查詢、頁面、國家、裝置。存下目前的 sitemap 並計算 URL 數量。記錄哪些頁面承載了你在意的曝光。
對檔案和資料庫做完整備份，並趁環境還在你眼前時把它寫下來——PHP 版本、資料庫版本、啟用中的外掛及其版本、cron 項目，以及郵件設定。那份清單就是你重建的依據，也是回復原狀的參考。
接著在切換前 24 小時凍結發佈。在遷移過程中發佈的文章可能只進到舊資料庫，這是一種讓人白忙一個下午的混亂方式。
還有一件事要放在這裡。如果網站把備份副本放在網站根目錄裡，搬遷前先清掉。我們曾經在一個佈景主題目錄裡發現 36 個 .backup 檔案，全部都可以被公開下載。遷移正是停止把它們重新發佈到新伺服器的自然時機。
URL 對照表就是遷移本身
如果網域改變或 URL 樣式改變，從舊 URL 到新 URL 的對照表就是最重要的單一產出物。在切換前用試算表建好，每個舊 URL 一列，而且只能有一個目的地。能保留同一個 URL 就保留——遷移後最安全的 URL，就是從來沒變過的那個。
URL 必須改變時，用單一 301 重新導向到最終目的地。兩、三個串接的重新導向會浪費檢索預算並稀釋訊號。永久搬遷不要用 302。注意會破壞對照的細節：結尾斜線、大寫字母、分頁與篩選 URL 上的查詢字串，以及 www 與非 www 的形式。Google 關於搬遷網站與變更 URL的說明很短，在建立對照表之前值得讀一遍。
在清除快取之後測試重新導向，而不是之前
這就是燒到過我們的陷阱。快取回傳的 200 不算通過測試。如果伺服器快取或 CDN 還留著舊回應，每一項檢查都會通過，而每個使用者看到的仍是舊站。先清除伺服器快取和 CDN，然後再測試。
用腳本對整份清單測試，不要只抽查五個 URL。跟著重新導向走，記錄最終 URL 以及每一跳的狀態。你要的輸出是一張表，每個舊 URL 都一跳就解析到預期目的地，最後是 200。
四種會無聲出錯的情況
這些都不會跳出錯誤。每一個都讓我們或客戶付出了真實的時間。
1. 凍結的 sitemap 檔案
有些 SEO 外掛會把 sitemap 快取成檔案，並持續提供那個檔案，直到計時器到期。後台畫面顯示綠色勾勾，但它提供的檔案已經好幾週舊了，而且檔名通常不含 “sitemap” 字串，所以在檔案系統裡搜尋也找不到。解法是在搬遷後刪掉快取檔案讓它重建，然後在 Search Console 確認 sitemap 的下載日期與 URL 數量是最新的。不要相信外掛的勾勾，去看時間戳記。
2. 沒有一起跟過來的 Cron
換主機等於重建環境，排程任務很容易被遺漏。如果設定裡停用了 WP-Cron，又沒有系統 cron 接手，排程文章就會永遠停在 “Scheduled”，而且沒有任何警示。驗證方法很簡單：排一篇一分鐘後發佈的測試文章，看它會不會真的發佈。
3. Canonical 與 hreflang 仍指向舊 URL
在多語言網站上，這些標籤是產生的，而產生的標籤在搬遷後可能又生出舊 URL。逐一檢查每個語言版本的 canonical 是否自我指向、hreflang 是否互相對應，並確認整組裡的每個 URL 都回傳 200。Google 關於多區域網站的文件，對於標籤必須如何配對有明確說明。
4. 表單與郵件不再送達
即使網站一切正常，DNS 與郵件記錄仍是遷移的一部分。換網域時，表單可能送出成功卻寄不到任何地方。換主機時，如果網站是透過不同位址被存取，綁定網域的防垃圾郵件金鑰可能就停止驗證。我們稽核過一個網站，它的表單已經無聲失效 12 天，因為它的 reCAPTCHA 金鑰註冊在另一個網域；在有人發現之前，已經有 207 次付費點擊落在上面。用手機送出一封真實的測試訊息並確認它送達，搬遷後做一次，一週後再做一次。
DNS、TTL 與憑證
至少在切換前 24 小時把 DNS TTL 調低到幾分鐘，讓切換能快速傳播。在新伺服器驗證完成、且 TTL 完全過期之前，讓舊伺服器持續運作並保持上線。不要在切換當天取消舊主機，那是你的退路。
在切換前於新主機上簽發 TLS 憑證，並事先決定要用哪個標準主機名稱。然後讓其他形式重新導向到它。伺服器位置對國際目標市場來說是弱訊號——Google 看的是網域、hreflang 設定和內容本身，而 CDN 讓位置幾乎無關緊要——所以不要讓主機地區的決定凌駕於遷移計畫之上。
搬遷後：依固定順序驗證
下面的順序會依照這些失敗原本會讓你措手不及的先後次序，一一抓出它們。
- 每個已對照 URL 的 HTTP 狀態。 一跳、目的地正確、最後是 200。
- robots.txt 與 sitemap。 確認兩者都能載入，接著在 Search Console 查看 sitemap 真正的下載日期並重新提交。
- Canonical 與 hreflang。 自我指向、互相對應、全部 200。
- 渲染。 JavaScript、CSS 與字型都能載入；行動版版面和你原本的一致。
- 速度。 測量重要頁面的首位元組時間（TTFB）。換主機是修好基礎架構問題最便宜的時間點——在我們其中一個網站上，替 nginx 加一層快取，就把 TTFB 從 2.14 秒降到 0.067。
- 表單與郵件。 用手機送一封測試訊息到收件匣，然後也檢查垃圾郵件資料夾。
- 變更地址 若網域有變更，在 Search Console 中執行。這是必要步驟，不是選用步驟。
預期的是延遲的重新檢索，而不是立即回復
遷移後的檢索關注度並不平均，它取決於網站的歷史，程度不亞於取決於新伺服器。2026 年 9 月 22 日，我們檢視了自己在同一個機器上的三個網站。其中一個首頁前一天才被檢索，那週發佈的頁面已經被索引。另一個則是最後一次檢索在十天前、sitemap 在十四天前，而在這期間發佈的三個新頁面 Google 仍不知道——“Google can’t recognize this URL”。同樣的伺服器、同一天，結果卻不同。
所以不要在第三天就評斷這次遷移。用四到六週觀察兩個數字：依 URL 類型分的索引率，以及新主機的檢索統計。如果索引率在下降而重新導向對照表沒問題，在動其他任何東西之前，先找找有沒有誤加的 noindex、robots.txt 封鎖，或是指向舊網域的 canonical。如果它持平而重新導向都能解析，那這次遷移是成功的；剩下的只是讓頁面被重新檢索的日常作業。
實際上會壞的是什麼，又多久會看到？
可見的症狀出現順序相當一致。幾小時內，重新導向或憑證問題會以錯誤的形式出現。一天內，郵件與表單會自己現形，通常是因為有人沒收到訊息。一週內，隨著檢索在新主機穩定下來，sitemap 與 canonical 的錯誤開始造成影響。索引與曝光變化最慢，卻是大家最先恐慌的。
所以這條時間軸就是倒著讀的檢查清單。先修好立刻會壞的東西，再觀察需要數週才會顯現的東西。如果重新導向錯誤和一點曝光下滑在同一個早上出現，它們不是同一件事，把它們當成同一件事，就是團隊開始一次改三個變數的起點。
回復原狀的選項保留 30 天
舊伺服器、舊 DNS 記錄與遷移前的資料庫，至少保留一個月。在切換前就寫好回復指令，不要等第一個警報響了才寫。如果索引率崩掉、一天內又找不到原因，把 DNS 指回去是合理的做法，而把這條路寫下來，能讓它成為一個決定，而不是一場恐慌。
關於新主機的規格，有一個我們用慘痛代價學到的提醒。一台單核心、1 GB 的機器跑三個 WordPress 網站會不穩，原因不是網站數量，而是 PHP 的記憶體上限被設成 1024 MB——比機器本身擁有的還多。把它設成 256 MB，並把 PHP worker 從 6 個降到 4 個，就恢復正常了。單一 PHP 行程實測為 80–124 MB，所以這種算術很容易往大方的方向算錯。
一頁版檢查清單
| 階段 | 必做事項 | 能證明它已完成的驗證 |
|---|---|---|
| 搬遷前 | 匯出基準資料、完整備份、環境清單、凍結發佈 | 基準檔案有日期，且存放在伺服器之外 |
| 搬遷前 | URL 對照表，每個舊 URL 一個目的地 | 每一列都有目標與狀態 |
| 搬遷中 | 調低 TTL、簽發憑證、讓舊伺服器保持上線 | 切換前憑證已在新主機生效 |
| 搬遷後 | 清除快取，然後端到端測試重新導向 | 以腳本驗證一跳 301 到最後 200 |
| 搬遷後 | 重建 sitemap 快取，確認真正的下載日期 | Search Console 顯示今天的日期與正確數量 |
| 搬遷後 | Canonical、hreflang、表單、郵件 | 測試訊息已收到；標籤自我指向 |
| 搬遷後 | 若網域有變更則執行變更地址 | Search Console 確認提交 |
| 四週後 | 將索引率與檢索統計與基準比較 | 依 URL 類型分的索引率持平或上升 |
每一個項目背後的模式都一樣：設定看起來可以正確，網站行為卻可能是錯的。要驗證的是結果，不是設定。搬遷後浮現的索引問題，和我們對一般網站執行的是同一套——請見12 點稽核與我們自己網站的索引測試。兩者都彙整在研究索引。
關於 SEO 遷移的常見問題
最重要的單一遷移步驟是什麼？
URL 對照表，只要有任何 URL 改變的話。每個舊 URL 一列，且只能有一個最終目的地，在切換前建好。能保留同一個 URL 就保留。再來，在測試重新導向之前先清除快取，是能抓到最多無聲失敗的步驟。
為什麼換主機之後我的排名掉了？
常見原因是重新導向解析錯誤、sitemap 仍在提供快取檔案、canonical 或 hreflang 標籤用舊 URL 重新產生，以及表單或郵件路徑停止送達。症狀出現的時間點有助於判斷：錯誤在幾小時內出現，郵件在一天內，索引則要數週。
遷移後要多久才會恢復？
檢索關注度並不平均，取決於網站的歷史。在同一個伺服器、同一天，我們看過一個首頁前一天才被檢索、新頁面已被索引，另一個則最後一次檢索在十天前、新頁面 Google 仍不知道。請用四到六週觀察索引率。
切換後應該馬上取消舊主機嗎？
不應該。舊伺服器、舊 DNS 記錄與遷移前的資料庫至少保留 30 天。如果索引率崩掉、一天內又找不到原因，把 DNS 指回去是合理的做法，而寫下來的回復路徑能讓它成為一個決定，而不是一場恐慌。
誰寫的，以及怎麼查證。 作者：劉宇，天問網路（河南天問網路科技有限公司，2017 年 5 月 3 日註冊；中國鄭州；UTC+8）創辦人。天問網路自 2017 年起為 B2B 製造商建置與維護 WordPress 外銷網站並執行 Google SEO，目前維護 30–40 個客戶網站，以及自家的研究網域。本頁每一個數字，都是在我們營運的網站上實測，或連向它的來源。我們不承諾排名，也不承諾詢價數量。聯絡方式：WhatsApp +86 135 2681 6415。
本頁由英文版機器翻譯，尚待人工審核。