WordPress 搬家教學：All-in-One WP Migration

想像你把整棟房子連同裝潢、傢俱、水電管線，原封不動搬到對街的新地基上，結果到了新址才發現大門口掛的還是舊門牌。客人照著舊地址找過來，撲了個空，還以為你倒閉了。WordPress 網站搬家最容易翻車的地方，從來不是「檔案搬不過去」，而是「東西搬過去了，卻沒有人找得到」。

WordPress 搬家可能涉及換主機、從本機上線、變更網域或同時調整多個環境。All-in-One WP Migration 是常見工具之一，可協助匯出與匯入網站，但實際步驟仍會受檔案大小、伺服器限制、擴充套件、網域與 SEO 設定影響；工具之外仍需要備份、測試與驗證。

先講結論：WordPress 搬家其實只有三個動作

不論你用的是哪一套外掛，WordPress 搬家的本質都拆不開這三個動作。把它們記在腦裡，後面所有工具操作你都看得懂：

1. 打包舊站：把檔案、資料庫、外掛、佈景主題、媒體庫全部封裝成一個可以帶著走的東西。
2. 在新主機拆箱還原：在新主機裝好空白 WordPress，再把那個封裝檔倒進去，讓新站長得跟舊站一模一樣。
3. 把門牌指過去：透過 DNS 與網域設定，讓原本打 你的網域.tw 的訪客改被帶到新主機，舊主機就此退場。

換句話說，All-in-One WP Migration 做的是第一步與第二步，第三步它完全不碰。很多新手以為按下「匯入」就等於搬家完成，其實那只是搬了一半。真正決定訪客與 Google 能不能順利找到新家的，是第三步，還有第三步之後的一連串驗證。

如果你只記得這篇文章的一句話，請記得這句：搬家前的備份，比搬家本身重要十倍；搬家後的驗證清單，比按下「匯入」那一刻重要十倍。

先搞清楚你是哪一種搬家

「WordPress 搬家」這四個字其實包了好幾種完全不同的情境，用的流程、風險等級、SEO 影響都不一樣。動手之前先對號入座，才不會把簡單的事搞複雜，或把複雜的事當簡單做。

搬家情境	換主機	換網域	主要風險	SEO 影響程度
純主機搬家（同一個網域）	是	否	DNS 切換時的短暫停機、設定遺漏	低（網址不變，理論上零影響）
主機＋網域一起換	是	是	舊網址要逐頁 301 到新網址	中高（做不好流量可能大幅下滑）
本地端推上正式網域	是（從本機到遠端）	是（從 localhost 到正式網域）	資料庫裡的絕對網址要全部替換	低（新站本來就沒有流量）
WordPress.com 搬到自架 WordPress.org	是	視情況	匯出格式限制、媒體要重新掛回	中（結構改變）

這篇文章聚焦在最常見的純主機搬家與主機加網域一起換這兩種情境，工具主角是 All-in-One WP Migration。如果你的需求是從 WordPress.com 搬到自架站，流程細節不太一樣，可以參考 WordPress.com 搬家到 WordPress.org 的完整教學；如果你是從本機 MAMP 環境推上線，本地端搬家到線上主機 那篇會更貼近你的情境。

為什麼要先分清楚？因為「換網域」這件事會牽動 SEO 最敏感的那條神經：網址。網址一變，等於 Google 眼中你是一個全新的網站，舊的排名、收錄、反向連結全部會被算到舊網址頭上。沒有做好 301 轉址，就是把自己的 SEO 資產丟在水裡。這件事我們後面會專門拉一個章節來講。

為什麼大多數人第一個想到的都是 All-in-One WP Migration

WordPress 在全球內容管理系統的市佔超過六成，這個生態裡光是搬家相關的外掛就有一拖拉庫。市面上的搬家外掛整理下來，Duplicator、Migrate Guru、UpdraftPlus 的搬家功能、WPvivid、All-in-One WP Migration，每一套都有它的支持者。但你在台灣的社團、論壇、教學文章裡問「WordPress 搬家用什麼」，十個有八個會吐出 All-in-One WP Migration 這個名字。

