WordPress 搬家到新主機教學：零停機遷移關鍵步驟

把 WordPress 搬到新主機、又不想讓排名在一夕之間蒸發，真正的關鍵其實落在「你怎麼安排 DNS 切換的那一刻」，跟你最後選了哪一套搬家外掛的關係並不大。很多人卡在工具的選擇上猶豫太久，反而漏掉了真正決定成敗的幾個時間點與設定。很多站長把換主機想成一場賭博，怕一搬完客人就看到白畫面、怕 Google 把收錄頁面整批清掉。接下來我會把保留原網域、零停機搬家的完整流程拆開給你看：為什麼這其實是相對低風險的動作、兩站並行跑的觀念、DNS 切換那一刀怎麼切才不留尾巴，以及切完之後 72 小時你要盯著哪些指標。

三分鐘重點：保留原網域換主機的 4 個核心動作

1. 在新主機上把網站完整重建起來，DNS 先一行都不動。
2. 用臨時網址或自己電腦的 hosts file，在新主機上把所有功能測透。
3. 把 DNS 的 TTL 提前 24 到 48 小時降到 300 秒，再挑離峰時段切換 A 紀錄。
4. 舊主機至少保留 72 小時不要下架，邊收殘餘流量、邊盯 Google Search Console 的覆蓋報告。

換主機不換網址：這是相對安全的搬家類型

先安你的心。在所有「網站搬家」的劇本裡，「只換主機、網址完全不動」是風險最低的一種。原因很單純：你的每一個網址都沒變，所以 Google 已經收錄的那幾百、幾千個頁面，索引不必重建，內部連結結構不必重拉，也不必對每一個舊網址設一道 301 轉址。換句話說，你搬的是「房子後面的地基」，不是「門牌號碼」。

WordPress 是目前廣泛使用的內容管理系統，換主機、升級方案或從共享主機移轉到 VPS 與雲端主機都有成熟工具和文件可參考。普遍不代表沒有風險，仍應先備份、測試新環境、核對 DNS、SSL、排程與索引設定，再安排正式切換。

搬家常見的高風險環節包括 DNS 切換、資料庫連線與新主機的 SSL 憑證。把這些變數管住，能降低主要停機風險，但仍要一起檢查 Email、排程、快取、交易寫入與第三方服務。

如果這次連網址都要一起更換，工程會多出逐頁 301 轉址、序列化資料替換與 sitemap 更新，可參考WordPress 搬家到新主機＋新網域完整指南。這套流程的前提是網址不變，只搬移主機。

三種把搬家搞砸的方式，先把原理講清楚

要理解低停機搬家流程，得先知道故障怎麼發生。常見問題可先歸成以下三類；了解機制，才知道後面每一個步驟在防什麼。

這三個風險都有一個共同的特性：它們只會在「DNS 切換那一刻」之後才會被訪客看見。這就是為什麼整個零停機搬家的設計邏輯，都是圍繞著「把所有可能出錯的事，在 DNS 切換之前就先測掉」這個原則。

零停機的核心觀念：兩站並行跑，最後一刻才切 DNS

整個流程我用一個觀念貫穿：兩站並行、最後一刀。這個想法其實是從軟體工程的藍綠部署（blue-green deployment）借來的，套到 WordPress 搬家上一樣好用。

具體是這樣運作的：你的舊主機一直保持運作，繼續服務所有訪客。同時，你在新主機上把網站一份一份重建起來，讓它「也是一個可以正常回應你網域的完整副本」。這時候 DNS 還是指向舊主機，所以全世界的訪客都還是打到舊主機，完全感覺不到任何異動。你自己則是透過修改本機的 hosts file，把你的網域「提前」指到新主機的 IP，於是你的瀏覽器會連到新主機、看到新版網站，而其他所有人還在舊站上。

這個階段你盡情測試、修問題、調設定，都不會影響到任何一個真實訪客。等到新主機上的網站完全沒問題了，你才去動 DNS，把 A 紀錄指向新主機的 IP。從這一刻起，新連進來的訪客會逐漸被導到新主機，而舊主機繼續留著，接住那些 DNS 還沒更新到、還連到舊 IP 的殘餘流量。

直白地說，零停機真正的意思是「在任何一刻，都至少有一端能正常回應訪客」。只要新舊兩端都活著、都能正常回應，DNS 的傳播落差就只是一段過渡期，算不上災難。正因如此，我會一再強調：舊主機不要切完就馬上下架。

