WordPress 搬家到新主機：DNS 切換、資料同步與驗證

保留原網域換 WordPress 主機時，先在新環境還原並測試，再同步最新資料與切換 DNS，可降低服務中斷風險。本文會說明新舊主機並行、交易寫入控制、憑證、郵件及切換後驗證；這些準備不能保證零停機或排名完全不波動。

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

1. 在新主機上把網站完整重建起來，DNS 先一行都不動。
2. 用臨時網址或自己電腦的 hosts file，在新主機上把所有功能測透。
3. 依原 TTL 和 DNS 供應商限制提前降低 TTL，再於實際離峰時段切換網站的 A／AAAA 或 CNAME 紀錄。
4. 保留舊主機至 DNS 與流量轉移完成，確認交易、排程與爬蟲都已正常使用新環境，再安排停用。

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

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

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

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

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

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

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

這些問題可能在測試時或正式切換後出現。應盡量於 DNS 切換前驗證，再保留可執行的撤回流程與切換後監控；測試通過不代表所有網路與外部服務都已驗證。

低停機的核心觀念：先測新站，再同步資料與切換 DNS

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

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

新環境若使用正式資料或憑證，測試仍可能寄出通知、扣款或呼叫正式 API。應限制存取、隔離排程與 webhook，改用沙盒或測試收件人。測試完成後再同步最新資料及切換 DNS，舊主機暫時保留但不可未經規劃繼續接收獨立交易寫入。

新舊兩端都能回應，有助於降低 DNS 快取過渡的中斷；但對交易站，還須確保只有受控的寫入來源。若兩個獨立資料庫同時接單，單靠主機都在線並不能避免訂單分裂或重複處理。

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

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

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

搬家時間取決於檔案、資料庫、外部整合及可用工具。請事先排定資料同步、測試、切換與撤回窗口，不能先假設切換一定只需十幾分鐘。

• 主機環境一致性：核對新主機的 PHP、資料庫、memory_limit 及所需擴充，使用仍受安全維護且與 WordPress、主題及外掛相容的版本。不要為了與舊站一致而沿用已停止安全更新的環境。環境落差是搬家後白畫面的常見元兇。如果你還在挑主機，可以參考 WordPress 官方維護的 推薦主機清單，先從共享主機、VPS、雲端主機這幾種類型裡挑出符合你流量與預算的方案。若考慮搬進 A2 Hosting，可以先看A2 Hosting 的面板導覽與搬入設定，熟悉新環境的面板與搬入流程。如果已經鎖定特定品牌，例如計畫把站搬進 HostGator，可以先讀HostGator 共享主機的方案與配額檢查，確認新環境的資源條件再排搬家時程。
• 完整備份：檔案和資料庫都要備，而且要存在「不是這兩台主機」的第三個地方，例如本機硬碟或雲端硬碟。搬家的時候最怕備份跟著主機一起出事。完整做法看WordPress 備份與還原完全指南，工具挑選可以參考 UpdraftPlus 這類主流方案，它是 WordPress.org 外掛目錄上最廣為使用的備份外掛之一，操作邏輯相當直覺。如果你不確定哪一套搬家工具適合你的站，可以先把WordPress 搬家外掛推薦看過一遍。
• DNS TTL 預先調低：至少提前一個原 TTL 週期修改，並考慮供應商限制與既有快取。300 秒只是可選範例，不是所有服務都允許，也不是全球訪客五分鐘內一定更新的保證。
• 盤點動態內容：留言、新訂單、聯絡表單、會員註冊，這些是「會持續寫進資料庫」的內容。你要先想好：在備份之後、DNS 切換之前這段時間，舊主機上新增的資料要怎麼帶過去。最簡單的做法是挑一個低流量的離峰時段、把這段窗口壓到最短，或甚至短暫開啟維護模式。
• 收齊憑證：新舊主機、FTP、SSH、控制台、資料庫與 DNS 後台的登入資訊先確認可用。密碼與 Secret 應放在受保護的密碼管理器或團隊指定的安全儲存位置，不要集中寫進一般文件。
• 挑離峰時段：依自己的交易與流量數據、客服和主機支援時間安排，不能假定台灣網站一律在週末凌晨流量最低。

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

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

流程是這樣的：