根據 W3Techs 的統計（2026 年 6 月），WordPress 在所有使用內容管理系統的網站中，市佔率長期超過 60%，這意味著幾乎每一個搬家的需求場景，背後都站著 WordPress 龐大的使用者基數，也造就了這類一鍵搬家外掛的市場。

它受歡迎不是沒有道理。把它的核心邏輯拆解來看：

• 把整站壓成一個檔案：檔案系統加資料庫，全部打包成一個 .wpress 匯出檔。你只要把這個檔案顧好，就等於顧住了整個網站。
• 匯入端不用預先設定資料庫：你只要在新主機裝好一個空白 WordPress，把外掛裝上去，匯入那個檔案，它會自動把資料表、選項、媒體全部填回去。對新手來說，這一點省掉的最大麻煩，就是不用手動改 wp-config.php。
• 自動處理序列化資料的網址替換：搬家最頭痛的「資料庫裡藏著舊網址」問題，外掛會在匯入時自動做字串替換，這是手動匯出匯入 SQL 最容易炸掉的地方。
• 介面極度直覺：一個頁面、四顆按鈕，沒有進階選項的選單地獄。

All-in-One WP Migration 在 WordPress.org 外掛目錄上架多年，安裝數與更新頻率都維持在一定水準，是它持續被信賴的基礎。

老實說，它不是最強大的，也不是最快的大型站搬家方案，但它是最不容易出錯的。對大多數中小型網站、形象站、部落格、甚至中小規模的 WooCommerce 商店，它就是那個「按下去了就會成」的工具。它的設計哲學是：用稍微笨一點、稍微慢一點的方式，換取最高的成功率。這在搬家這種「錯一次就要花一整晚救」的場景裡，是非常划算的取捨。

動手之前：三道保險缺一不可

最常見的翻車現場是這樣：開開心心按下「匯出」，然後在新主機匯入失敗，回頭才發現舊主機已經被自己改壞了。搬家前這三道保險，是任何團隊都該當成標準作業、不能跳過的前置作業。

第一道：做一份與搬家外掛無關的獨立備份

All-in-One WP Migration 本身就是打包工具，為什麼還要再多備份一份？因為打包與匯入過程都可能出錯，你需要在「完全獨立於這次搬家流程」的地方，留一份可以隨時回滾的乾淨版本。常見的做法是用 UpdraftPlus 做一次完整備份，把檔案與資料庫分開存到雲端，這份備份與 All-in-One WP Migration 的匯出檔是完全不同的兩份東西，互為保險。

如果你對 WordPress 備份的完整觀念還不熟，備份與還原的完整指南 裡有更系統性的整理。重點是：備份要存得夠遠（不要跟網站同一台主機），而且要確認還原流程真的跑得通。備份沒測過還原，等於沒備份。

第二道：確認新主機的環境符合 WordPress 需求

WordPress 對伺服器環境有明確的最低要求，新版尤其會拉高 PHP 與 MySQL 的版本門檻。很多人搬完才發現新主機的 PHP 版本太舊，整個站白畫面，這種低級錯誤完全可以事前避開。

WordPress 官方明確列出伺服器需求，包含 PHP、MySQL 或 MariaDB、HTTPS 支援等條件，搬家前務必逐一比對新主機是否達標。

具體要核對的項目：

• PHP 版本是否達到 WordPress 目前建議的門檻（舊主機沒升級不代表新主機預設就是新版，要主動確認）。
• MySQL 或 MariaDB 版本。
• 是否支援 HTTPS，以及是否提供免費 SSL 憑證。這一點在搬家後特別重要，後面 SEO 章節會再展開。
• PHP 的 upload_max_filesize、post_max_size、memory_limit、max_execution_time 這幾個值是否夠大。這直接決定你能不能順利匯入那個打包檔，是下一個大章節的主題。

如果你還在比較主機方案，可先看四種虛擬主機類型的比較，依網站流量、管理能力、備份與測試環境需求選擇。

第三道：開啟維護模式，避免搬家期間有人下單

這是最常被低估的一道。如果你跑的是 WooCommerce 或任何有即時交易、表單提交的網站，搬家那段時間如果還有訪客在線上下單、留言、填聯絡表單，這些資料會寫進舊主機的資料庫，而你打包的是更早的版本，結果就是這些訂單與訊息人間蒸發。