hosts file 不是唯一能「提前看到新站」的方法。另一條路是用臨時網址或預覽網域（staging subdomain），例如新主機配給你一個像 preview.你的網域.com 或一串臨時網址，讓你直接從那個網址瀏覽新版網站。兩種做法的目的完全一樣：在 DNS 正式切換之前，先讓你有辦法看到、測到新主機上的網站。

兩者的取捨是這樣：hosts file 的好處是你測的時候用的就是你正式上線的那個網域，SSL 憑證、cookie、絕對網址的行為都跟正式環境完全一致，測試結果最可信；缺點是只有改了 hosts 檔的那一台電腦看得到，要給同事一起測比較麻煩。臨時網址的好處是可以開給任何人看、方便協作；缺點是它畢竟不是正式網域，牽涉到網域的東西（SSL、cross-domain cookie、某些寫死網址的外掛）測出來可能跟正式環境有落差。實務上我偏好兩者並用：先用臨時網址做第一輪肉眼檢查，正式切換前再用 hosts file 做最後一輪精準驗證。

搬家前的準備工作，先把可預見風險降下來

搬家當天的實際切換通常只要十幾分鐘，但前面一週的準備才是勝負手。準備做足，當天就是照表操課；準備不足，當天就是半夜手忙腳亂、邊修邊祈禱。這張清單，是你在切換 DNS 之前要全部打勾的事。

• 主機環境一致性：新主機的 PHP 版本、MySQL 版本、memory_limit、必要的 PHP 擴充功能（imagick、xml、mbstring、curl 這些 WordPress 常用的），都要跟舊主機對齊，或至少符合你佈景與外掛的最低需求。環境落差是搬家後白畫面的常見元兇。如果你還在挑主機，可以參考 WordPress 官方維護的 推薦主機清單，先從共享主機、VPS、雲端主機這幾種類型裡挑出符合你流量與預算的方案。若考慮搬進 A2 Hosting，可以先看A2 Hosting 的面板導覽與搬入設定，熟悉新環境的面板與搬入流程。如果已經鎖定特定品牌，例如計畫把站搬進 HostGator，可以先讀HostGator 共享主機的方案與配額檢查，確認新環境的資源條件再排搬家時程。
• 完整備份：檔案和資料庫都要備，而且要存在「不是這兩台主機」的第三個地方，例如本機硬碟或雲端硬碟。搬家的時候最怕備份跟著主機一起出事。完整做法看WordPress 備份與還原完全指南，工具挑選可以參考 UpdraftPlus 這類主流方案，它是 WordPress.org 外掛目錄上最廣為使用的備份外掛之一，操作邏輯相當直覺。如果你不確定哪一套搬家工具適合你的站，可以先把WordPress 搬家外掛推薦看過一遍。
• DNS TTL 預先調低：在你打算切換的 24 到 48 小時之前，把網域 DNS 紀錄的 TTL（Time To Live）改成 300 秒。這個數字代表全球的 DNS 解析器「最多可以把你的舊 IP 快取多久」。TTL 越短，你切換 IP 之後，全世界跟上新 IP 的速度越快。這一步千萬不能省，後面會再詳細講。
• 盤點動態內容：留言、新訂單、聯絡表單、會員註冊，這些是「會持續寫進資料庫」的內容。你要先想好：在備份之後、DNS 切換之前這段時間，舊主機上新增的資料要怎麼帶過去。最簡單的做法是挑一個低流量的離峰時段、把這段窗口壓到最短，或甚至短暫開啟維護模式。
• 收齊憑證：新舊主機、FTP、SSH、控制台、資料庫與 DNS 後台的登入資訊先確認可用。密碼與 Secret 應放在受保護的密碼管理器或團隊指定的安全儲存位置，不要集中寫進一般文件。
• 挑離峰時段：以台灣繁中市場來說，周末凌晨一到四點通常流量最低。就算 DNS 傳播出了點狀況，影響到的訪客也最少，你也有充足時間在白天流量回來之前把問題處理乾淨，這段緩衝對電商站尤其重要。

第一階段：在新主機把網站完整重建（DNS 還沒切）

這個階段的目標，是讓新主機上出現一個跟你原網站一模一樣、而且能正常回應你網域的副本。注意，這時候 DNS 一行都還沒改，所以對全世界來說你的網站還是舊的。你只是在「後台」默默把新房子蓋好。

流程是這樣的：

