WordPress 搬家搬到掉排名，多半不是因為檔案沒傳完，而是因為資料庫裡的網址被錯誤的方式改過。一般的靜態或手寫網站，把檔案複製過去、資料庫匯入、DNS 一切就結束了；WordPress 多出三件事會在這個環節翻車：整個資料庫裡散佈著寫死的絕對網址、所有連線設定集中在 wp-config.php 這一支檔案、以及內頁能不能開完全取決於 .htaccess 裡那一段重寫規則。這三件事處理錯，網站不會漂亮地「壞掉」讓你馬上發現，而是首頁正常、內頁 404、部分設定悄悄變成空值。
先劃清範圍：搬家的通用順序——先盤點帶得走什麼、DNS TTL 什麼時候調短、信箱與 MX 怎麼一起處理、SSL 怎麼重新簽發——我們已經寫在網站搬家怎麼搬才不出包，想要一份可以列印出來逐項打勾的版本則見網站搬家檢查表 20 項。這篇只寫 WordPress 比一般網站多出來的部分，通用步驟不重述。
WordPress 搬家比一般網站多出來的三件事
| 多出來的事 | 為什麼一般網站沒有 | 沒處理好的後果 |
|---|---|---|
| 資料庫裡到處是絕對網址 | WordPress 把站台網址存進 wp_options 的 siteurl／home，文章內容、附件路徑、佈景與外掛設定裡也各自存了完整網址 |
換網域後圖片全破、後台一登入就被導回舊網址、部分設定讀不出來變成預設值 |
| wp-config.php 是連線與常數的集中點 | 資料庫帳密、資料表前綴、鹽值、除錯開關、快取常數全部寫在同一支檔案，而且它通常不在版本控制裡 | 照抄舊的就連不上新資料庫；漏抄資料表前綴則「資料庫明明有資料，網站卻要求重新安裝」 |
| 永久連結靠 .htaccess 的重寫規則撐著 | 內頁網址不是實體檔案，要靠重寫規則轉給 index.php 處理 | 首頁正常、所有內頁 404。這是搬完最常見的第一個症狀 |
這張表也是驗收時的分診表：首頁開得起來、內頁全 404 ＝ 第三項；後台一直被導回舊網址 ＝ 第一項；整站要求重新安裝 ＝ 第二項。症狀對得起來，就不必從頭亂查。
七個步驟的正確順序
| 步驟 | 做什麼 | 怎麼驗這一步做完了 |
|---|---|---|
| 1 | 盤點：WordPress 版本、PHP 版本、外掛與佈景清單、資料庫容量、wp-content 的檔案數與容量、是否為多站台 | 清單寫下來，新主機規格逐項對得上 |
| 2 | 打包 wp-content（不要逐檔傳整站） | 打包檔的大小與原目錄容量相近 |
| 3 | 匯出資料庫（mysqldump 或後台匯出工具） | 匯出檔尾端有完整的結束標記，不是被截斷的半份 |
| 4 | 新主機先把 PHP 版本調成與舊站相同，再解包與匯入 | 用相同版本先確認站台能開，之後才談升版 |
| 5 | 網址取代（只有換網域時才需要，見下一節） | 取代工具的報告列出改了幾筆、哪幾張表 |
| 6 | 用 hosts 檔把網域指到新主機，在不切 DNS 的情況下驗整站 | 首頁、內頁、後台、表單都正常，舊站同時照常運作 |
| 7 | 短暫凍結後台、重新匯出一次資料庫覆蓋、切換 DNS、舊主機續留 | 切換後兩邊都開著，訪客不會看到錯誤頁 |
第 2 步的實測：打包的意義不在壓縮率，在往返次數
很多人以為打包壓縮是為了「縮小體積、傳快一點」。我們在自己的主機上量過一次，結果不是這樣。以本站的網站目錄為樣本，共 4,616 個檔案、224,818,461 bytes（約 214 MiB）：
| 方式 | 產生的檔案大小 | 耗時 | 相對原容量 |
|---|---|---|---|
| tar 打包、不壓縮 | 228,239,360 bytes | 1 秒 | 101.5% |
| tar 打包 + gzip 壓縮 | 186,137,253 bytes | 6 秒 | 82.8% |
壓縮只省下 17%，卻多花了 6 倍時間。對以圖片為主的 WordPress 站（wp-content/uploads 通常就是這種組成），打包的價值不在壓縮，而在把「4,616 次逐檔傳輸的往返」變成「1 次大檔傳輸」。逐檔傳的瓶頸從來不是總容量，是每個檔案各自的連線建立、權限設定與確認往返；檔案數越多差距越誇張。所以步驟很清楚：在舊主機上打包成一個檔（趕時間就別壓縮）、傳一次、在新主機上解開。這也是為什麼搬家前要先確認新舊主機都給得到 SSH 或相當的命令列權限——虛擬主機做得到哪些事，我們逐項寫在虛擬主機能做到什麼。
第 4 步：PHP 版本先對齊，不要邊搬邊升級
搬家當下同時升 PHP 版本，是把兩個變數綁在一起：站台開不起來時，你分不清是搬家漏了東西，還是某支外掛不相容新版 PHP。正確順序是先用與舊站相同的版本把站搬起來、確認一切正常，再擇日單獨升版。前提是新主機的版本要選得到——我們的主機上並存 15 個 PHP 版本（ea-php53 到 ea-php85），可以逐個目錄各自指定，挑主機時該看哪些規格整理在WordPress 主機怎麼選。升版之後值得順手做的效能檢查，另外整理在WordPress 網站很慢怎麼辦。
網址取代為什麼不能直接用 SQL replace？
先講一個能省掉整節麻煩的判斷：如果只是換主機、網域完全不變，那你根本不需要做網址取代。資料庫裡存的網址本來就是對的，動它只會製造風險。這一節只適用於「搬家同時換網域」或「順便從 http 換成 https」的情況。
接著是那個讓很多人搬到一半資料變空值的原因：WordPress 的外掛與佈景設定，是以 PHP 的序列化格式存進資料庫的，而序列化格式會在每個字串前面記錄它的長度。用 SQL 的 REPLACE() 或文字編輯器對匯出檔直接取代，字串內容變了、前面的長度數字沒跟著變，整筆資料就還原不回來。
這不是理論。下面是我們在主機上實際跑的一段驗證，用一組模擬的外掛設定（存了站台網址與一張 logo 的路徑），把舊網域取代成新網域：
看第二段的 s:22:：新網址其實只有 18 個字元，長度前綴卻還停在 22。還原的結果是 false——整筆設定變成讀不出來，WordPress 讀到讀不出來的設定時通常就回退成預設值，畫面上看起來像是「設定自己不見了」。更麻煩的是它安靜：不會噴錯誤、不會中斷，你要等到某天發現某個區塊空白了，才回頭想是不是搬家那天弄壞的。
正確的做法是先把資料還原成陣列、在陣列層級取代、再重新序列化，長度前綴才會跟著更新。同一段程式這樣處理的結果是：
s:18: 與 s:46: 都對了，還原正常。實務上你不必自己寫這段程式，有兩類工具本來就是這樣做的：
兩種安全的取代方式
- 命令列工具 WP-CLI 的 search-replace：它會逐筆判斷資料是不是序列化格式並正確重算長度。我們的主機上裝的是 WP-CLI 2.12.0，搭配 PHP 8.5.10、MySQL 8.4.9。先加上 dry-run 參數跑一次，它會告訴你打算改幾筆、改在哪幾張表，數字看起來合理再實跑。
- 支援序列化的搜尋取代外掛：後台操作、適合沒有命令列權限的環境。同樣要先用它的預覽模式看筆數，不要直接按執行。
兩者都要在取代前先匯出一份資料庫備份。取代是不可逆的操作，做壞了能退回去的就只有那份備份。
取代範圍的兩個提醒
第一，取代要涵蓋的不只是 wp_options：文章內容與附件路徑、文章與分類的自訂欄位、使用者的個人設定、留言內容裡都可能有絕對網址，所以工具預設會掃全部資料表，不要自行縮小範圍。
第二，附件的 guid 欄位長得像網址，但它的作用是訂閱端用來辨識「這篇我看過了」的識別碼。換主機不換網域時完全不必動它；真的換了網域，也要先想清楚訂閱端會把舊文章重新當成新文章推送一次。取代工具通常有排除 guid 的選項。
切換 DNS 前後，保住排名的六件事
搜尋引擎那一端其實很寬容：網址不變、內容不變、伺服器回應正常，換一台主機它幾乎不會有反應。排名掉，多半是搬家時順手改了別的東西。以下三件在切換前做、三件在切換後做。
切換 DNS 之前的三件
- 網址結構一個字都不要改。永久連結的格式、分類與標籤的網址前綴、有沒有結尾斜線，全部抄舊站的設定。搬家那一次只做搬家。真的非改不可，就要同時準備一份舊網址對新網址的 301 對照表，而且那應該是另一次獨立的作業。
- 測試期間不要讓新站被索引。用 hosts 檔驗證是比較乾淨的做法，因為新站從頭到尾沒有對外可連的網址。若一定要用主機商給的臨時測試網址，記得加上存取密碼。這裡有一個常見的災難：有人為了測試而勾選了 WordPress 的「搜尋引擎可見度」選項，正式切換後忘記取消，等於主動請搜尋引擎不要收錄整個網站，而且從畫面上完全看不出來。這一項務必列進切換後的驗收清單。
- 舊站 .htaccess 的自訂規則逐條抄過去。除了 WordPress 自動產生的那一段重寫規則，很多網站的 .htaccess 裡還累積了歷年的 301 轉址、防盜連、快取標頭、擋特定檔案的規則。這些規則掉了不會有任何錯誤訊息，但過去累積的轉址權重會一起消失。
切換 DNS 之後的三件
- 拿搬家前的網址清單逐筆比對。最省事的來源是舊站的 sitemap，切換後把清單跑一遍，確認每一筆都回 200 而不是 404 或 500。內頁一旦大量 404，通常就是永久連結的重寫規則沒跟著搬。
- 看搜尋主控台的檢索統計與索引狀態。切換後的頭兩週，注意有沒有突然冒出一批「找不到（404）」或伺服器錯誤。這是最早能發現漏搬的訊號，比等排名掉下來再查早得多。
- 舊主機留到 TTL 全球到期之後。DNS 的快取時間決定了世界各地什麼時候看到新位址。舉例來說，本站網域的 A 記錄目前的 TTL 是 14400 秒（4 小時），代表某些解析器最長會沿用舊位址 4 小時；所以正確的做法是搬家前一到兩天先把 TTL 調短（例如 300 秒），切換完成、確認流量都進到新主機之後再調回去。這段期間舊主機不要關，讓還沒更新的訪客照樣看得到網站。DNS 各種記錄怎麼填，見中華電信 DNS 怎麼設定。
搬完當天的八項驗收
切換完不是結束。下面八項建議在同一天做完，每一項都有明確的判斷標準，不需要專業知識也驗得出來：
| # | 驗什麼 | 通過的標準 |
|---|---|---|
| 1 | 首頁、三個內頁、一個分頁、一個搜尋結果頁 | 全部正常顯示。內頁若 404，就是永久連結的重寫規則問題 |
| 2 | 後台登入與外掛狀態 | 能登入、外掛清單與舊站一致、沒有外掛顯示錯誤 |
| 3 | 上傳一張測試圖片 | 圖片顯示得出來，且檔案確實落在新主機的 uploads 目錄 |
| 4 | 送一封聯絡表單測試信 | 收得到。信箱是跟著網域走的，別假設它自己會搬 |
| 5 | HTTPS 與混合內容 | 瀏覽器沒有出現「部分內容不安全」的警告 |
| 6 | 「搜尋引擎可見度」選項 | 確認沒有被勾起來 |
| 7 | 快取外掛的設定檔 | 停用再重新啟用一次，讓它重新產生設定。舊的快取設定檔常寫死舊主機的實體路徑 |
| 8 | 排程工作 | 定期發布、備份、電子報這類排程有照常執行 |
第 7 項值得多說一句：快取類外掛會產生額外的設定檔，裡面寫的是主機上的實體路徑，而每家主機的路徑結構都不一樣。搬過去照舊留著，輕則快取失效，重則整站白畫面。搬家前先停用所有快取外掛、搬完再重新啟用，可以省掉這一類問題。
自己搬，還是交給主機商？
判斷標準不是技術難度，是「出事的時候誰有能力收拾」。上面七個步驟每一步都寫得出來，但實際搬的時候會遇到的是：舊主機的控制台跟教學畫面長得不一樣、匯出檔在匯入時因為容量限制中斷、外掛授權綁定網域要重新啟用、公司信箱同時要搬而且不能漏信。這些都不難，只是耗時，而且多半發生在你已經把切換時間公告給同事之後。
我們的做法是把搬家併進網站代管的範圍：由同一組人負責主機、搬移與後續維運，出問題不必在設計商、主機商與 IT 之間轉三手。如果連網站本身也打算一起重做，網頁設計與主機在同一個環境開發部署，可以直接省掉搬移這一段；把設計、主機、代管放在同一個窗口的一條龍服務，價值正是在這種跨環節的斷點上。至於各類型主機的年費行情，可對照主機租用費用一年多少。
最後提醒一件與技術無關、卻最常被忽略的事：搬家前先確認網域登記在自己名下、而且你握有可以修改 DNS 的帳號。網域不在自己手上，前面七個步驟做得再漂亮，最後那一步切不過去。這一類合約面的地雷，我們整理在低價一條龍服務隱藏的網站代管陷阱。
常見問題
Q：WordPress 搬家會不會掉排名？
只換主機、網域與網址結構都不變的情況下，正常搬完不會掉排名，搜尋引擎那一端幾乎察覺不到差別。真正會掉排名的是搬家時順手改掉了別的東西：永久連結格式換了、分類網址結構改了、測試期間「搜尋引擎可見度」被勾起來而且忘記取消、舊主機太早關掉導致 DNS 還沒全球生效就整站連不上、或是網址取代做壞讓內頁大量出現空白與錯誤。這幾項都不是搬家本身造成的，而是搬家順手改動造成的。所以原則很簡單：搬家那一次只做搬家，網址結構、佈景、外掛版本全部照舊，等新主機穩定兩週以上再談改版。
Q：WordPress 搬家可以只用搬家外掛嗎？
小型網站可以，中大型網站要有備案。搬家外掛的優點是把檔案與資料庫包成一包、匯入時自動處理網址取代，省掉手動步驟；缺點是它要在瀏覽器請求的時間限制內把整包產生出來，網站一大就容易在打包或還原到一半中斷，而且失敗時留下的半套狀態比手動搬還難收拾。判斷方式是看 wp-content 的容量與檔案數：只有幾百個檔案、幾百 MB 以內，用外掛通常順利；上萬個檔案或數 GB，建議改成檔案用打包傳輸、資料庫用 mysqldump 匯出、網址取代另外用支援序列化的工具處理。無論用哪一種，匯入前都要在舊主機留一份可以還原的完整備份。
Q：WordPress 搬家要停機多久？
照正確順序做，實際不可寫入的時間通常只有幾十分鐘，而不是整個 DNS 生效期間。做法是：先把整站搬到新主機並用 hosts 檔驗到能正常開，這段期間舊站照常運作、訪客無感；確認新站沒問題後才進入短暫的凍結期，公告暫停後台編輯、重新匯出一次最新的資料庫覆蓋新站，凍結期的長度等於匯出加匯入的時間；然後切換 DNS，舊主機繼續開著到 TTL 全球到期。訪客在 DNS 生效前連到的是舊站、生效後連到的是新站，兩邊都開著就不會看到錯誤頁。關鍵是搬家前一到兩天先把 DNS 的 TTL 從預設值調短。