正規做法是：在低流量時段（通常是半夜）進行，並且在搬家前開啟維護模式或暫時把站設為「即將上線」狀態，把流量擋住。寧可讓訪客看到一小時的維護頁面，也不要承受丟訂單的風險。對交易型網站來說，這不是選配，是必要操作。

實戰：用 All-in-One WP Migration 一鍵搬家的完整流程

前置作業做完，正式進入搬家流程。這裡把它拆成「舊站打包」與「新站還原」兩個對稱的階段，每一步都附上實務上需要特別留意的地方。

階段一：在舊站匯出打包檔

1. 安裝並啟用 All-in-One WP Migration。從 WordPress 後台的外掛安裝頁面搜尋即可，外掛安裝 的標準流程。
2. 進入「匯出」>「檔案」。外掛會開始掃描你的整站，把檔案系統與資料庫打包。這個過程可能花上幾十秒到幾分鐘，取決於網站大小與媒體數量。
3. 選擇匯出目標為「檔案」。它也支援直接匯出到 Google Drive、Dropbox、FTP 等，但除非你的站大到本地下載困難，否則建議先用最單純的「下載到本機」，你才能親眼確認那個檔案真的存在、真的有大小。
4. 下載 .wpress 匯出檔。這個檔案就是你的整站快照，務必妥善保存。打包完成後，外掛會顯示一個下載連結，點下去把檔案存到本機。

一個小提醒：打包過程中如果畫面卡住或轉圈很久，通常是 PHP 的執行時間或記憶體限制撞到上限。遇到這種狀況不要狂重新整理，先去主機後台把 max_execution_time 與 memory_limit 拉高，再重試一次。網站越大，這個問題越容易出現。

階段二：在新主機還原

1. 在新主機安裝一個空白 WordPress。用主機商提供的一鍵安裝，或照著 WordPress 安裝教學 手動裝。這個空白 WordPress 只是個容器，它的佈景主題、設定之後都會被匯入檔覆蓋掉。
2. 在新站安裝並啟用 All-in-One WP Migration。版本要跟舊站一致，避免格式不相容。
3. 進入「匯入」>「檔案」，上傳剛剛下載的 .wpress 檔。外掛會開始解包，把檔案寫回、把資料庫倒回去、自動做網址替換。畫面上會跳出一個警告，告訴你這會覆蓋現有資料，確認即可。
4. 匯入完成後，登入新站的後台。注意，登入帳號密碼會被匯入檔覆蓋成舊站的，所以你原本設的空白站帳號會失效，要用舊站的帳密登入。這一點很多人會愣住，其實是正常行為。
5. 第一次登入時，WordPress 會要求你重新儲存固定網址。到「設定>固定網址」，什麼都不用改，直接按「儲存變更」，這個動作會觸發系統重新生成 .htaccess 與網址路由規則，是避免搬家後出現 404 的關鍵一步。固定網址的 SEO 結構如果還沒調整過，永久連結設定教學 可以一併參考。

到這裡，你的網站「內容」已經在新主機上還原了。但是先別急著開香檳，因為這個時候訪客打開你的網址，被帶到的還是舊主機。你只是把房子搬過去，門牌還掛在舊地址。接下來的網域切換，才是真正「搬家」的那一刀。

最常卡關的地方：上傳檔案大小限制

這一點值得特別獨立成一個章節來講，因為它是 All-in-One WP Migration 使用者碰壁率最高的一道牆，而且幾乎每個第一次用它的人都會撞上。學會怎麼繞過它，你的搬家流程才算真的順。

故事的發展通常是這樣：你在舊站開開心心匯出一個 300MB 的打包檔，到新站按下匯入，結果畫面跳出紅字，告訴你「上傳檔案超過伺服器的 upload_max_filesize 限制」，通常是 2MB、8MB 或 128MB。你的網站越大、媒體庫越多，打包檔就越大，撞牆的機率越高。這不是外掛的 bug，是 PHP 與伺服器的安全限制，外掛只能在這個上限內運作。

繞過這道牆，有幾條路可以走，底下依難易度排列：