1. 在新主機裝好一個空的 WordPress。多數主機商都會提供一鍵安裝，或者你也可以手動裝，過程跟初次架站完全一樣。
2. 把舊主機的 wp-content 整個複製到新主機。這個資料夾裡裝著你的佈景（themes）、外掛（plugins）、以及所有上傳的圖片與檔案（uploads）。上傳方式可以用 FTP，也可以用主機後台的檔案管理員壓縮打包後上傳，後者對大站來說快很多。
3. 匯出舊主機的資料庫，匯入新主機的資料庫。用 phpMyAdmin 匯出成 .sql 檔，再到新主機的 phpMyAdmin 匯入。大站資料庫如果超過上傳限制，可以分批匯入或請主機商暫時調高限制。
4. 改 wp-config.php 的四個常數：DB_NAME、DB_USER、DB_PASSWORD、DB_HOST。新主機的資料庫名稱、帳號、密碼、主機位置通常跟舊主機不同，這是最容易漏掉的一步，也是「Error establishing a database connection」最常見的原因。
5. 用 hosts file 在自己電腦上提前瀏覽新站。這是整個零停機流程最關鍵的技巧。你打開自己電腦的 hosts 檔（Mac 或 Linux 是 /etc/hosts，Windows 是 C:\Windows\System32\drivers\etc\hosts），加一行「新主機的 IP 加上你的網域」，存檔後，你的瀏覽器就會把你的網域指到新主機。於是全世界還在舊站，只有你看到的是新站。

這裡要特別點出一個「保留原網域搬家」最大的紅利。因為你的網址完全沒變，文章、圖片、內部連結裡的每一個 URL 都還是正確的，你幾乎不需要做序列化資料的 search-replace。序列化字串裡的舊網址替換，是「換網域」搬家最頭痛的工程，一個沒處理好，整個佈景的 widget 設定、外掛選項就會壞掉。而保留原網域搬家，完美閃掉了這個坑。正因如此，我一直強調，這是一種相對安全的搬家類型。

第二階段：在新主機上把所有功能測透

hosts file 改好之後，你的電腦已經連得到新主機上的網站了。這時候請你用「一個挑剔的訪客」的心態，把站上每一個會動的東西都點一遍。這個階段測得越徹底，DNS 切換那天就越輕鬆。下面的清單是每一次搬家前都建議走一遍的項目。

• SSL 憑證佈署：在新主機上先用 Let's Encrypt 這類免費來源把憑證核發下來。確認 https 開頭的網址能正常打開、鎖頭圖示是綠色的、沒有混合內容警告。SSL 對 SEO 與信任的影響，可以看SSL 憑證完整教學。
• 永久連結重新儲存：到後台「設定 → 永久連結」，什麼都不用改，直接按兩次「儲存」。這個動作會強制 WordPress 重新產生網址重寫規則（rewrite rules），能解掉搬家後常見的 404 問題。
• 內部連結與圖片：隨機點開幾篇文章，看圖片有沒有正常顯示、內部連結會不會跑到 404。圖片如果還指向舊主機的網址，多半是因為搬移過程漏了檔案。
• 表單、購物車、登入頁：聯絡表單寄一封測試信給自己、購物車走一趟結帳流程（但不要真的送出訂單）、後台登入頁確認能登入。這些動態功能最容易在新主機的權限或 PHP 設定不一致時出問題。
• 外掛與佈景版本對齊：新主機上的外掛、佈景版本要跟舊主機一致。如果新主機用的是一鍵安裝的全新 WordPress，可能會裝到比較新的版本，造成行為差異。
• 暫時關掉快取：測試期間把快取外掛先停掉，否則你看到的可能是舊的快取頁面，會誤判問題已經解決。等切換穩定後再開回來。

這些都測完、新站上每一個功能都跟舊站一樣能正常運作，你就可以準備進入下一個階段，也就是真正動 DNS。

第三階段：DNS 切換那一刀

前面所有準備，都是為了這一刻。但諷刺的是，當你準備做足，這一刀本身反而非常平淡。你只是去 DNS 代管商的後台，把 A 紀錄的 IP 從舊主機換成新主機，存檔，然後等。真正容易出事的是「等」這段時間的認知落差。

