WooCommerce 換主機後：網址、訂單、電郵與付款要驗甚麼
搬遷完成、首頁打得開，只代表某個網址回了 HTML。它不代表 DNS 已指向正確來源、TLS 憑證涵蓋新主機、舊連結已轉到新路徑，也不代表付款回呼、訂單電郵、webhook 或背景排程仍然運作。對網店來說，這些路徑任何一段斷掉，都可能變成「客人以為落單成功，你卻收不到單」。
本文是一份搬遷後營運驗收清單，不是主機商排名，也不是固定上線時間承諾。它只處理換主機或換環境後的驗證；若你仍在搬遷前隔離 staging，請先讀staging 隔離清單；更新後的功能驗收看回歸測試；舊版面或舊價看快取排查；更新後的安全訊號看安全訊號清單；備份能否還原則看還原演練。
先記錄，再選擇性處理。 不要一次過清除所有快取（purge everything）、批量改所有訂單狀態、重跑所有排程、重送所有 webhook，或急著刪除舊環境。先保存目前狀態與證據，再按受影響路徑逐項處理；這是實務建議，不是平台保證。
一、DNS 與 TLS：先確認「去哪裡」和「有沒有加密」
搬遷後第一個要問的不是「首頁漂亮嗎」，而是「這個域名現在把流量帶去哪裡」。如果主機或來源伺服器（origin）變了，應更新指向新來源的相關 DNS 記錄，通常就是 A、AAAA 或 CNAME，而不是把所有記錄一併改掉 [9]。改動前先記錄原本的 nameserver、proxy 狀態、記錄值與 TTL；改動後用多個解析器核對，並留意舊 TTL 未過期時仍可能看到舊位置。
但 公開 DNS 查詢的結果不是 origin 證明。Cloudflare 的已代理（proxied）A、AAAA 或 CNAME 記錄會由 Cloudflare 網絡處理流量，公開查詢通常返回 Cloudflare 的 anycast／邊緣節點位址，而不是新主機的 origin IP；CNAME flattening 亦可能讓查詢看似 A／AAAA [11]。要證明新 origin 真的接手，還要核對 Cloudflare 記錄的 origin 設定（例如主機名、Tunnel 或 Load Balancer）、來源伺服器設定與日誌，或用一個受控的回應標記／測試路徑確認請求由哪個環境處理 [11]。不要因為公開 DNS 見到 Cloudflare IP 就當作已搬去新主機，也不要盲目 flush 所有 DNS。
TLS 亦要在主機層核對。WordPress 官方說明，HTTPS 需要 TLS／SSL 憑證已安裝並可供 web server 使用；FORCE_SSL_ADMIN 只能在 SSL 已配置好之後使用，不能代替憑證本身 [2]。實務上要核對憑證是否涵蓋實際主機名（例如 apex 與 www）、鏈結是否完整、到期日、HTTP 是否正確轉到 HTTPS，以及反向代理或負載均衡器後方的 HTTPS 判斷。若搬遷後出現混合內容、登入被踢回 HTTP 或憑證名稱不符，先修主機與設定，不要只在前台加一個轉址遮蓋問題。
二、網址與 redirect：site URL 不是唯一要改的地方
WordPress 的「WordPress Address (URL)」與「Site Address (URL)」是兩個獨立設定，兩者都應包含 https://，且結尾不應有斜線 [1]。搬遷後要先在 Settings > General 核對這兩個值，再檢查 permalink、選單、頁面內容、產品短描述、圖片與 CTA 是否仍藏舊網址。官方文件亦提醒，RELOCATE 只會把 Site URL 自動改成你進入登入頁時使用的路徑，不會修正其餘設定；完成登入與 URL 修正後應把 RELOCATE 從 wp-config.php 移除，不要長留 [1]；所以「登入得到」不是完整驗收。
如果只是換主機而域名不變，不要因為見到舊字串就做全庫 search-replace。相反，若域名或路徑真的改了，應使用能處理 PHP 序列化資料（serialized data）的工具，先備份、先試跑（dry-run）、核對報告，再在可控範圍執行；WP-CLI 的 search-replace 文件說明它會處理 serialized data，並提供 dry-run 選項 [10]。舊資料中的 GUID（WordPress 用作內容固定識別碼）不應跟隨域名改寫；serialized 欄位亦不應用手改或普通 SQL 全庫取代。任何改寫都要先有可回復的備份與範圍紀錄；這不是叫你用一條 SQL 全庫取代，也不是把舊站資料直接覆蓋回新站。
驗收時至少抽查首頁、主要產品、分類、購物車、結帳、我的帳戶、聯絡頁與媒體檔案；記錄每個 URL 的預期結果、實際 HTTP 狀態、最終 URL 與標準網址（canonical）。舊域名、舊產品路徑與外部廣告連結要不要 301，應按實際 URL 地圖與業務需要決定；不要用一個模糊的萬用 redirect 把所有路徑導到首頁。
三、訂單與付款：狀態只是線索，不是結算證明
WooCommerce 的訂單狀態顯示訂單在結帳、付款、履行、取消或退款流程中的位置；例如 Processing 代表已收到付款並扣減庫存，On hold 可能仍在等待付款確認 [3]。搬遷後要抽樣核對搬遷前後的訂單數量、狀態、金額、稅項、運費、商品行、備註與客戶資料，並分清「付款成功」與「履行完成」是兩個不同問題。遇到延遲通知或離線付款，應同時看訂單備註與該付款商的文件 [3]。
不要在正式站批量把舊訂單改成 Completed 或 Processing 來「整理」資料；這樣做會混淆付款與履行紀錄。也不要把測試訂單當成一般訂單：WooCommerce 官方說明，測試訂單可以觸發訂單電郵、出現在分析報表，而且系統沒有可靠的外觀或特殊狀態把它與真實訂單分開；官方建議在隔離測試環境（staging）進行測試付款 [7]。不要把正式站使用中的付款 gateway（收款通道）切換到 sandbox。 若業務確需在正式環境驗證，應按付款商規則、取得明確授權，做一筆可追蹤的受控真實交易，並對帳 charge／refund、fees、庫存、訂單狀態與通知電郵；sandbox 成功不能證明正式環境結算（live），真實交易亦不能代替其他驗收項。
切換邊界：只能有一個正式寫入來源（authoritative writer）
搬遷切換（cutover）時，正式資料只能有一個可寫入的 authoritative writer（唯一權威寫入來源）。新環境開始接單後，舊副本應隔離為唯讀或不接收新訂單／排程工作，不要讓兩邊同時處理訂單、付款回呼、延遲 webhook 或背景工作；同時保留舊站的訂單、日誌、佇列與付款證據，不要急著刪除。
切換後要對帳自上次同步以來的新訂單、庫存變動、處理中的付款回呼（in-flight callbacks）與延遲送達的 webhook，並確認每一筆只被處理一次。若已在新站產生訂單，不要盲目回滾資料庫或 DNS；回滾決定要先完成訂單／付款／庫存／通知對帳，避免重複收費、重複發信或重複執行背景工作。
四、付款回呼與 webhook：兩條不同的對外／對內路徑
這裡最容易混淆：WooCommerce Webhooks 是商店主動送出的 event notification（事件通知），不是付款商傳入的付款回呼或 IPN。 WooCommerce 文件說明 webhook 是把事件通知送到你指定的 URL，可觸發另一個網站或第三方服務的行為；每個 webhook 有狀態、topic、交付網址（delivery URL）與簽署密鑰（secret），交付紀錄可在 WooCommerce > Status > Logs 的 webhooks-delivery 來源查看 [4]。搬遷後要核對每個 webhook 是 Active、Paused 還是 Disabled，delivery URL 是否仍指向正確環境，secret 是否已按環境更新，以及接收端回應是否成功。
付款商的 incoming callback 則是另一條路徑：要按該付款商的文件核對接收網址（endpoint）、簽名、IP allowlist、重送政策與訂單備註，不要把 WooCommerce webhook 的設定當成付款回呼設定。若見到大量失敗，先保存請求與回應證據，再選擇性重送受影響事件；不要一次過重送所有歷史 webhook，亦不要把正式付款商 secret 貼進工單、聊天或版本控制。
五、電郵：Sent 只代表交給了郵件系統
WooCommerce 預設使用 WordPress 的 wp_mail() 發送郵件，所以主機的郵件設定與 SMTP 供應商都是發信路徑的一部分 [5]。搬遷後要先確認 WooCommerce > Settings > Emails 的相關通知仍然啟用，再查看 transactional-emails 日誌：Sent 只表示 WooCommerce 已把郵件交給郵件系統，不代表已送達客戶收件箱；Failed 則通常會記錄 WordPress 或郵件服務回報的原因 [5]。WordPress 密碼重設與管理員郵件未必出現在同一個 WooCommerce 日誌，應另外查看 SMTP 供應商紀錄 [5]。
測試時使用你能控制、不能轉寄給真實客戶的測試信箱；不要在正式站向真實客戶重送大量訂單電郵。寄件網域的 SPF、DKIM、DMARC 與 SMTP 認證應按實際郵件供應商文件核對；這些是營運檢查，不是本文對任何供應商的保證。若 WooCommerce 顯示 Sent 但客戶收不到，應同時查垃圾郵件分類、退信、SMTP 紀錄與寄件網域設定，而不是只重按一次「重送」。
六、排程與背景工作：先看工作類型，再決定是否重跑
WooCommerce 的 scheduled actions 管理訂單通知、付款處理等背景工作，可在 WooCommerce > Status > Scheduled Actions 查看；WP-Cron 依賴網站流量觸發，除非主機設定了 server-side cron；Action Scheduler 則是用來處理大量 WooCommerce 工作、webhook 與電郵的背景工作佇列（job queue） [6]。搬遷後要記錄 pending、failed、in-progress 與下一次執行時間，並分清哪些工作涉及付款、通知、庫存或一般維護。
不要因為見到積壓就取消全部工作或全部重跑。先保存佇列與失敗原因，修正根本問題（例如 SMTP、付款商連線、DNS 或 PHP 錯誤），再按工作類型選擇性重試；全部清除可能同時抹掉調查線索與仍待處理的業務事件。若主機停用了 WP-Cron，亦要確認 server-side cron 真的在跑 [6]。
七、快取：清 URL 不等於已更新，成功回應也不等於已清掉
搬遷後見到舊價、舊庫存或舊版面，先分清瀏覽器快取、網站頁面快取、物件快取（object cache）與 CDN 四層。Cloudflare 文件建議先按單一 URL 清除（purge），而不是一開始就 purge everything；成功 purge 只代表 Cloudflare 收到請求，不代表目標內容曾被快取或已被移除 [8]。清除後要重新請求該實際 URL，對照畫面內容／版本、來源伺服器（origin）的版本與 Age、CF-Cache-Status、Cache-Control 等回應標頭 [8][12]。
不要只憑一次 HIT 判定 purge 失敗。 第一個未命中請求可能是 MISS，之後由另一個請求或另一個地區重新填入而變成 HIT；HIT 只表示該次請求由 Cloudflare 快取回應，不單獨證明你剛才的 purge 沒有生效，也不證明內容仍是舊版 [12]。Cloudflare 文件建議 purge 後確認 CF-Cache-Status 不再是 HIT，但這不是放諸四海皆準的唯一判準；反過來，見到 MISS 也不等於 origin 正確 [8][12]。應核對實際內容與來源版本，必要時按 URL 重試並記錄請求時間、地區、標頭與畫面。
因此，先核對 origin 的資料與版面，再按受影響 URL 清 CDN；網站頁面快取與 object cache 亦要分別處理。不要在未記錄前把所有快取一次清空，也不要把「purge 回 200」當成驗收完成。每次清快取都應留下 URL、時間、地區、回應標頭與實際畫面證據。
搬遷後六道營運閘門
- 01 · DNS／TLSproxied 記錄的 origin 設定、日誌或受控標記
公開 DNS 見到 Cloudflare 邊緣 IP 不等於 origin；憑證仍要涵蓋主機名。
- 02 · 網址site URL、permalink、舊連結與媒體
兩個 URL 設定都要核對；域名未變時不要默認全庫 search-replace。
- 03 · 訂單／付款數量、狀態、備註、結算與單一 writer
狀態不是結算證明；有新單後勿未對帳就回滾 DB／DNS；測試訂單可能有真實副作用。
- 04 · 回呼／webhook付款商 incoming callback ≠ Woo outbound webhook
分別核對 endpoint、secret、狀態與 delivery log；不要重送全部。
- 05 · 電郵／排程Sent 不等於送達；積壓不等於全部重跑
看 transactional-emails、SMTP 紀錄與 Action Scheduler 工作類型。
- 06 · 快取／驗收先修 origin，再按 URL purge
對照內容、origin 與標頭；單次 HIT 可能由新請求重新填入。關鍵未驗記 blocked，不可當 pass。
記住：公開 DNS 不等於 origin；首頁開得到不是完成；單次 HIT 不代表 purge 失敗；sandbox 付款不是正式結算。判定：pass＝證據完整；pending＝待補；blocked＝關鍵未驗／證據不足，不可當 pass。
下載完整 SVG 流程圖八、用一張表決定 pass、pending 或 blocked
以下每一列都要有預期結果、實際結果、證據位置、時間與負責人。判定只有三種：pass 只限證據完整且符合預期；pending 是未完成但有明確下一步；blocked 是關鍵路徑未測、fail 或證據不足。blocked／pending 不可當作 pass，亦不應把搬遷標示為「已完成」：
| 路徑 | 要驗 | 可接納證據 | 判定 |
|---|---|---|---|
| DNS／TLS | proxied 記錄的 origin 設定、origin 日誌或受控標記、憑證涵蓋主機名、HTTP→HTTPS | Cloudflare 記錄（遮蔽敏感值）、origin 日誌／受控回應、憑證鏈與到期日、回應標頭 [2][9][11] | 只見公開 DNS／edge IP：blocked；origin 證據齊：pass |
| 網址／redirect | site URL、permalink、舊連結、canonical、媒體 | URL 清單、HTTP 狀態、最終 URL、抽查截圖 [1] | 關鍵 URL 未驗：blocked；完整抽查：pass |
| 訂單／付款 | 搬遷前後數量、狀態、金額、庫存、備註、付款商結算；只容一個正式 writer | 訂單匯出、庫存紀錄、付款商 charge／refund／fee 報表、對帳紀錄 [3][7] | 未對帳：blocked；完整對帳：pass |
| 回呼／webhook | 付款商 endpoint、Woo webhook 狀態與日誌、在途／延遲事件 | 請求／回應紀錄、付款商事件紀錄、webhooks-delivery 日誌 [4] | 未驗或重複處理：blocked；逐筆對帳：pass |
| 電郵 | 通知啟用、Sent／Failed、SMTP、寄件網域、可控信箱收件 | transactional-emails、SMTP 紀錄、測試信箱收件、退信 [5] | 只見 Sent：pending；收件與 SMTP 證據齊：pass |
| 排程 | pending／failed／in-progress、cron 觸發、是否重複執行 | Action Scheduler 匯出、server cron 紀錄、背景工作對帳 [6] | 未驗：blocked；關鍵工作完成且無重複：pass |
| 快取 | origin 版本、指定 URL purge、實際內容／版本、回應標頭 | CF-Cache-Status、Age、Cache-Control、頁面快取與物件快取紀錄、畫面 [8][12] | 只見 HIT 或 200：pending；內容與 origin 吻合：pass |
若關鍵項 fail 或未測，應由店主或獲授權人員決定是否暫停新結帳、保持舊環境唯讀、分批修正或回滾；不要自行刪除舊站、舊 DNS 記錄、日誌或佇列。若已在新站接單，回滾前必須先完成訂單、付款、庫存與通知對帳，避免重複收費、重複發信或重複執行背景工作。搬遷完成不是一個口號，而是一組可重現的 pass 證據；blocked／pending 不是 pass。
常見問題
首頁開得到，是否代表搬遷完成？
不是。首頁只證明某個 URL 回應；DNS、TLS、訂單、付款回呼、webhook、電郵、排程與快取仍要逐項驗。
域名沒有變，是否仍要做全庫 search-replace？
不應默認要做。只有當 URL 真的改變時才需要處理資料庫內舊網址；並應使用能處理 serialized data 的工具，先備份與試跑（dry-run），並保留 GUID 不改 [10]。
WooCommerce Webhook 是否就是付款商回呼？
不是。WooCommerce webhook 是商店送出的 event notification；付款商 incoming callback／IPN 是另一條介面，要分別核對 [4]。
可否在正式站建立測試訂單？
測試訂單可能觸發電郵與分析，而且外觀與真實訂單無明顯分別；官方建議在隔離測試環境（staging）測試。不要把正式站使用中的付款 gateway 切到 sandbox。若業務確需在正式環境驗證，須按付款商規則取得授權，做一筆可追蹤的受控真實交易，並對帳 charge／refund、fees、庫存與通知；sandbox 成功不代表正式結算 [7]。
Purge 回 200 是否代表快取已清？
不代表。200 只表示 Cloudflare 收到請求；文件建議 purge 後確認 CF-Cache-Status 不再是 HIT，但單次 HIT 可能由其他請求或地區重新填入，不能單獨判 purge 失敗。要對照實際內容／版本、origin 與回應標頭 [8][12]。
排程工作積壓，是否可以全部重跑？
不應。先記錄工作類型與失敗原因，修正根本問題後再選擇性重試；全部重跑或全部取消都可能造成重複通知、重複付款或證據流失 [6]。
資料來源
搬完，先驗收再宣佈完成
Managed-WP.™ PRO 提供 WordPress 專業代管服務。若你正整理搬遷後的 DNS、TLS、訂單、付款回呼、電郵、排程與快取證據，先把實際環境、版本與外部端點清單整理好，再按團隊權限確認支援範圍。
聯絡 Managed-WP.™ PRO若你需要按實際主機、DNS、付款商與團隊權限整理搬遷後驗收紀錄，可聯絡 Managed-WP.™ PRO。
編輯說明：本文由 Managed-WP.™ PRO 編輯團隊根據上述官方文件整理。標示為實務建議的內容不是 WordPress、WooCommerce、Cloudflare 或主機商的保證；版本、介面、付款流程與功能可能變更，請以實際環境及最新官方文件為準。