方法	難度	適用情境	注意事項
修改 .htaccess 或 php.ini 拉高上限	低	你有權限改伺服器設定（多數虛擬主機適用）	改完要確認 post_max_size 與 upload_max_filesize 同時拉高，否則還是會被擋
從 URL 匯入（若目前版本或延伸模組支援）	低中	匯出檔可以先放到舊主機或雲端空間	舊主機要還在線上，且檔案要能被公開存取
使用 Unlimited Extension 提高大檔支援	中	商業網站、檔案經常超過 512MB	這是 ServMask 官方的付費延伸，一次購買支援多站
先手動把媒體庫搬走，再匯出精簡版	中高	網站超大，打包檔動輒好幾 GB	要熟悉 FTP 與資料庫操作，FTP 教學 是前置功課

若匯入檔超過限制，優先從主機控制台調整 upload_max_filesize、post_max_size、memory_limit 與執行時間，或請主機客服依檔案大小設定合理上限。不要直接把固定的 php_value 數值貼進 .htaccess：部分 Apache 組態會因此產生 500 錯誤，Nginx 也不讀取這個檔案。修改前先備份設定，完成匯入後再評估是否恢復原限制。

如果你的站大到連拉高上限都吃力，例如打包檔動輒好幾 GB，那就值得考慮 ServMask 官方的延伸模組，它針對大檔匯入與多種雲端儲存做了優化。

All-in-One WP Migration 提供一系列 官方延伸功能（Extensions），涵蓋大檔匯入、雲端儲存整合、多站支援等進階需求，由開發商 ServMask 維護。

其中 Unlimited Extension 是大站搬家時最常被點名的方案，它解除了免費版對匯入檔案大小的預設限制，對媒體庫龐大或長期經營的內容站來說，是一次投資、長期受用的選擇。

ServMask 的 Unlimited Extension 解除了免費版的檔案大小限制，並支援持續更新，是大型網站搬家的常見升級路徑。

實務上的取捨是這樣：如果是純內容站、媒體庫在 1GB 以內，免費版配 .htaccess 調整就綽綽有餘；一旦站大到有大量原始圖、影片、或 WooCommerce 商品圖，就值得直接上 Unlimited Extension，省下與檔案大小搏鬥的時間。時間也是成本，在搬家這種緊迫的場景裡尤其明顯。

WooCommerce 與超大網站：這個外掛的極限在哪裡

All-in-One WP Migration 不是萬能的。它設計的初衷是服務中小型網站，當你的站大到一個程度，它會開始力不從心。知道它的極限，你才知道什麼時候該換工具，免得硬幹到天亮。

WooCommerce 商店的特殊風險

WooCommerce 是 WordPress 生態裡最大的電商外掛，全球使用量相當驚人。

W3Techs 的數據顯示，WooCommerce 在所有使用電商系統的網站中，市佔率長期名列前茅，是 WordPress 生態最具代表性的電商解決方案。

WooCommerce 搬家最主要的風險是交易資料的即時性。訂單、庫存與顧客資料會持續變動，匯出到切換之間若仍有交易，新舊站就可能不一致。網址替換也要使用能安全處理 WordPress 序列化資料的工具；完成後應實際測試購物車、結帳、付款、運費與訂單寫入，不能只看首頁是否正常。

所以對 WooCommerce 商店，實務上的建議是：務必在維護模式下搬家，把站完全封鎖直到切換完成；搬家完成後，逐筆核對最近一筆訂單是否在新站看得到；如果站很大，認真考慮改用更適合電商的專業搬家方案，別再靠一鍵外掛硬扛。這不是 All-in-One WP Migration 特別差，而是所有「打包快照」式的搬家工具，都面臨同樣的即時性難題。

什麼時候該換工具

幾個明確的訊號，代表你已經超出 All-in-One WP Migration 的舒適區：打包過程頻繁逾時、匯入後出現資料表不完整、媒體庫有大量破圖、或你發現自己得不斷手動修補資料庫。這時候再跟工具搏鬥只是消耗時間，換一套更適合大型站的方案才是正解，例如具備增量搬移、資料庫直接對接的專業工具。不同工具的適用情境比較，前面提過的搬家外掛評比裡有整理，可以幫你判斷。

把門牌正式搬過去：網域、DNS 與停機控制

內容還原完，接下來是最關鍵、也最容易出事的一刀：把網域從舊主機切到新主機。這一步的本質是改 DNS，讓全世界打你網址的請求，從此被帶到新主機的 IP。