先講那個提前降 TTL 的動作為什麼關鍵。DNS 不是一個即時同步的系統，它是一個層層快取的分散式查詢。當某個台灣的 ISP 解析器問過你的網域、拿到舊 IP 之後，它會把這個答案快取一段時間，這段時間就是 TTL。如果你在切換前沒有先把 TTL 調低，那麼全球各地的解析器可能會把你的舊 IP 快取好幾個小時甚至好幾天，你已經把紀錄改到新主機了，但很多訪客還是被送到舊主機。把 TTL 提前 24 到 48 小時降到 300 秒，等於是告訴全世界「我接下來要變更，請你五分鐘後重新來問一次」。

就算降了 TTL，DNS 傳播也不是瞬間完成的。根據 Cloudflare 對 DNS 傳播的說明，全球的 DNS 解析器更新一份新紀錄，往往需要最長約 48 小時的窗口才會完成。這也是為什麼舊主機在切換後還要繼續留著跑一段時間。DNS 的運作原理與紀錄設定，看DNS 網域指向設定教學會更清楚。

切換那一天，照這個順序走：

1. 確認 hosts file 測試的結果一切正常，新主機真的準備好了。
2. 到 DNS 代管商後台，依主機商提供的目標修改 A／AAAA 紀錄；若使用 CNAME，目標應是主機名稱而不是 IP 或完整 URL，根網域能否使用則依 DNS 供應商的 flattening／ALIAS 支援而定。
3. 存檔後，用 dig 或線上 DNS 查詢工具（例如 nslookup.io）從不同地區確認新 IP 開始傳播。
4. 把舊主機保持上線，什麼都不要關。它會繼續接住那些 DNS 還沒更新的訪客。

這裡有一個新手超容易踩的雷：郵件 MX 紀錄。如果你的 email 是放在別的地方，例如 Google Workspace 或 Microsoft 365，那麼你在改 DNS 的時候千萬不要去動 MX 紀錄。很多人以為「搬家」就是把整個網域的 DNS 全部搬過去新主機代管，結果 MX 一跟著改，公司信箱立刻收不到信。原則是：這次只改指向網站的那一筆紀錄，其他跟網站無關的紀錄（MX、SPF、DKIM、DMARC）維持原樣。

順著這個雷，再多講一個新手常搞混的觀念：到底是改 A 紀錄、改 CNAME、還是把整組 nameserver 換掉？這三者差很多。A 紀錄是把你的網域（或某個子網域）直接指向一個 IP 位址，這是你自己架站、主機商給你一組固定 IP 時最常見的打法。CNAME則是把你的網域「別名」指向另一個網址，主機商給你一個像 xyz.cloudwaysapps.com 這樣的位址時就用這個，好處是主機商背後換 IP 你也不必跟著改。換 nameserver則是完全把整個網域的 DNS 代管權交給另一家（例如從原本的網域商交給 Cloudflare），這會一口氣搬走所有紀錄，風險最高，電商站的郵件、驗證紀錄全都得重新檢查一遍。

保留原網域、只換主機的搬家，多數時候你只需要動 A 紀錄或 CNAME 那一筆，nameserver 完全不用碰。這也是這類搬家相對單純的原因之一：你能動到的東西少，能出錯的範圍就小。如果你不確定自己現在的 DNS 是怎麼設的，在動任何紀錄之前，先把後台現有的每一筆紀錄截圖或抄下來留底，萬一改壞了還能照原樣還原。

第四階段：切換後 72 小時的驗證清單

DNS 切下去之後，工作還沒結束。接下來的 72 小時是觀察期，你要用數據確認「搬家真的沒事」，不能只靠感覺。接下來這幾項是我會在切換後持續盯著的指標。

• Google Search Console：因為你的網域沒變，所以 GSC 的 property 不必重新驗證、資料也不會歸零。但你要主動去確認「覆蓋報告」沒有突然冒出一批 404 或伺服器錯誤，「效能報告」的曝光與點擊沒有異常下滑，並且手動重新提交一次 sitemap。GSC 的完整操作看Google Search Console 教學。
• 全站 404 與混合內容掃描：用爬蟲工具（Screaming Frog、或免費的線上掃描器）從新主機 IP 抓一遍全站，看有沒有 404 連結、有沒有圖片還走 http。這類問題在 hosts file 測試時可能因為你自己已登入而看不到。
• Core Web Vitals 基線：新主機的反應速度可能比舊主機快、也可能慢。搬完立刻量一次 LCP、INP、CLS，當作新基線。指標的優化觀念看Core Web Vitals 完全攻略。如果發現新主機反而變慢，要認真評估是不是該換方案或加掛快取。
• 舊主機流量觀察：看舊主機的訪問 log，確認流量在切換後逐步歸零。等連續兩天都幾乎沒有訪客了，再正式下架。太早關舊主機，等於把還沒跟上 DNS 傳播的訪客推向斷線。
• 排名與流量監控：用 GSC 或你習慣的排名追蹤工具觀察一週。如果看到異常下滑，先別慌，按排名下滑的排查流程逐項檢查，多半是某個技術細節沒接好。
• 檢查「是否阻止搜尋引擎索引」：這是我每一次搬家都會親自翻一次的開關。有些新主機在一鍵安裝 WordPress 時，會貼心地幫你把「設定 → 閱讀 → 抵制搜尋引擎索引此站」打勾（因為他們假設你還在建構中）。如果你沒有在切換前把它關掉，新站就會對 Google 回傳 noindex，輕則延後收錄、重則幾週內流量崩跌。這個開關藏在後台一個不起眼的角落，卻是搬家後排名無聲消失的常見兇手之一。

