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

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

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

WordPress 搬家的三個主要階段

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

1. 打包舊站：把檔案、資料庫、外掛、佈景主題、媒體庫全部封裝成一個可以帶著走的東西。
2. 在新主機拆箱還原：在新主機裝好空白 WordPress，再把那個封裝檔倒進去，讓新站長得跟舊站一模一樣。
3. 切換與驗證：完成最新資料同步，配置 DNS、HTTPS 與必要轉址，再持續驗證。確認舊主機無有效流量與資料待處理後，才安排停用。

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

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

先搞清楚你是哪一種搬家

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

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

只換主機與改網址，需要的搜尋處理不同。改網址時應對應新舊 URL、設定永久轉址、更新內鏈和 canonical；不是新網域一出現就把舊歷史全部清空，也不能只靠一條轉址保證結果。

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

可比較 市面上的搬家外掛中的 Duplicator、Migrate Guru、UpdraftPlus、WPvivid 與 All-in-One WP Migration。選擇時核對資料量、主機支援、網域替換及授權條件，再用測試副本確認備份能否完整還原。

本篇以 All-in-One WP Migration 說明匯出與匯入流程。工具可減少手動搬移步驟，但不能代替主機、DNS、憑證和業務資料的盤點。

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

• 產生 .wpress 匯出檔：包含所選網站資料與檔案，實際範圍受排除設定影響。主機排程、DNS、憑證及部分環境組態須另行盤點，不能只保存一個檔案就當作全部環境已備妥。
• 匯入端不用預先設定資料庫：你只要在新主機裝好一個空白 WordPress，把外掛裝上去，匯入那個檔案，它會自動把資料表、選項、媒體全部填回去。對新手來說，這一點省掉的最大麻煩，就是不用手動改 wp-config.php。
• 自動處理序列化資料的網址替換：搬家最頭痛的「資料庫裡藏著舊網址」問題，外掛會在匯入時自動做字串替換，這是手動匯出匯入 SQL 最容易炸掉的地方。
• 介面極度直覺：一個頁面、四顆按鈕，沒有進階選項的選單地獄。

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

對可在目前環境成功匯出與還原的網站，這套工具能減少手動處理。是否適合應先試還原並核對資料，不能宣稱它一定成功、最不易出錯，或適用所有中小型商店。

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

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

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

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 或任何有即時交易、表單提交的網站，搬家那段時間如果還有訪客在線上下單、留言、填聯絡表單，這些資料會寫進舊主機的資料庫，而你打包的是更早的版本，結果就是這些訂單與訊息人間蒸發。

依實際流量安排切換窗口，凍結或受控同步新訂單、註冊、留言、管理員與 API 寫入，並處理付款回呼與排程。一般維護模式或 Coming Soon 頁不保證阻止所有入口；新舊站不能在過渡期各自接單而沒有一致性方案。

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

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

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

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

匯出卡住時先檢查外掛與主機紀錄、磁碟空間、檔案權限、資料量及 PHP 限制。確認原因後再調整合理資源或分開處理媒體；提高 memory_limit 與執行時間不是所有卡住情況的解法。

階段二：在新主機還原

1. 在新主機安裝一個空白 WordPress。用主機商提供的一鍵安裝，或照著 WordPress 安裝教學 手動裝。這個空白 WordPress 只是個容器，它的佈景主題、設定之後都會被匯入檔覆蓋掉。
2. 在新站安裝並啟用 All-in-One WP Migration。版本要跟舊站一致，避免格式不相容。
3. 進入「匯入」>「檔案」，上傳剛剛下載的 .wpress 檔。外掛會開始解包，把檔案寫回、把資料庫倒回去、自動做網址替換。畫面上會跳出一個警告，告訴你這會覆蓋現有資料，先確認是正確的目標站、已備份目標資料且可接受覆蓋，再確認；切勿直接匯入仍在接單的正式站。
4. 匯入完成後，登入新站的後台。注意，登入帳號密碼會被匯入檔覆蓋成舊站的，所以你原本設的空白站帳號會失效，要用舊站的帳密登入。這一點很多人會愣住，其實是正常行為。
5. 驗證固定網址與伺服器規則。使用備份中的帳號登入，檢查首頁、文章與頁面網址。必要時到「設定＞固定網址」重新儲存，以更新 rewrite rules；Apache 的 .htaccess 是否可寫，以及 Nginx 的伺服器設定，仍須分別確認。不要為了搬家任意改動原 URL 結構，相關說明見 永久連結設定教學。

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

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

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

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

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

若匯入檔超過限制，優先從主機控制台調整 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 提供大檔支援、伺服器端還原與 WP-CLI 等功能，仍須考慮磁碟、網路與環境相容性。現行產品採年費授權並有站點用量規則，不能再概括為一次購買終身使用。