DNS 切換有個讓人焦慮的特性：它不是即時生效的。你改完設定之後，全球的 DNS 快取需要時間更新，這段時間內，有些訪客會被帶到新主機，有些還在舊主機，呈現一種「分裂」狀態。這個過程叫傳播（propagation），可能花幾分鐘到 48 小時不等，取決於各地的 DNS 快取設定（TTL）。

要讓這個分裂期盡量短、盡量無痛，有幾個技巧：

• 搬家前先降低 DNS 的 TTL。在切換前 24 到 48 小時，把網域的 TTL 調到很短（例如 300 秒），讓全球 DNS 提早習慣「這個網域的設定要頻繁更新」。等真正切換那一刻，傳播速度會快很多。這個動作要在你原本的 DNS 設定 介面裡做，通常在網域註冊商或 DNS 託管商的後台。
• 舊主機在切換後不要立刻關掉。讓它再活 24 到 48 小時，這段傳播期內被導到舊主機的訪客還是看得到網站，不會撲空。等確認新主機一切正常、流量完全轉移，再把舊主機下架。
• 純主機搬家（網域不變）可以做到近乎零停機。這也是為什麼 同網域換主機 是所有搬家情境裡 SEO 風險最低的：網址完全不變，Google 眼中什麼都沒發生。詳細的零停機流程，那篇有專門的步驟拆解。

如果你的情境是連網域一起換，那就不只是改 DNS 這麼簡單，你還得在舊網址與新網址之間建立完整的 301 轉址對應，這件事的規模與複雜度完全不同，主機加網域一起換的完整指南 有針對性的做法。

一個被多數搬家教學略過的雷：企業信箱

這裡插一段幾乎沒有搬家教學會提醒、卻會讓人痛到不行的細節：如果你的網域同時也用在企業信箱（例如用 Google Workspace、Microsoft 365 收發 @你的網域.tw 的郵件），那麼搬家時動到 DNS，很可能把信也一起弄斷。

電子郵件派送依賴 DNS 的 MX 記錄。若切換網站 A 記錄或 CNAME 時誤刪 MX、SPF、DKIM 等郵件設定，寄信方可能延遲重試或收到退信；實際結果依寄信伺服器與快取而異，不能假設郵件一定會「消失」。

保守的做法是：動 DNS 之前，先把目前的 DNS 設定完整截圖或匯出備份，特別標註 MX 記錄、SPF、DKIM 這幾組與郵件相關的紀錄；切換時只改網站相關的 A 記錄或 CNAME，郵件相關的紀錄一字不動；切換後立刻寄一封測試信進出，確認收發正常。如果你對 DNS 的各種記錄類型還不熟，前面提過的 DNS 設定教學與 網域申請全攻略 把這些觀念拆得很細，值得在動手前先讀過一遍。寧可花二十分鐘弄懂，也別拿公司的郵件當賭注。

搬家後的 SEO 守護戰：301、HTTPS 與行動版索引

這是多數搬家教學最草率帶過、卻最不能省的一塊。搬家對 SEO 的衝擊，往往不是在搬家當下爆發，而是在搬家後的幾週內慢慢發酵。當你發現流量往下掉的時候，問題通常已經累積了一段時間。所以這一節的每一條，都要在搬家完成後立刻檢查，不是等出問題才回頭補。

第一件：網址變了就一定要設 301 轉址

如果你是純主機搬家、網域沒變，理論上所有網址都不變，這一項可以跳過。但只要你的網址結構有任何改變（換網域、換固定網址格式、http 換 https），就必須為每一個舊網址設定 301 永久轉址，指向對應的新網址。

Google Search Central 明確說明，301 重新導向會將排名訊號從舊網址傳遞到新網址，是搬遷網頁時保留 SEO 成果的正確做法。

永久搬遷應使用 301 或 308 表達長期變更；302 是暫時轉址。Google 可能在長期觀察後把暫時轉址視為永久，但不應依賴這種推斷。301 與 302 的差異與正確設定方式，301 與 302 轉址完整教學 有深入說明。

第二件：HTTPS 要完整接起來，不能半套