切下去才發現出事：撤回 DNS 還是往前推，這中間有一條決策線

前面那套低停機流程，前提是準備完整、切換順利。但 DNS 切換後，新主機仍可能出現 hosts file 測試沒發現的問題，例如金流 webhook 收不到、整站間歇性 500，或 PHP 設定讓關鍵外掛報錯。這時要在把 DNS 撤回舊主機與留在新主機修復之間做判斷，搬家並不是單行道。

先把判斷的決策線畫清楚。你可以把「出事的類型」分成兩種，處理方向完全相反：

• 設定類問題（404、白畫面、混合內容、永久連結、單一外掛衝突）：如果主機仍可用且根因明確，留在新環境修復可能比撤回更快。DNS 撤回也要等待各地快取更新，實際時間受 TTL 與解析器行為影響，不能保證固定幾分鐘完成。
• 整站性故障（全站 5xx、資料庫連不上、SSL 憑證完全沒核發、新主機整台回應不了）：這類問題的修復時間不可預測，可能要動到主機商客服、可能要重灌環境。這時候撤回才是對的，先把流量導回舊主機讓網站活著，再回頭慢慢修新主機。

決策核心是比較預估修復時間、故障影響與撤回成本，而不是套用固定 15 分鐘門檻。若交易、登入或全站可用性受到重大影響，而且根因與修復時間仍不明，就應依事先定義的回復條件撤回；局部且可快速驗證的設定問題則可留在新主機修復。

撤回還有資料一致性的風險。切換後的新訂單、留言與會員資料只存在新資料庫時，直接把 DNS 指回舊站會讓這些寫入在舊後台看不到。不要自行把整份新資料庫反向覆蓋舊站；應先凍結寫入，依應用程式與資料表關聯做資料比對及合併，交易站最好由熟悉 WooCommerce 或該系統資料模型的人處理。事先縮短切換窗口，才是降低這類風險的主要方法。

正式切換前，應在 staging 或書面 runbook 演練撤回：記錄如何把 DNS 指回舊主機、如何確認舊站可接流量，以及切換後新寫入資料要如何處理。交易資料的合併不要只在腦中演練，也不要把「反向同步」簡化成整庫覆蓋。

搬家後 WordPress 信件寄不到？PHP mail 與 SMTP 是兩條獨立的管線

有一類搬家後遺症症狀很隱晦，可能一兩週才被發現：表單通知信沒收到、新會員收不到密碼重設信、WooCommerce 訂單確認信進了顧客的垃圾箱、甚至完全沒寄出。原因是多數站長以為「換主機跟寄信沒關係」，但實際上 WordPress 寄信這件事，跟主機綁得比你想的緊。

先把兩條常被搞混的管線分清楚。MX 紀錄決定寄到網域信箱的收信路徑，搬家時通常不必更動。WordPress 則透過 wp_mail() 寄出通知，實際傳輸可能使用主機郵件服務、SMTP 或 API，取決於目前設定。若原本依賴主機預設郵件管線，換主機就可能改變寄信結果。

問題就出在這裡。很多新主機，特別是共享主機與低階方案，基於濫用防護要嘛直接禁用 PHP mail()，要嘛允許但從一個信譽較差的 IP 段發出來。信譽差的結果是，你的通知信還沒進到顧客的收件匣就被 Gmail、Outlook 這類大型信服務判斷為垃圾信或直接丟棄。搬家前信件都很正常，搬家後無聲無息地斷掉，是最常見的劇本。