1. 在新主機裝好一個空的 WordPress。多數主機商都會提供一鍵安裝，或者你也可以手動裝，過程跟初次架站完全一樣。
2. 把舊主機的 wp-content 整個複製到新主機。這個資料夾裡裝著你的佈景（themes）、外掛（plugins）、以及所有上傳的圖片與檔案（uploads）。還須盤點 wp-config.php、伺服器規則、mu-plugins、特殊目錄與環境設定。上傳可用 SFTP，也可以用主機後台的檔案管理員壓縮打包後上傳，後者對大站來說快很多。
3. 匯出舊主機的資料庫，匯入新主機的資料庫。用 phpMyAdmin 匯出成 .sql 檔，再到新主機的 phpMyAdmin 匯入。大站資料庫如果超過上傳限制，可以分批匯入或請主機商暫時調高限制。
4. 改 wp-config.php 的四個常數：DB_NAME、DB_USER、DB_PASSWORD、DB_HOST。新主機的資料庫名稱、帳號、密碼、主機位置通常跟舊主機不同，這是最容易漏掉的一步，也是「Error establishing a database connection」最常見的原因。 也要核對資料表前綴、特定主機常數與路徑；不要只因四個 DB 常數正確就視為組態已完整。
5. 用 hosts file 在自己電腦上提前瀏覽新站。這能協助以正式網域測試新主機，但只影響本機的名稱解析；金流回呼與其他外部服務仍需另外驗證。你打開自己電腦的 hosts 檔（Mac 或 Linux 是 /etc/hosts，Windows 是 C:\Windows\System32\drivers\etc\hosts），加一行「新主機的 IP 加上你的網域」，存檔後，你的瀏覽器就會把你的網域指到新主機。於是全世界還在舊站，你的電腦可先連到新主機；仍要確認 IPv6、代理與瀏覽器 DNS 快取沒有讓請求走到舊站。

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

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

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

• SSL 憑證佈署：切換前在新主機準備有效憑證，可用 Let's Encrypt 這類免費來源把憑證核發下來。DNS 尚未指向新主機時，HTTP-01 驗證未必會到新站，可評估 DNS-01 或主機商支援的方式。確認憑證網域、有效期、信任鏈與 HTTPS 正常，不以綠色鎖頭作唯一判斷。SSL 對 SEO 與信任的影響，可以看SSL 憑證完整教學。
• 永久連結：確認結構未改；必要時儲存一次以更新 rewrite rules。Apache／LiteSpeed 的 .htaccess 與 Nginx 規則需分別核對，反覆按兩次不是必要步驟。
• 內部連結與圖片：檢查檔案、權限、大小寫、URL、CDN 及回應狀態。同網域搬家時，URL 文字不會直接顯示來源是哪台主機，不能只看圖片網址判斷漏檔。
• 表單、購物車與登入：在隔離設定下測試通知與沙盒交易，含付款回呼、訂單狀態與庫存；只走到結帳頁而不提交，無法驗證完整流程。
• 外掛與佈景版本對齊：新主機上的外掛、佈景版本要跟舊主機一致。如果新主機用的是一鍵安裝的全新 WordPress，可能會裝到比較新的版本，造成行為差異。
• 暫時關掉快取：測試期間把快取外掛先停掉，否則你看到的可能是舊的快取頁面，會誤判問題已經解決。等切換穩定後再開回來。

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

第三階段：DNS 切換那一刀

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

DNS 回應有快取期限。降低 TTL 只影響之後取得的新回應，已快取的舊值仍可能等原期限到期；請依既有 TTL 提前安排，並從多個網路及實際伺服器日誌驗證，不能把 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. 保留舊主機服務過渡流量，但依寫入與排程計畫限制舊站動作，避免新舊兩邊分別接單或重複寄信。

若郵件服務獨立於網站，搬網站時通常保留 MX、DKIM、DMARC 等設定；但也要核對 MX 目標是否依賴被修改的 A／AAAA，以及 SPF 是否授權舊主機發信。若更換 nameserver，須先完整複製所需紀錄，不能只搬網站那一筆。

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

只換網站主機時，通常可保留原 DNS 代管商，依新主機提供的值調整網站相關的 A、AAAA 或 CNAME 紀錄。還要檢查 www、其他子網域與 CDN 代理設定；不要順手改動郵件紀錄。修改前匯出或記錄現有設定，並確認每一項變更的用途。

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

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

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

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

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

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

• 設定類問題（404、白畫面、混合內容、永久連結、單一外掛衝突）：如果主機仍可用且根因明確，留在新環境修復可能比撤回更快。DNS 撤回也要等待各地快取更新，實際時間受 TTL 與解析器行為影響，不能保證固定幾分鐘完成。
• 整站性故障：先控制寫入並確認新舊資料差異，再依預先測試的撤回計畫決定切回或原地修復。直接把 DNS 指回舊主機，可能讓切換後的新訂單與會員資料無法使用。

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

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

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

搬家後信件寄不到：檢查 WordPress 的實際發信設定

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

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

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

先診斷現有發信服務，再決定是否改用交易郵件服務。依選用 mailer 使用 SMTP、API 或 OAuth，配置網域驗證並查退信紀錄；不是所有服務都只填帳號密碼，也不能保證每封信進收件匣。