搬家是個好時機，把網站正式推上 HTTPS（如果還沒的話）。Google 將 HTTPS 列為排名訊號之一，而且沒有完整加密的網站，瀏覽器會顯示「不安全」警告，對信任度與轉換率都是傷害。

Google Search Central 建議網站全面採用 HTTPS，並提供完整的部署指引，包含憑證取得與伺服器設定。

這裡的陷阱是「半套 HTTPS」：首頁是 https，但站內某些圖片、CSS、JS 還掛在 http 上，瀏覽器會判定為混合內容（mixed content），輕則跳出警告，重則資源直接被擋下不載入，版面整個走樣。All-in-One WP Migration 在匯入時會做網址替換，但你還是要手動檢查一遍，確保整站每一個資源都是 https 開頭。如果你是從 http 升級到 https，HTTP 換 HTTPS 的完整攻略 與 SSL 憑證指南 會幫你把這段做扎實。

第三件：確認行動版索引與頁面體驗

Google 已全面採用行動優先索引（mobile-first indexing），主要以行動版內容進行檢索與建立索引。搬家後若行動版缺少主要內容、結構化資料或必要資源，搜尋呈現與讀者使用都可能受影響。

Google 官方在 2023 年 10 月 宣布行動優先索引已全面上線，主要以行動版內容檢索並建立索引；這不代表行動版會額外獲得排名加分。

Google 的排名系統會參考多項頁面體驗訊號，Core Web Vitals 是其中一組小幅訊號；分數良好不保證排名，分數變差也不能單獨證明排名會下降。

Google 在 2020 年 11 月的 頁面體驗訊號時程說明中，將頁面體驗訊號納入整體排名系統，Core Web Vitals 是其中一部分，提醒站長重視載入效能與互動穩定度。

搬家後要確認行動版完整渲染，並比較新舊環境的速度。快取或 CDN 設定若未接回來，Core Web Vitals 可能變差，但排名變動仍要結合索引、轉址、內容與其他因素診斷。可重新跑一次 網站速度測試，並檢查 快取外掛 與 圖片優化。

第四件：用 Google Search Console 緊盯索引狀態

搬家後，Google Search Console 是你最重要的觀測站。不論網域有沒有換，你都要在搬家後的幾天內密集觀察：收錄頁數有沒有異常下降、有沒有大量網址回報 404、搜尋點擊有沒有斷崖式下滑。一旦發現異常，越早處理越能止血。

如果你對 GSC 還不熟，Google Search Console 完整教學 是系統性的入門，五個實戰技巧 則能幫你把監測效率拉上來。萬一真的在搬家後遇到排名下滑，網站流量下滑的找回方法 與 排名掉了的急救技巧 提供了具體的應對步驟。

上線後十二項驗證清單，確保新主機沒有暗傷

搬家最忌諱「按下匯入就放著不管」。很多問題當下看不出來，要等新站上線幾天後才慢慢浮上來。這份清單，是每次搬家完成後都該逐項打勾的檢查表，照著走一遍，就能確認新主機真的沒有暗傷。

1. 前台每一種頁面類型都點開看一次：首頁、文章頁、分類頁、商品頁（若有）、聯絡頁、about 頁。確認沒有破版、沒有白畫面。
2. 媒體庫的圖片全部正常顯示：隨機點開十篇舊文章，看圖片有沒有破圖。破圖通常是網址替換不完整造成的。
3. 固定網址結構與舊站一致：到「設定>固定網址」確認，這一點錯了會導致整站 404。
4. 表單與互動功能實測：送出一封聯絡表單、留一則測試留言、（WooCommerce）跑一次完整的結帳流程，確認功能正常。
5. 外掛與佈景主題全部啟用：有些外掛在匯入後可能被停用，逐項確認。如果原本裝了 資安外掛 或 Wordfence，要重新啟用並檢查規則。
6. SSL 憑證有效且整站 https：用瀏覽器檢查憑證狀態，並確認沒有混合內容警告。
7. 後台帳號與權限正常：確認管理員帳號能登入、權限角色正確。
8. 排程事件（cron）正常運作：例如排程備份、自動發文，這些在搬家後常會卡住。
9. 備份機制重新接上：把 備份外掛 的排程與雲端目的地重新設定好，別讓新站處於沒有備份的裸奔狀態。
10. 確認 sitemap：同網域換主機通常不必重複提交相同 sitemap；先確認內容與回應正常。若更換網域或 sitemap 網址，才在對應的 GSC 資源更新提交。
11. Google Analytics 與追蹤碼仍在：確認分析碼沒有在匯入過程中遺失，否則你的流量數據會斷層。
12. 觀察 404 與爬蟲錯誤：搬完後持續檢查伺服器紀錄與 GSC。報表更新不保證在 24 到 48 小時內完成；若發現舊網址 404，再確認是否有相符的新網址可做永久轉址。