解法不是去跟新主機的 mail server 奮鬥，而是趁這次搬家順手把 WordPress 的發信切到獨立的 SMTP relay 服務。主流的選擇有 SendGrid、Postmark、Amazon SES、Brevo（原 Sendinblue）這類，它們的商業模式就是「專門幫你把交易信可靠地送到收件匣」，信譽維護、退信處理、開信追蹤都幫你做好。設定方式是用 WP Mail SMTP 這類外掛把 WordPress 的發信方式從 PHP mail 改成 SMTP，填入 SMTP 服務的帳號密碼與伺服器位址即可。

使用第三方寄信服務時，要依供應商文件設定 SPF 與 DKIM，並確認寄件網域符合 DMARC 對齊。DMARC 可由對齊的 SPF 或 DKIM 通過，不是只加 SPF 就一定成功；網域也只能有一筆 SPF 記錄，新增服務時要合併而非重複建立。如果搬家前已使用外部 SMTP 或 API，仍要確認新主機的連線、防火牆與 Secret 設定是否完整。

切換後的驗證動作很輕卻很關鍵：用 WP Mail SMTP 的測試功能寄一封信到自己的一個外部信箱（不要用同網域的信箱測，那測不準），檢查信件有沒有進收件匣、有沒有被標垃圾。表單、密碼重設、訂單確認這三條最關鍵的通知路徑，各實際走一次。這十幾分鐘的測試，可以避免你三週後才被顧客反應「我都沒收到你的信」。

大站搬法完全不同：WP-CLI、SSH 與託管型 WordPress 主機為什麼不能套用標準流程

phpMyAdmin、FTP 與後台檔案管理員是否夠用，取決於主機的上傳限制、執行時間、資料庫大小與連線穩定度，沒有通用的 50 或 100 MB 分界。當瀏覽器工具反覆逾時，或檔案量已不適合整包傳輸時，就應改用 SSH、命令列或主機商的遷移工具。

進入這個層級，常會使用 SSH 與 WP-CLI。命令列不受瀏覽器上傳限制，但仍可能受伺服器資源、SSH 工作階段、代理或主機政策限制，不能說完全沒有逾時問題。典型做法如下：

• 資料庫用 mysqldump 直接匯出成 .sql 檔，再用 mysql 命令列匯入新主機，全程命令列、不受 phpMyAdmin 的 upload_limit 限制。
• wp-content 用 rsync 同步，rsync 會比對新舊兩邊的檔案差異，只傳輸有變動的部分。對好幾 GB 的上傳資料夾來說，這比整個打包上傳快非常多，而且中斷後可以接續續傳。
• 用 WP-CLI 處理搜尋取代、永久連結、快取清除，例如 wp search-replace 處理資料庫裡的舊網址（這次保留原網域的搬家原則上用不到，但若你之後也要換網域會用到）、wp rewrite flush 重新產生網址重寫規則、wp cache flush 清快取。這些動作在後台點按鈕會跑很久甚至逾時，WP-CLI 是秒級完成。

託管型 WordPress 主機通常把快取、備份、搬家、SSL 或 CDN 整合進控制台。搬入前應優先查該主機的官方遷移流程與禁用外掛清單，因為伺服器快取、物件快取與通用外掛的設定可能重複或衝突；若官方工具不適用，再選擇可驗證與可回復的替代方式。跨品牌搬家前怎麼套用這些檢查，可以參考從 A2 升級到 hosting.com 的搬家評估。

從共享主機升級到託管型 WordPress 主機，是很多人這次搬家真正的目的。取捨要誠實看：託管型方案的成本通常是同等規格共享主機的數倍，但你換到的是更穩定的效能、不再需要自己調快取與備份外掛、以及出事時能找到懂 WordPress 的客服。對流量大到共享主機已經在頻繁限流的站，這個升級通常立竿見影；對流量還沒上來的小站，這筆預算可以暫緩。決策的關鍵不是「別人說託管型比較好」，而是「你現在的主機在尖峰時段是不是已經在拖累你的 Core Web Vitals」。如果是，升級是投資；如果還不是，先搬同等級、把錢留在內容與推廣上，回報通常更高。WordPress 整體維運的系統性觀念，可以搭配WordPress SEO 完整指南一起看，把主機、效能、搜尋最佳化當成同一條線來思考。

你跑的是 WooCommerce 或交易型網站嗎？再多兩道保險