ServMask 的 Unlimited Extension 提供進階匯入功能；目前產品頁列有年費與站點上限，續訂、使用次數及支援條件應在購買前核對。

先查看目前版本的匯入畫面、主機限制與方案功能，再選擇調整環境、付費擴充或其他工具。沒有通用的「1GB 以下免費版加 .htaccess 就夠」規則，也不應修改外掛程式或使用過時版本規避限制。

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

是否適用大型網站取決於資料量、資源、版本與方案。先做可驗證的試搬；若反覆失敗，依實際錯誤評估主機遷移工具、命令列或其他方式，不只按網站大小判定外掛的設計用途。

WooCommerce 商店的特殊風險

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

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

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

WooCommerce 搬家需在最後同步前控制訂單、庫存、會員、API 與排程寫入，再核對完整切換窗口中的資料。只開維護頁或只看最後一筆訂單都不足以證明一致；無法安全處理時，應由熟悉商店資料模型的人執行。

什麼時候該換工具

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

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

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

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

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

• 搬家前先降低 DNS 的 TTL。依目前 DNS 紀錄的 TTL，至少提前一個完整 TTL 降低需要切換的紀錄（例如調至 300 秒，若服務商允許）。已快取的舊紀錄仍要等原 TTL 到期；降低 TTL 有助於之後的切換，但不保證各地同步完成。這個動作要在你原本的 DNS 設定 介面裡做，通常在網域註冊商或 DNS 託管商的後台。
• 舊主機在切換後不要立刻關掉。切換後保留舊主機，持續查看舊站請求、DNS 解析與新站功能，並確保過渡期的新訂單等寫入有一致性處理；確認不再有待處理流量與資料後才下架。所需時間取決於原 TTL、快取與服務情境，不以固定 24 到 48 小時判定。
• 純主機搬家（網域不變）可藉事前測試與受控切換降低停機。這也是為什麼 同網域換主機 是所有搬家情境裡 SEO 風險最低的：網址完全不變，但仍會改變主機回應與檢索環境。詳細的切換流程，那篇有專門的步驟拆解。

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

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

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

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

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

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

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

第一件：為永久搬移的網址設定適當轉址

如果你是純主機搬家、網域沒變，理論上所有網址都不變，這一項可以跳過。但只要你的網址結構有任何改變（換網域、換固定網址格式、http 換 https），應為有等價新內容的舊 URL 設定 301 或 308；已刪除且沒有替代內容的 URL 回傳 404 或 410。

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. 媒體檢查：抽查不同時期文章，再用爬蟲與檔案盤點擴大覆蓋。破圖可能來自漏檔、權限、大小寫、URL 或 CDN，十篇抽查不代表全部媒體完整。
3. 核對固定網址結構：確認既有公開 URL 與路由規則仍可用；若刻意變更網址，需另做轉址與內鏈更新，並測試代表頁面及全站錯誤。
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，再確認是否有相符的新網址可做永久轉址。

驗證所需時間取決於網站規模、資料量與外部整合。記錄實際測試、異常及處理結果，再決定是否完成切換，不以固定半小時到一小時當作通用驗收期限。

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

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

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

搬家後首頁正常、內頁 404 時，先核對永久連結與伺服器 rewrite 設定。儲存永久連結可更新 WordPress 規則，但 Nginx、CDN、權限或路徑問題須另查，不能都歸因於忘了按儲存。

悲劇三：舊主機太早關掉，DNS 傳播期內訪客撲空。改完 DNS 之後，全球快取需要時間更新，這段期內還會有訪客被導到舊主機。如果你在切換後立刻把舊主機關掉，這批訪客就會看到錯誤頁面。保留舊主機並監看實際請求與新站驗收結果；待 DNS 舊快取、訂單與其他寫入都處理完，再安排下架。固定等一兩天不能代替確認。

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

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

收尾：你的下一步

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

1. 前置準備：用 UpdraftPlus 做一份獨立備份，核對新主機的 PHP、MySQL、SSL、上傳限制是否達標，挑一個低流量時段進行。
2. 打包舊站：用 All-in-One WP Migration 匯出 .wpress 檔，下載到本機妥善保存。
3. 還原新站：在受保護的新環境安裝相容的 WordPress 與搬家外掛，再匯入已驗證的備份。確認帳號、網址與 rewrite rules，需要時重新儲存固定網址；不要把匯入完成當成驗收完成。
4. 解決卡關：依錯誤紀錄確認主機與外掛限制，再選受支援的調整或擴充方案，不盲目修改 .htaccess。
5. 切換網域：提前依 TTL 安排 DNS，完成最新資料核對；舊站保留至流量與資料處理完成，換網域轉址則至少維持一年。
6. 守住 SEO：該設的 301 設好，HTTPS 接完整，行動版與頁面體驗確認無誤。
7. 跑驗證清單：十二項逐一打勾，用 GSC 緊盯索引與 404。

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

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