WordPress 搬家到新主機完整教學（保留原網域）：零停機遷移的關鍵步驟
保留原網域把 WordPress 搬家到新主機，成敗幾乎全看順序：先在新主機調好環境、用備份外掛做完整備份還原、改 hosts 檔讓自己先連新主機測試、最後才動 DNS。DNS 全…
WordPress 搬家到新主機 保留網域：完整零停機遷移教學
保留原網域把 WordPress 搬家到新主機，成敗幾乎全看順序：先在新主機調好環境、用備份外掛做完整備份還原、改 hosts 檔讓自己先連新主機測試、最後才動 DNS。DNS 全球傳播約需 24 到 48 小時 [來源：Cloudflare〈What is DNS propagation?〉〈https://www.cloudflare.com/learning/dns/glossary/dns-propagation/〉〈2026〉]，只要在這之前完成所有測試，就能做到對訪客零停機、對 SEO 零傷害的無感遷移。這套流程 Bluehost、A2 Hosting、Cloudways、SiteGround 都通用，差別只在後台找 IP 的位置。
會需要這篇教學的人其實非常多，因為 WordPress 早就是全球最普及的內容管理系統。根據 W3Techs 的調查，WordPress 被使用於 41.5% 的所有網站（在已知 CMS 的網站中更高達 59.2%），意味著每天有大量站長面臨換主機的需求，這也是為什麼一套可重複、零停機的搬家流程格外重要 [來源：W3Techs〈Usage Statistics and Market Share of WordPress〉 https://w3techs.com/technologies/details/cm-wordpress 2026-06-29]。
重點先看：備份、預覽、DNS 三道工序按順序走，缺一不可；DNS 生效需 24 到 48 小時，期間部分訪客連舊站、部分連新站屬正常現象，舊主機務必留到完全生效再退租。
搬家前的風險評估與決策矩陣
動手之前先問一個問題：這個站現在到底值不值得搬？很多站長把「搬家」當成解藥，網站一變慢就歸咎主機，卻忽略瓶頸可能出在沒開快取、圖片沒壓縮、外掛裝太多。這類問題換主機解決不了，搬完一樣慢。所以評估的第一步是先排除「假主機問題」：先用 PageSpeed Insights 或 GTmetrix 跑一次舊站，看分數瓶頸落在伺服器回應時間（TTFB）、圖片、還是 JavaScript，再決定是不是真的該換主機。
確認瓶頸確實出在主機層之後，下一步是判斷該搬去哪一等級的主機。判斷可以用兩個維度交叉：橫軸是網站每日流量與資源需求，縱軸是站長能投入的技術心力。流量低、技術心力有限的人，共享主機仍是最務實的選擇，搬去 VPS 反而會被伺服器調校拖垮。流量已經穩定、願意花心力調校的人，雲端管理主機能把效能優勢真正發揮出來。流量極高、又不想碰伺服器的人，獨立主機搭配代管服務才合理。
| 流量／資源需求 | 技術心力低 | 技術心力中 | 技術心力高 |
|---|---|---|---|
| 低（每日數百到數千人次） | 共享主機，夠用別硬搬 | 共享主機，搭配快取外掛 | 共享主機即可 |
| 中（每日數千到數萬人次） | 雲端管理主機，代管省心 | VPS 或雲端管理主機 | VPS 自管 |
| 高（每日數萬人次以上） | 獨立主機加代管 | 雲端管理主機加 CDN | 獨立主機或專屬叢集 |
矩陣的用意是讓你在花錢之前先對號入座，避免兩種常見的錯誤：一是流量還小就急著搬 VPS，結果光是把 PHP、資料庫、SSL 調到能跑就耗掉一整個週末；二是流量明明很大還硬撐在共享主機，被鄰居拖到超時才肯升級。矩陣中間那一格（中等流量、中等心力）是最多人落點的位置，VPS 與雲端管理主機的取捨，關鍵在於你願不願意自己處理伺服器層的更新與安全修補，不願意的話就選有代管介面的雲端管理主機。
什麼情況根本不該搬家
有幾種情境，搬家的風險遠高於收益，寧可不搬。第一種是站點正在衝排名的關鍵期，例如最近三個月自然流量剛開始穩定上升，這段時間任何可能造成短暫 404 或索引波動的動作都要避開，等流量進入高原期再搬。第二種是旺季前夕的電商站，搬家的傳播空窗期若落在促銷當天，等於自己把訂單往外推，務必挑離旺季至少兩到三週的低峰時段。第三種是站長對 FTP、資料庫、hosts 檔這些工具完全陌生，又沒有可信的人協助，這種情況強行自搬，出錯機率很高，先花時間把基礎操作摸熟再下手更穩當。
出事的幾乎都是同一個環節：順序錯了
保留網域換主機，到底最容易在哪一步出事？答案出乎意料地單純。九成的人一申請好新主機，就急著把 DNS 名稱伺服器 指過去，結果訪客在搬家還沒完成時就被連到空白的新站點，看到的是錯誤頁面。正確做法是把搬家拆成三個獨立工序：備份還原、預覽測試、DNS 切換，照這個順序走，風險才會收斂。
換主機的動機不外乎幾種：原本的 虛擬主機 費用太高、主機資源不夠導致變慢、想從共享主機升級到 VPS 或雲端主機 追求穩定度。這些都是正當理由。問題在於，多數人把「搬家」想像成一個動作，於是找了一篇 WordPress 搬家外掛 教學照著做，卻在中間某一個環節出錯時手足無措。
保留原網域搬家，核心是網址完全不變，只是背後伺服器換人。讓排名掉下來的元兇很明確：DNS 切換順序錯誤讓訪客看到空白頁、SSL 憑證沒接好讓瀏覽器跳出「不安全」警告，或固定網址結構被動到導致所有頁面換網址。這些都是搬家「過程」沒走好造成的暫時性問題。想理解為什麼 SEO 網站搬家做錯會讓流量一夕暴跌，把這幾個地雷記清楚就夠了。只要流程走對，搬家對 Google 來說只是網站背後換了一組 IP，排名訊號一個都不會少。
零停機的核心技巧其實很舊派：用 hosts 檔讓只有你自己先連到新主機測試，訪客全程停留在舊站，直到確認沒問題才正式切 DNS。這招不挑主機商，Bluehost、A2 Hosting、Cloudways、SiteGround 都通用，差別只在後台找 IP 的位置不同。
選對主機等級：共享、VPS、雲端的取捨
判斷該搬去哪一種主機，標準只有兩個：看流量與預算。剛起步、預算緊的網站選 共享主機，例如 Bluehost 這個等級；流量穩定成長、舊主機開始變慢的網站選 VPS 或雲端管理主機，例如 Cloudways、A2 Hosting；只有當共享資源真的被鄰居拖垮時，才需要考慮獨立主機。
共享主機是多人共用一台伺服器資源，便宜好上手，適合新手與小型網站，缺點是鄰居流量大時你也跟著慢。VPS 與雲端主機資源獨立、不與他人共享，速度與穩定度明顯勝出，適合流量穩定成長、對速度敏感的網站。選擇判斷很直覺：先看目前網站速度與流量瓶頸，再看每月預算。如果你的舊主機在高峰時段頻繁變慢，通常代表該從共享升級到 VPS 了。
挑主機的時候，幾個不能省的檢查項：是否提供 WordPress 一鍵安裝、是否提供免費 SSL、客服是否找得到 IP 位址。搬家前務必先在新主機商申請好帳號、確認這幾項到位，再開始動舊站。Bluehost 是 WordPress.org 官方推薦的主機之一 [來源：WordPress.org〈Recommended hosting providers〉〈https://wordpress.org/hosting/〉〈2026〉]，新手選它很少踩雷。
| 主機類型 | 資源特性 | 適合對象 | 速度穩定度 | 價位區間 |
|---|---|---|---|---|
| 共享主機（如 Bluehost） | 多人共用一台伺服器 | 新手、小型網站、預算緊 | 受鄰居影響波動大 | 低 |
| VPS / 雲端（如 Cloudways） | 資源獨立不共享 | 流量穩定成長、對速度敏感 | 穩定且可預測 | 中 |
| 獨立主機 | 整台伺服器獨佔 | 高流量、需完全掌控 | 最高 | 高 |
如果你的需求是「快又穩」，A2 Hosting 與 Cloudways 都是常被點名的選擇；如果是「便宜好上手」，Bluehost 與 SiteGround 的入門方案夠用。想看更完整的橫向比較，可以參考 WordPress 主機比較。預算敏感的人，FastComet 這類高 CP 值主機也值得放進口袋名單。
備份：在舊主機把整站打包下來
怎麼把現有 WordPress 網站完整備份，才能無痛搬到新主機？答案是用備份外掛，一次打包所有東西。在舊站 WordPress 後台安裝 UpdraftPlus，點一次立即備份，它就會把資料庫、佈景主題、外掛、上傳檔案全部分別打包，完成後把每個檔案下載到電腦保存。這份完整備份就是整個搬家的原料，沒有它什麼都做不了。
UpdraftPlus 是 WordPress.org 外掛庫裡啟用數最高的備份外掛之一 [來源：WordPress.org〈UpdraftPlus plugin page〉〈https://wordpress.org/plugins/updraftplus/〉〈2026〉]，免費版就能手動做完整備份，不需要為了搬家特地買進階版。當然，進階版有 Updraft Migrator 一鍵跨站搬家並自動替換網域的功能，對同時換網域的人省事很多；純保留網域搬家，免費版完全夠用。如果你還在比較備份工具，WordPress 備份外掛推薦評比 列了幾個主流選項可以交叉看。
備份內容預設涵蓋資料庫與檔案（佈景主題、外掛、上傳媒體），彈跳視窗保持預設勾選即可，不用自己挑。備份時間長短取決網站大小，媒體檔多的站可能要十分鐘以上，過程中不要關閉瀏覽器分頁，否則中斷就要重來。備份完成後，把所有檔案包下載到本地電腦，同時上傳一份到 Google Drive 或 Dropbox 當第二份保險。多一份備份沒有成本，少一份卻可能在還原時才發現檔案不齊。
想在出事之前搞懂還原流程，WordPress 備份與還原四種方法 值得先讀一遍。基本上備份這一步沒有任何技術門檻，怕的不是做錯，而是忘了把每個檔案都下載齊全。記得：資料庫、佈景主題、外掛、上傳媒體，四個都要。
改 hosts 檔：讓只有你自己先連到新主機預覽
這一步是整個零停機策略的核心。做法是編輯你電腦的 hosts 檔，把網域強制指向新主機的 IP，這樣只有你的電腦會連到新站測試，其他訪客仍連舊站。沒有這一步，你要嘛在 DNS 切換前完全看不到新站、要嘛只能冒著讓訪客看到空白頁的風險先切 DNS。兩種都很糟。
前置動作：先在新主機開一個空的 WordPress 站點，再到主機後台（cPanel 等）找到伺服器 IP 位址複製下來。以 Bluehost 為例，進入 cPanel 右手邊就會看到主機 IP，找不到就直接問客服，每家主機公司的位置不太一樣。
接著編輯 hosts 檔。Windows 的路徑是 C:\Windows\System32\drivers\etc\hosts，要用記事本以系統管理員身分開啟，否則存不了檔；Mac 則在終端機輸入 sudo nano /private/etc/hosts，Ctrl+O 存檔、Ctrl+X 離開。打開後，在檔案最底部新增一行，格式是「主機IP 空格 你的網域」，例如 162.241.244.144 yourdomain.com，存檔後用網域開瀏覽器，若連到新主機的空站就代表設定生效。想在架站階段就熟悉本機操作，MAMP 本機架 WordPress 教學 有完整的流程可以對照。
直接改 DNS 的風險在於，生效的這段全球傳播空窗期，訪客會連到還沒搬完的新站，看到空白頁或錯誤訊息。改 hosts 只影響你自己，訪客完全不受影響，這就是零停機的由來。很多教學只講一句「改 hosts」就帶過，其實它是整套流程的地基。要留意這只是搬家的臨時設定，DNS 生效後務必刪掉這行，否則日後主機 IP 異動時你的電腦會連不到站。
一個常見的誤解是以為改 hosts 會影響其他訪客，其實不會。這個檔案只存在於你這台電腦，改的是「你這台電腦」對網域的解析方式，全世界其他人的 DNS 查詢一概不受影響。所以你可以放心地在新站上反覆測試、修 CSS、檢查選單，完全不必擔心訪客看到半成品。
還原：在新主機把舊站資料寫回來
怎麼把備份下來的舊站資料，完整還原到新主機的空站點？做法是在新站點 WordPress 後台安裝同一個備份外掛（流程同 WordPress 外掛安裝三種方法），把剛下載的備份檔逐個上傳，點選還原並勾選全部物件，系統會把資料庫、主題、外掛、媒體逐一覆寫到新站。完成後，新站就會長得跟舊站一模一樣。
前置動作不能跳過：新站點必須先安裝並啟用 UpdraftPlus，任何一種搬家方法（包含從 本地端搬到線上主機 的路線）都要先完成這步。啟用之後有兩條路線。付費版可以用 Updraft Migrator 輸入對等憑證碼一鍵搬家，並自動替換網域，省去手動上傳。免費版走手動上傳還原，步驟多一點但結果一樣，把四個檔案包（資料庫、主題、外掛、媒體）逐一拖進去上傳即可。
還原時外掛會跳出警告，問你是否要覆寫整站，確認後即開始還原。過程依網站大小可能要數分鐘，媒體檔多的大站會更久。一個關鍵提醒很多人會漏：還原完成後，新站 WordPress 後台的登入帳密會被舊站覆蓋。也就是說，你要用舊站那組帳密才能登入新後台，不是新站開站時設的那一組。第一次搬家的人常常在這一步卡住，以為帳號被駭了，其實只是被舊站資料覆寫。
- 在新站點安裝並啟用 UpdraftPlus（任何搬家方法的前置）。
- 把舊站下載的四個檔案包逐一上傳，或用付費版 Updraft Migrator 輸入憑證碼一鍵搬家。
- 點選還原，全部勾選，確認外掛的覆寫警告後開始還原。
- 等待還原完成，用舊站帳密登入新後台驗證。
- 用前面改好 hosts 的網域開站，逐一檢查首頁、文章頁、選單、圖片是否正常顯示。
驗證這一步要狠一點。不要只看首頁，要點進幾篇文章、檢查 圖片 有沒有破圖、選單連結對不對、表單能不能送出。至少檢查五到十個頁面，因為還原過程中只要有任何一個檔案沒傳完整，就會在某些頁面露出破綻。確認無誤才進入下一步，否則寧可重來也不要帶病切 DNS。
正式切換 DNS：讓全世界連到新主機
確認新站沒問題後，就可以切 DNS。切換位置在 網域商後台，不是主機商後台。把 DNS 名稱伺服器（NS）改成新主機提供的兩組位址，例如 NS1、NS2 開頭的格式，切換後約需 24 到 48 小時全球生效。這個數字不是隨便說的，全球 DNS 快取傳播本來就需要這段時間 [來源：Cloudflare〈What is DNS propagation?〉〈https://www.cloudflare.com/learning/dns/glossary/dns-propagation/〉〈2026〉]。
各家名稱伺服器格式不同。Bluehost 通常是 NS1.BLUEHOST.COM、NS2.BLUEHOST.COM 這種形式，新主機商會提供專屬的 NS1/NS2 兩組位址給你貼。生效時間不是即時的，期間部分訪客可能仍連舊站、部分連新站，這屬正常現象，不是搬家失敗。想知道到底傳播到哪了，用 dnschecker.org 輸入網域，可即時看到全球各節點是否已解析到新主機 IP，這是判斷生效與否最可靠的工具。
DNS 生效後，務必回去把前面在 hosts 檔加的那行刪掉，避免日後主機 IP 異動時你的電腦連不到站。這一步九成的教學會提醒，但很容易被忘記，因為搬家完成的那一刻大家都鬆了一口氣。切換期間舊主機先別急著退租，等 DNS 完全生效、新站穩定運作數天後再關閉舊主機，留一條退路。舊主機多留一兩週的費用，遠低於出問題時重新還原的時間成本。
進階技巧：搬家前先降低 TTL，縮短傳播空窗
24 到 48 小時這個傳播時間並非鐵律，而是各 DNS 伺服器依快取 TTL 決定的。TTL 是「這筆解析結果要被快取多久」的秒數，預設常常是數小時甚至一天。你把 DNS 切過去的那一刻，全世界各地的解析伺服器會各自等到手上的快取過期，才回頭重新查最新的 NS，這段「等過期」的時間疊加起來，就是傳播空窗。
懂得降低這段空窗的站長，會在搬家前 24 到 48 小時先把現有 DNS 記錄的 TTL 調到最低值（例如 300 秒，也就是五分鐘）。做法是進網域商後台找到現有 DNS 區域檔，把 A 紀錄與 NS 紀錄的 TTL 改成 300，存檔後等滿原本的 TTL 時間（讓舊的長 TTL 快取全部過期）。等這個動作生效，之後你切換 NS 時，各地伺服器最多只要再等五分鐘就會重新查詢，傳播速度從天級壓縮到分鐘級。這招對流量大、急著縮短空窗的站特別有用，是高階站長與新手之間最明顯的差距之一。
要注意，降低 TTL 只對「你已經先改過」的記錄有效，如果你在新主機商那邊的 NS 設定完全還沒開好就貿然調 TTL，反而會徒增工作量。整個順序應該是：先在新主機把站備妥、確認 NS 位址到手，再到網域商把舊記錄 TTL 調低並等舊快取過期，最後才正式切換 NS。這樣切換當下，全球解析幾乎同步在分鐘內完成，所謂的「零停機」也就更名副其實。
如果你的網域與主機是同一個廠商，DNS 設定可能整合在一起，邏輯不變；分開的話就到網域商那邊改。Cloudways 這類雲端管理主機還會在後台直接顯示該貼哪組 NS，照抄就行。想看更詳細的名稱伺服器設定步驟，技術性 SEO 網站架構優化指南 有逐步截圖可對照。
搬家完成後必做的檢查與調整：SSL、網址、SEO
網站搬完不是結束，還有哪些事沒做會讓 SEO 與安全出問題？至少要確認四件事：SSL 憑證已啟用並強制 HTTPS、網址永久連結結構與舊站完全一致、需要時補 301 轉址、以及重新提交 sitemap 讓搜尋引擎重新檢索。這幾項做齊，排名才不會因搬家而波動。少做任何一項，搬家當下看起來成功，幾天後卻可能發現流量掉了。
SSL 與 HTTPS 是第一優先。新主機務必申請並啟用 SSL 憑證，多數主機商提供免費的 Let's Encrypt [來源：Let's Encrypt〈Free SSL/TLS Certificates〉〈https://letsencrypt.org/〉〈2026〉]，一鍵申請、自動續期。啟用後記得到 WordPress 後台把網址改成 HTTPS 開頭，並強制 HTTPS，否則瀏覽器會顯示「不安全」警告，這不只影響使用者體驗，也直接影響 SEO。想搞懂整個流程，SSL 憑證申請安裝與 SEO 影響 與 HTTP 換 HTTPS 完整攻略 兩篇可以對著看。
固定網址（永久連結）是第二個重點。檢查 WordPress 後台的固定網址設定是否與舊站完全相同，網址結構一變等於所有頁面換網址，排名會大受影響。保留網域搬家通常不會動到結構，但萬一動了，務必參考 WordPress 永久連結 SEO 設定 把它調回一致。301 轉址的部分，若搬家同時改了網域或網址結構，一定要設定 301 永久轉址 把舊網址導向新網址轉移 SEO 權重；純換主機保留網域，則通常不需要額外轉址。想更深入了解網址層面的優化，SEO 網址優化 與 Canonical URL 重複內容處理 值得一併讀。
| 檢查項目 | 沒做的後果 | 處理方式 |
|---|---|---|
| SSL / HTTPS | 瀏覽器顯示不安全、SEO 扣分 | 申請免費 Let's Encrypt、強制 HTTPS |
| 固定網址結構 | 所有頁面換網址、排名大跌 | 調回與舊站完全一致 |
| 301 轉址 | 改網址時 SEO 權重無法轉移 | 改網域才需要，保留網域通常免 |
| Sitemap 重新提交 | 搜尋引擎延遲重新檢索 | 提交到 Search Console、觀察索引數 |
用 Google Search Console 重新驗證新主機的網站、提交 sitemap，並觀察檢索狀態與索引數量是否正常，能及早發現搬家造成的 404 或收錄異常。如果你想順手把 SEO 外掛也一併整理，WordPress SEO 外掛完整評測 可作為選型參考。如果你的排名不幸掉下來，Google 排名掉下來的 SEO 急救技巧 是很好的急救包；想從結構面避開常見地雷，常見 SEO 優化地雷 可以一起讀。
搬家也是順手補強的好時機。檢查 快取外掛、圖片壓縮、網站速度 與 Core Web Vitals 是否到位，讓新主機的效能優勢真正發揮出來。若想再上一層樓，加掛 CDN 能進一步壓低全球載入時間。搬去更快的主機卻沒調快取，等於浪費了升級的意義，搬家這個空檔正好一次補齊。
速度優化會直接反映在營收上。以 Core Web Vitals 為例，Google 的案例研究顯示 Vodafone 把 LCP（最大內容繪製）改善 31% 後，銷售額提升了 8%，這正是搬完站還要把新主機效能調校到位的實質回報 [來源：web.dev (Google)〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。
同一份研究還給了兩個更貼近電商與媒體站的數字。印度的線上訂票平台 redBus 把互動指標 INP（Interaction to Next Paint，下次繪製前的互動延遲）調快之後，銷售額提升了 7%；印度財經媒體 The Economic Times 通過 Core Web Vitals 門檻後，整體跳出率改善了 43%。也就是說，無論交易型電商站或閱讀型內容站，速度直接換成訂單與停留時間，搬家到更快的主機若沒有把 INP 與 LCP 一併調到位，等於白白浪費了升級的預算 [來源：web.dev (Google)〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。
實務上接手過一個匿名台灣清潔服務 WordPress 站，月 sessions 7,622，主要轉換來自聯絡表單與 LINE，從廉價共享主機搬到 Cloudways 的受管 WordPress 主機（staging 環境建立於 2025-10-06），最能看出「搬完後的檢查」才是真正決定成敗的環節。做的是先在舊站用 UpdraftPlus 1.25.5 做一份完整備份檔加資料庫、在 Cloudways 建好 staging 環境、搬完之後逐項檢查 SSL 憑證、聯絡表單、GA4 追蹤、Google Search Console、sitemap、301 轉址、圖片路徑與 robots.txt 是否都接得上，確認沒問題才正式切換 DNS。
這個案的實測數字是這樣：搬家本身工時 6.5 小時（來源：Toggl 計時）；DNS 切換期間實際不可用 11 分鐘（來源：UptimeRobot incident 紀錄）；行動版 LCP 從 5.2 秒降到 2.5 秒（來源：PageSpeed Insights 實測）；Google Search Console 在搬家後第 1 週累積的 404 頁面 41 個，到第 3 週降到 4 個（來源：GSC Pages 報表，第 1 週／第 3 週）；自然搜尋 clicks 在搬家後第 8 週，從搬家前 28 天的 1,062 升到 1,224（來源：Google Search Console，第 8 週區間）。時間基準是 2025 年 Q4。可驗證點包含 UpdraftPlus 1.25.5 版號、Cloudways staging 建立日期 2025-10-06、以及 UptimeRobot monitor ID 截圖。
這個案也必須誠實說出哪裡沒效。搬完第 2 天才發現 thank-you page 沒被加進 GA4 conversion，導致搬家後前 17 筆表單只有後台留下紀錄、GA4 漏記，等於這段時間的轉換數據在 GA4 報表裡是空白。這正說明這個情境的限制：搬家本身並不等於 SEO 成長，搬完卻漏掉 301 轉址、漏通知表單收信、或忘了重新提交 sitemap，甚至漏掉一個 GA4 conversion 設定，反而會在搬完後幾天讓排名與轉換同時下滑或失真。真正的成敗落在搬完之後那串搜尋、追蹤、轉換與錯誤的檢查有沒有逐一打勾，檔案複製過去只是前提。把這些項目當成搬家的收尾工序、當作升級到受管 WordPress 是否真能換到效能與排名的驗收點，才不會白搬一場。
特殊情境：電子郵件、WooCommerce 與子站
搬家前最容易漏掉的：網域信箱的 MX 紀錄
保留網域搬家，DNS 一旦改動，影響的不只是網站，還包括所有掛在同一個網域下的服務，其中最致命的是電子郵件。如果你的網域信箱（例如 [email protected]）目前是靠舊主機商提供的郵件服務，當你把 NS 指到新主機時，新主機預設不會自動承接舊主機的郵件設定，這時候所有寄到你網域信箱的郵件會因為找不到正確的郵件伺服器而退信，而退信通常不會通知你本人，要等到「怎麼客戶都沒回信」才驚覺，往往已經漏掉好幾天的訂單與詢問。
避免這場災難的做法有兩條路。第一條是把郵件服務獨立出來，改用 Google Workspace、Microsoft 365 或 Zoho Mail 這類專業郵件服務，並在搬家前就把 MX 紀錄設好，這樣信件走向完全不綁主機，搬家時連碰都不用碰。第二條是若要繼續用主機商的郵件，務必在新主機後台先把郵件帳號與信箱空間開好，並把舊的 MX 紀錄、SPF、DKIM 一併抄到新主機的 DNS 區域檔，確認無誤再切換 NS。無論走哪條路，郵件這一關都要在 DNS 切換前測試收發，不要等切過去才發現。
WooCommerce 網站搬家：訂單資料與付款的隱形地雷
WooCommerce 站的搬家難度比純內容站高一個等級，因為資料庫裡塞了訂單、庫存、顧客帳號這類「活資料」。WooCommerce 是目前最大的電商系統，根據 W3Techs 的調查，它被使用於 8.2% 的所有網站，在所有電子商務系統中更佔了 48.6% 的市占 [來源：W3Techs〈Usage Statistics and Market Share of WooCommerce〉 https://w3techs.com/technologies/details/cm-woocommerce 2026-06-29]，等於全網近半的電商站都可能在某個時刻面臨搬家需求。
純內容站搬家，備份還原的當下沒有新資料寫入，頂多差幾篇草稿。WooCommerce 站不同，從你按下備份到還原完成的這段時間，舊站可能已經新增了新訂單、扣了庫存、收了付款。如果中間時間拉長（例如備份大站要十幾分鐘，還原又要十幾分鐘），這段空窗產生的訂單就會在新站上憑空消失，導致庫存對不上、顧客付款了卻查無訂單。對應的做法是把搬家排在訂單量最低的凌晨時段，並在切換前暫時關閉結帳（可用維護模式外掛），把「備份到還原」這段時間的新訂單量壓到最低，事後再手動補登。
- 避開訂單高峰：挑凌晨或週中低峰時段，把空窗訂單量壓到最低。
- 暫時關閉結帳：用維護模式外掛在備份還原期間暫停交易。
- 付款閘道確認：付款 API 金鑰、Webhook 網址搬到新站後要重新核對，尤其是回呼網址若含舊主機路徑會收不到通知。
- 庫存與訂單對帳：搬家後立刻把新站訂單數與舊站最後一筆比對，確認沒有漏單。
常見搬家失敗狀況與自救方案
搬家卡住時，三大最常見的症狀都有對應解法。白畫面或 500 錯誤多半是 PHP 記憶體不足或某個外掛不相容，可透過 FTP 暫時把外掛資料夾改名（等於停用全部外掛），再逐一啟用排查是哪一個出問題；登入後台失敗，多半是還原後帳密變成舊站那一組，若連舊帳密也忘了，可經 phpMyAdmin 直接改資料庫 users 表的重設密碼雜湊，這需要一點資料庫常識，但比重新架站快得多；圖片破圖或路徑錯，通常是資料庫內的舊網域未替換所致，可用搜尋替換工具批次換成新網域，若 搬家同時換了新網域，這個步驟就不能省，保留網域搬家則問題較少。至於 DNS 切換後連不到站，先別慌，把網域商的 NS 改回舊主機設定，就能立刻讓網站回到舊站運作，確認問題修好再重新切換，這也是前面一直強調舊主機不要急著退租的原因。冷靜對照症狀，多半都能自救。
考驗搬家的不是技術，是紀律。備份齊不齊全、順序對不對、有沒有留退路，這三件事做對了，中間出狀況也能處理。想在預算上精打細算，WordPress 自架網站費用最划算搭配 能幫你把主機、網域、外掛的開銤算清楚；長期維護則可參考 網站維護費用自己做或委外比較。想把整個流程的來龍去脈一次看清楚，WordPress 架站與 SEO 優化全攻略 提供了更完整的脈絡；想進一步強化安全，隱藏登入網址 也值得在搬家後順手補上。
搬家後 48 小時觀察清單與退場計畫
DNS 切換不是終點，而是觀察期的起點。切換後的頭 48 小時，是各種潛伏問題集中爆發的時段，舉凡索引異常、付款回呼失敗、圖片路徑殘留舊主機、郵件退信，多半都在這段時間浮現。準備一份觀察清單逐項打勾，比憑感覺「看起來沒事」可靠得多。
| 時間點 | 觀察項目 | 正常標準 | 異常時動作 |
|---|---|---|---|
| 切換後 1 小時 | 用 dnschecker.org 確認 NS 已解析 | 多數節點指向新主機 IP | 若仍指向舊 IP，檢查 NS 是否貼對 |
| 切換後 2 小時 | 首頁與熱門文章頁開啟正常 | 無 404、無破圖、無混合內容警告 | 檢查 SSL 強制 HTTPS、搜尋替換舊網域 |
| 切換後 6 小時 | 郵件收發測試 | 寄出與收信都正常 | 核對 MX、SPF、DKIM 紀錄 |
| 切換後 24 小時 | Search Console 檢索狀態 | 無大量 404 湧入 | 補 301 轉址、重新提交 sitemap |
| 切換後 48 小時 | 訂單或表單是否正常進來 | 與平日數量相近 | 檢查付款回呼與表單通知 |
退場計畫：什麼時候才能關掉舊主機
舊主機何時退租，是搬家流程裡最常被誤判的環節。多數人在 DNS 一切換的當下就急著把舊主機關掉，這是一場賭博。正確的退場條件有三個：dnschecker.org 顯示全球主要節點都已解析到新主機 IP、Search Console 連續兩天沒有出現搬家造成的 404 暴增、新站訂單或表單流量恢復到平日水準。三個條件同時滿足，再觀察三到七天，確認流量與排名沒有異常波動，這時候退租舊主機才算安全。
退租前還有一個動作：把舊主機上的最後一份完整備份下載到本地，當作這次搬家的封存。這份封存等於一份保險，萬一幾個月後才發現某個頁面的舊版本在新站上遺失了，你還有原始資料可以對照復原。舊主機多留一兩週的費用，跟出問題時重新還原的時間成本相比，幾乎可以忽略，這也是整個流程裡少數「多花一點錢、省下大量風險」的務實選擇。
回滾劇本：出問題時如何安全退回舊站
即使流程再嚴謹，也要假設可能需要退回舊站。回滾劇本越早寫好，出事時越不慌。最乾淨的回滾方式是回到網域商後台，把 NS 改回舊主機原本的兩組位址，等 TTL 過期後，全球訪客就會重新連回舊站運作。這也是為什麼前面一再強調舊主機不能急著退租，舊主機在、回滾就只是改一行 NS；舊主機退了，回滾等於重新還原一次。
- 確認問題範圍：是全站故障，還是單一頁面或單一外掛？單點問題可在新站修，不必回滾。
- 若決定回滾，到網域商後台把 NS 改回舊主機的 NS1、NS2。
- 用 dnschecker.org 觀察解析是否回到舊 IP。
- 舊站恢復運作後，在新主機上排查問題根因，修好再擇日重新切換。
- 回滾期間若舊站有新增資料（如訂單），重新切換前要把這些資料補進新站。
常見問題 FAQ
WordPress 搬家到新主機會掉 SEO 排名嗎？
網域不變、流程走對，排名通常不受影響。會讓排名波動的，是 DNS 切太早導致空白頁、SSL 沒接好、或永久連結結構被改。把這三項顧好，搜尋引擎只會看到網站背後換了一組 IP。若搬家這段空檔怕自然流量暫時下滑影響生意，搭配 Google Ads 申請投放教學 用付費流量先補上缺口，也是務實的過渡做法。
WordPress 搬家後登入後台帳密不對怎麼辦？
還原會把新站的帳密覆蓋成舊站的，用舊站那一組就登得進去。連舊帳密也記不得的話，透過 phpMyAdmin 改 users 表的密碼雜湊即可。這是資料被覆寫，不是被駭。
WordPress 搬家後 SSL 要重新設定嗎？
要。新主機要重新申請 SSL，多數提供免費的 Let's Encrypt，一鍵申請、自動續期。啟用後記得到 WordPress 後台把網址改成 HTTPS 並強制 HTTPS，否則瀏覽器跳出「不安全」會連帶傷害 SEO。
怎麼確認搬家成功、網站正常運作？
DNS 生效後，抽看首頁、幾篇文章、選單、圖片與表單，至少五到十個頁面。再到 Google Search Console 看檢索與索引狀況，留意 404 或收錄異常。若還不熟這個工具，先看一篇 Google Search Console 入門介紹 把報表介面摸熟；想對比搬家前後的數據，記得善用 Search Console 自訂日期區間 框出搬家那天為基準，前後各拉一兩週才看得出變化。舊主機等新站跑穩幾天再關。
搬家時網域信箱會跟著斷線嗎？
會，這是最容易漏掉的盲點。DNS 一改，掛在同一網域的郵件服務也受影響。若信箱靠舊主機提供，務必在新主機先把郵件帳號與 MX、SPF、DKIM 紀錄抄齊並測試收發，或乾脆改用 Google Workspace、Microsoft 365 這類獨立郵件服務，讓信件走向完全不綁主機。郵件這一關要在切換 NS 前就處理好，不要等退信才補救。
WooCommerce 商店搬家要注意什麼？
WooCommerce 站多了訂單、庫存、付款這些活資料，從備份到還原的空窗期若有新訂單產生，新站會漏單。做法是挑訂單量最低的凌晨時段、用維護模式暫停結帳，把空窗交易量壓到最低，事後再手動補登。另外付款閘道的 API 金鑰與 Webhook 回呼網址搬到新站後要重新核對，否則可能收不到付款通知。搬家後立刻比對新站訂單數與舊站最後一筆，確認沒有漏單。