如果你的站是用 WooCommerce 架的電商，或任何會在資料庫裡即時寫入交易資料的網站，風險等級會跳一級。依 W3Techs 的統計（2026 年 6 月），WooCommerce 在全球電商平台類的市佔是第一名，使用量非常大。也就是說，這個「搬家風險」影響的站長數量，遠比你想像的多。

交易型站最大的麻煩，是「DNS 空窗期的新訂單會落在舊資料庫」。想像一個情境：你已經把資料庫搬到新主機了，但 DNS 還在傳播，這時候某個顧客因為解析器還沒更新，連到了舊主機，下了一筆訂單、付了錢。這筆訂單只存在舊主機的資料庫裡，新主機完全看不到。如果你太早把舊主機關掉，這筆訂單就憑空消失了。對一個做生意的站來說，這是不能接受的失誤。

所以跑交易型站的搬家，要在前面那份清單之外，再加兩道保險：

• 排定下單凍結窗口：挑一個明確的離峰時段（例如凌晨兩點到四點），在這段時間用維護模式外掛把站暫時關閉、公告「系統維護中」。維護模式會擋住新的寫入，保證這段時間沒有新訂單、沒有新會員。等資料庫最後一次同步完成、DNS 切換好，再把維護模式關掉。這樣就不會有訂單遺落在舊資料庫。
• 切換前最後一次資料庫同步：在維護模式開啟之後、DNS 切換之前，再做一次從舊資料庫匯出、匯入新資料庫的動作，把維護模式開啟前那短短時間的動態資料（留言、訂單、會員更新）補進新主機。這樣新主機上的資料就是完全最新的。

還有兩個電商搬家要特別留意的點：金流與第三方服務的 webhook。多數金流服務（綠界、Stripe、PayPal 這類）的 webhook 通知網址是指向你的網域，所以 DNS 一切換，它就會自動跟著連到新主機，理論上不需要改設定。但理論歸理論，務必在新站上跑一筆小額測試訂單、走完完整付款流程，確認 webhook 真的能收到、訂單狀態真的能更新。庫存同步、會員 session 是存資料庫還是存檔案，也要確認一下設定。

把「換主機」變成 SEO 加速機會

多數人把搬家當成「一個要熬過去的風險」，但其實換個角度想，這是一次順手把網站變快的機會。Google 在 web.dev 上明確指出，網頁速度會直接影響使用者體驗與轉換，速度差的站會在還沒傳達價值之前就流失訪客。換到一台反應更快的主機，等於是一次免費的效能升級，而更快的載入速度有機會回饋到 Core Web Vitals 與搜尋表現上。

所以搬家的時候，順手做這幾件事，把風險變成紅利：

• 清理沒在用的外掛：每多一個外掛就多一份載入負擔。趁這次盤點，把停用超過半年沒碰的外掛直接刪掉，別只是停用。
• 啟用快取與 CDN：新主機的快取機制要重新設定，頁面快取、物件快取（object cache，例如 Redis）、OPcache 都確認開啟。
• 圖片優化一波：把上傳資料夾裡的圖片跑一次壓縮、轉成 WebP、啟用延遲載入，趁這次把長久沒處理的大圖清乾淨，效果通常立竿見影。
• 確認追蹤碼與驗證：Google Analytics、GSC 驗證、Search Console 的 sitemap 提交、canonical 設定，全部重新檢查一遍。

一個常見的疑問是：換主機之後要不要主動通知 Google？答案是不必。Google 是靠爬蟲定期造訪你的網站來發現變化的，它會自己注意到你的伺服器 IP 變了、速度變了。你真正要做的，是確保新主機能正常被爬蟲抓取（沒有封鎖、沒有 5xx 錯誤），這就夠了，不必特地跑去某個後台「通知」它。把視角拉高來看，換主機其實只是整個網站維運與改版工程裡的一個環節，不要急著在搬完當下就做太多 SEO 動作。

搬家後網站怪怪的？用這張症狀對照表快速定位

就算流程走得很謹慎，切換後的頭幾個小時還是可能冒出一些小狀況。問題不在於「會不會出事」，而在於「出事的時候你能不能快速看出是哪一環」。我整理了一張症狀對照表，把搬家後最常見的異常、它背後最可能的成因、以及第一時間該怎麼處理，通通對齊在一起。切換後只要網站有任何不對勁，先來對這張表，比你在後台漫無目的地翻設定快得多。