使用第三方寄信服務時，要依供應商文件設定 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 cache flush 主要清物件快取，不代表所有頁面快取與 CDN 都已清除。

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

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

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

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

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

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

• 控制所有寫入來源：切換前凍結新訂單、註冊及其他必要寫入，並處理 API、付款回呼、管理員與排程。一般維護頁不保證擋住這些入口；舊站在 DNS 過渡期也要維持受控狀態，避免重新開放獨立接單。
• 最後同步與核對：確認寫入已受控後，匯出資料庫並同步新增媒體等檔案，再核對訂單、庫存與會員。只同步資料庫不一定涵蓋所有變更，恢復服務前需確認唯一的正式寫入環境。

還有兩個電商搬家要特別留意的點：金流與第三方服務的 webhook。多數金流服務（綠界、Stripe、PayPal 這類）的 webhook 通知網址是指向你的網域，所以 DNS 一切換，它就會自動跟著連到新主機，但 DNS 快取、來源 IP 白名單、防火牆與憑證仍可能影響回呼。但理論歸理論，先以金流沙盒確認，再依商戶授權與退款安排評估是否需要正式小額測試、走完完整付款流程，確認 webhook 真的能收到、訂單狀態真的能更新。庫存同步、會員 session 是存資料庫還是存檔案，也要確認一下設定。

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

多數人把搬家當成「一個要熬過去的風險」，但其實換個角度想，這是一次順手把網站變快的機會。Google 在 web.dev 上明確指出，網頁速度會直接影響使用者體驗與轉換，速度差的站會在還沒傳達價值之前就流失訪客。換到一台反應更快的主機，可能改善伺服器回應，但新方案與調校仍有成本，且不保證所有 Core Web Vitals 或搜尋排名都提高。

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

• 清理沒在用的外掛：每多一個外掛就多一份載入負擔。趁這次盤點，把停用超過半年沒碰的外掛直接刪掉，別只是停用。
• 驗證快取與 CDN：依主機支援與量測結果配置頁面、物件快取及 OPcache，避免多套重複；購物車、結帳與個人化內容須有正確排除或隔離。
• 另排圖片優化：搬家穩定後再分批壓縮與調整格式，保留原檔並測試。首屏關鍵圖片通常不應延遲載入，不宜把所有圖片一律加 lazy-loading。
• 確認追蹤碼與驗證：Google Analytics、GSC 驗證、Search Console 的 sitemap 提交、canonical 設定，全部重新檢查一遍。

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

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

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

這張表有一個使用上的前提：在你動手修之前，先確認你看到的症狀是發生在「新主機」還是「舊主機」。切換後的 48 小時內，你自己瀏覽器連到的可能是舊主機（因為 DNS 還沒傳播到你這一端），這時候你去新主機改設定當然沒用。可比對 DNS、實際連線與新舊主機日誌；使用 CDN 或代理時，ping 可能只得到邊緣 IP，不能單靠它確認來源主機。這個小動作可以幫你省下大量瞎忙的時間。

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

搬家常見的翻車原因

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

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

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

搬家後要確認憑證自動續期、驗證方式與到期告警。Let’s Encrypt 的有效期政策正逐步縮短，也有不同憑證設定檔；應以實際憑證到期日與 ACME 客戶端建議安排自動化，不能固定每 90 天才執行續期。

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

搬家當天的逐項打勾表

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

1. 前一週：買新主機、確認 PHP 與資料庫版本仍有安全維護，並與網站相容、做第一次完整備份（檔案加資料庫），存到第三個地方。
2. 切換前：依既有 TTL 提前降低網站紀錄 TTL，確認 DNS 供應商允許的數值。
3. 前 24 小時：在新主機上把 WordPress 裝好、wp-content 上傳、資料庫匯入、wp-config 改好、SSL 憑證佈署完成。
4. 測試日：改 hosts file，在自己的電腦上把新站上的每一個功能（圖片、連結、表單、購物車、後台登入）全部點過一遍。
5. 切換日：控制交易、API、排程等寫入，完成最後同步與核對，再切換 A／AAAA 或合適的 CNAME；舊站維持受控過渡。
6. 切換後幾天：檢查 Google Search Console 的網頁索引報表、掃全站 404、量 Core Web Vitals 基線，並觀察舊主機流量是否逐漸歸零。
7. 確認穩定後：等既有 TTL 到期、舊主機存取日誌趨近於零，並完成交易、Email、排程與備份驗證，再依主機合約正式下架舊環境。

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

如果你這次連網址也要一起換、或站上跑的是複雜的多站網路、電商金流整合，需要有人陪你走一次，SEO 搬家改版的風險評估是另一個值得先讀的起點。依流程降低風險後，仍須觀察索引、流量與交易資料，不能保證完全不受影響。