這份清單看起來很多，但跑熟了大概半小時到一小時能走完。它真正的價值，在於問題還沒被 Google 與訪客發現之前，你先把暗傷找出來。一次扎實的搬家後驗證，勝過事後花一整週救火。

四個常見的搬家悲劇，你也可以避開

下面整理搬家時常見、而且可以事前檢查的錯誤。

悲劇一：以為匯入成功就等於搬家完成，沒切換網域。最常見的誤會。檔案還原了，後台能登入了，就以為大功告成，結果忘了把 DNS 指過去，訪客還是看到舊主機的舊內容，甚至舊主機合約到期被關掉，整個網站就消失了。記得，內容還原只是搬家的第二步，第三步的網域切換才是正式上線。

悲劇二：搬家後沒有重新儲存固定網址，整站 404。這個問題前面提過，這裡再強調一次。匯入後到「設定>固定網址」按一次「儲存變更」，這個動作幾乎不花時間，卻能擋掉一個會讓整站 404 的致命錯誤。匯入完的第一件事就該是這個。

悲劇三：舊主機太早關掉，DNS 傳播期內訪客撲空。改完 DNS 之後，全球快取需要時間更新，這段期內還會有訪客被導到舊主機。如果你在切換後立刻把舊主機關掉，這批訪客就會看到錯誤頁面。正確做法是讓舊主機再多活一兩天，等流量完全轉移再下架。這個等待成本很低，代價卻是避開一個流量黑洞。

悲劇四：混合內容沒有清乾淨，版面走樣。從 http 升級到 https 後，若站內資源仍使用 http，瀏覽器可能警告或阻擋 CSS、JS，造成版面與功能異常。這不是一項獨立的「混合內容排名處罰」，但會傷害安全性與使用體驗。應修正資料庫與模板裡的資源網址，不要只靠前端強制改寫掩蓋來源問題。

這四個問題主要來自流程疏漏。使用哪一套外掛固然重要，但備份、交易凍結、DNS、轉址與驗收是否按步驟完成，更直接影響結果。

收尾：你的下一步

走到這裡，你應該已經很清楚 WordPress 搬家的全貌了。接著把整個流程濃縮成一份你可以照著做的行動方案：

1. 前置準備：用 UpdraftPlus 做一份獨立備份，核對新主機的 PHP、MySQL、SSL、上傳限制是否達標，挑一個低流量時段進行。
2. 打包舊站：用 All-in-One WP Migration 匯出 .wpress 檔，下載到本機妥善保存。
3. 還原新站：在新主機裝好空白 WordPress 與同一版外掛，匯入打包檔，完成後立刻重新儲存固定網址。
4. 解決卡關：遇到上傳大小限制，用 .htaccess 或 Unlimited Extension 繞過。
5. 切換網域：先降低 TTL 再改 DNS，舊主機多留一兩天。
6. 守住 SEO：該設的 301 設好，HTTPS 接完整，行動版與頁面體驗確認無誤。
7. 跑驗證清單：十二項逐一打勾，用 GSC 緊盯索引與 404。

搬家這件事，做對了，訪客與 Google 幾乎不會察覺；做錯了，可能要花好幾個月把流失的排名與信任一點一點養回來。實務上會把它看成網站經營裡少數那種「不能出錯」的關鍵操作，值得你多花一兩個小時，把每一個步驟做扎實。

如果你正在規劃更全面的 WordPress 維運節奏，搬家只是其中一環，網站維護費用 與 架站成本 的完整拆解，能幫你把整體的長期投入看清楚。把每一次搬家、每一次備份、每一次升級，都當成是在鞏固你這座網站的根基。地基打穩了，上面的內容與流量才有地方站。