這張表有一個使用上的前提：在你動手修之前，先確認你看到的症狀是發生在「新主機」還是「舊主機」。切換後的 48 小時內，你自己瀏覽器連到的可能是舊主機（因為 DNS 還沒傳播到你這一端），這時候你去新主機改設定當然沒用。判斷的方法是先 ping 一下網域，看回來的 IP 是新主機還是舊主機，再決定要去哪一邊除錯。這個小動作可以幫你省下大量瞎忙的時間。

如果你的站是從本機搬到正式主機、或之前用 MAMP 這類本機環境架站，症狀排查的邏輯也一樣：先確認連到的是哪一台、再對照成因。換主機與本機上線，本質上處理的都是「環境差異造成的設定錯位」。

搬家常見的翻車原因

搬家失誤多半不是罕見事件，而是平常容易忽略的設定沒有跟著移轉。以下整理幾種常見原因，方便上線前逐項核對。

例如切換前沒有先調整 TTL，部分解析器可能在既有快取到期前仍指向舊主機；又或者 wp-config.php 的 DB_HOST 沒換成新主機提供的值，導致資料庫連線錯誤。localhost 在某些主機仍是正確值，不能只看字面判斷，應以供應商給的連線資訊為準。

另一個常見的坑是新主機少裝了某個 PHP 擴充功能，結果某個外掛在前台跑出白畫面，但後台卻正常，因為那個外掛只在特定頁面用到那個擴充功能。還有一種更隱晦的：舊主機上原本設了 cron job 定時跑備份或排程發文，搬家的時候只搬了檔案和資料庫，沒人意識到 cron job 是主機層級的設定，於是新主機上排程發文從此沒再觸發過，直到讀者反應才知道。

SSL 憑證的續約也是高頻事故。Let's Encrypt 的憑證每 90 天要續約一次，新主機通常會幫你設好自動續約，但如果你是手動申請的、或主機的自動續約沒設定成功，三個月後憑證一過期，整站瞬間從 https 掉成不安全的警告頁面，排名與轉換一起往下掉。搬家後請務必確認憑證是有排程自動續約的。

這些故事背後的道理都一樣：搬家真正會出錯的地方，幾乎都卡在某個設定、某個排程、某個憑證沒被帶過來，跟搬家外掛夠不夠強沒太大關係。正因如此，我前面花了那麼多篇幅講測試清單與驗證流程。

搬家當天的逐項打勾表

把上面所有流程濃縮成一張你可以照著走的行動清單。建議你把這一段存起來，搬家當天對著一項一項打勾。

1. 前一週：買新主機、確認 PHP 與 MySQL 版本一致、做第一次完整備份（檔案加資料庫），存到第三個地方。
2. 前 48 小時：到 DNS 代管商後台，把網域的 TTL 改成 300 秒。
3. 前 24 小時：在新主機上把 WordPress 裝好、wp-content 上傳、資料庫匯入、wp-config 改好、SSL 憑證佈署完成。
4. 測試日：改 hosts file，在自己的電腦上把新站上的每一個功能（圖片、連結、表單、購物車、後台登入）全部點過一遍。
5. 切換日離峰時段：開啟維護模式（交易型站），做最後一次資料庫同步，到 DNS 後台把 A 紀錄改成新主機 IP，存檔。
6. 切換後幾天：檢查 Google Search Console 的網頁索引報表、掃全站 404、量 Core Web Vitals 基線，並觀察舊主機流量是否逐漸歸零。
7. 確認穩定後：等既有 TTL 到期、舊主機存取日誌趨近於零，並完成交易、Email、排程與備份驗證，再依主機合約正式下架舊環境。

保留原網域的 WordPress 搬家，換句話說，就是把「可能出錯的事全部提前測掉，再挑一個離峰時刻優雅地切換 DNS」。它不是賭博，是一套有紀律的流程。準備做足了，搬家那天你甚至可以從容地泡杯咖啡，看著 DNS 傳播進度條慢慢推進。記得兩個最容易壞事的地方永遠是同一組：DNS 切換的時機，以及那些「跟著主機跑、卻沒被你想到的設定」（資料庫連線、SSL 自動續約、cron 排程、索引開關）。把這幾個變數盯緊，剩下的細節多半能在 hosts file 測試階段就處理乾淨。

如果你這次連網址也要一起換、或站上跑的是複雜的多站網路、電商金流整合，需要有人陪你走一次，SEO 搬家改版的風險評估是另一個值得先讀的起點。把這套流程走穩，你的排名、你的訪客、你的訂單，都會安安穩穩地跟著搬到新家。