WordPress 搬家外掛怎麼選：五種搬移角色與斷點核對

想像一個場景：主機商寄來續約通知，價格一次漲足；或者流量終於超過方案上限，後台開始出現資源警示；也可能是你接手一個客戶的舊站，合約載明兩週內要移進指定環境。三種開頭，同一個結局：你打開搜尋框，輸入「WordPress 搬家外掛」。（示意）

搜尋結果很熱鬧，結論卻互相打架。這一篇把某款工具捧成神器，下一篇把它排在第三；每份清單都有自己的冠軍，也都附上漂亮的星評與下載數字。照單安裝、失敗、換下一份清單重來的人，卡的幾乎是同一個地方：匯入跑一半停住、圖片整批消失、換完網域搜尋表現往下掉。

動手之前，三個誤解先拆掉。星評高不等於搬得動你的站，評價反映的是順利案例的數量，不是它對你的主機限制與資料規模的支援程度。搬家也不等於複製檔案，網站的本體大半在資料庫裡，而資料庫裡寫死的網址字串才是真正的難關。首頁正常更不等於搬完，驗收是對帳，不是看畫面。

你缺的不是第八份清單，而是一條能走的判斷流程。WordPress 在 W3Techs 的網站技術長期調查 裡，長年穩坐內容管理系統市佔第一；生態大到這個程度，代表工具多到選不完，也代表你遲早要面對一次搬家。與其背別人的冠軍名單，不如學會自己收斂。

快速重點：搬家外掛沒有公認冠軍。先回答四個問題：網址換不換、資料多大、誰來執行、能停機多久，答案會把數十款工具縮到兩三款；剩下的風險，交給預演、寫入控制與切換後的對帳。

五種搬家情境，風險各不相同

「搬家」兩個字掩蓋了一個事實：它至少是五種形狀不同的任務。任務認錯，工具再熱門也會中途出事，因為每種情境害怕的東西根本不一樣。先對號入座，準備要抓多深、風險熱點落在哪、工具的挑選範圍才會同時清楚。

↔ 左右捲動檢視完整表格

情境形狀	準備深度	風險熱點	網址換不換
只換主機、網域照舊	半天可收工	檔案體積撞上主機資源限制	不換
主機與網域一起換	替換要先預演	序列化網址替換出錯、搜尋訊號中斷	會換
本機開發站上線	環境要先對齊	路徑、權限與連線設定落差	會換
WordPress.com 轉自架站	時程要抓寬	匯出範圍受方案限制、設定需重建	通常會換
電商站搬移	切換劇本必備	交易資料持續寫入、金流設定遺漏	視情況

表裡真正該盯的是「網址換不換」那一欄。網址不動，搬家的本質是複製加上重新開機，多數工具都做得來；網址一換，資料庫裡的序列化字串替換立刻登場，難度直接跳一級。同一款外掛，有人用起來行雲流水，有人用完整站白屏，差別多半落在這一欄，而不是工具本身的優劣。

準備深度那一欄，用來估算該投入的心力，不是用來嚇退你。落在「半天可收工」的情境，一份完整備份加上一次乾淨的匯入就能結案；需要預演或劇本的情境，測試環境、替換演練與轉址清單都該進入計畫。把這欄當成工時估算的依據，比當成放棄的理由有用。

只換主機、網域不動的搬法，成敗取決於資料走哪條路、新環境給多少資源，完整步驟照 換主機不換網域的逐步指南 走即可，這裡不重複。要提醒的是別把「難度低」讀成「不用準備」：上傳上限、執行時間、磁碟空間這三面牆，在最單純的情境裡照樣存在，只是你還沒撞到。

從本機搬到正式環境，等於一次自帶網址變更的搬家。本機的路徑、權限、連線設定與正式主機都有落差，媒體路徑對不上是經典斷點；資料庫裡寫死的本機路徑也要替換，漏了它，圖片會集體指向一個外界連不到的位址。還沒把環境架起來的人，先看 MAMP 本機環境的架設教學；環境就緒要上線，再接 本機搬上線上主機的完整流程，兩篇串起來就是這條路的骨架。

從 WordPress.com 移到自架站，又是另一種形狀。能匯出多少內容取決於方案權限，外掛與佈景主題多半要在新站重裝重設，部分搬移外掛在 .com 端根本裝不進去。這條路的取捨先讀 兩種 WordPress 的完整比較 再排時程，才不會做到一半發現前提不成立。

電商搬移的難度之所以最高，不在資料量，而在資料還活著：訂單、會員、庫存在複製期間持續寫入，任何「搬完再說」的安排，都可能漏掉切換前幾小時的交易。這種站需要另一套切換劇本，後面會用一整節專門處理。

主機架構也會改變搬法的成本。共享主機把資源上限壓得低，撞牆機會大；VPS 與雲端能調的參數多，手動路徑也走得開。這層差異屬於選型問題，完整的討論留在 主機類型比較指南；這裡的原則只有一句，先知道自己的牆有多高，再挑翻牆的工具。

網址會不會變？這題決定難度等級

換網域的搬家風險硬是高一級，原因只有一個：舊網址不只出現在文章內文，它還被寫進網站選項、小工具設定、選單結構、佈景參數、外掛的後設資料，而且大量藏在序列化字串裡。PHP 的序列化格式會在每段字串前記錄長度，網址換了，那個數字也得跟著換。

這是不能打開資料庫工具、用普通的搜尋取代直接動手的原因。普通取代把文字換掉，長度標記卻留在原地，兩者對不上，WordPress 讀到那段資料就判定損毀：輕則某個設定失效、側邊欄消失，重則前台白屏、圖片整批不見。一個看起來純文字的網址，實際上戴著一把看不見的尺。

網址藏在哪裡，決定替換要掃多廣。文章內文與自訂欄位是最明顯的位置；佈景設定、外掛參數、小工具與選單，多半是序列化後整段塞進單一欄位；快取與統計類的資料表裡，也可能留有舊網域的殘影。乾淨的做法是先盤點位置與數量，再決定替換範圍，而不是把整個資料庫當成同一鍋。

所以挑工具時要檢查的第一項規格，不是介面順不順，而是它怎麼處理序列化資料的網址替換。做法乾淨的工具，通常會在文件裡明講處理方式與排除範圍；隻字不提的，你要當它靠簡單字串取代，把風險算進自己的帳，再決定要不要用。

難度等級落在實務上，是三個具體差異。工具要挑得更嚴，序列化替換成為必檢規格；驗收要做得更深，內文、選單、小圖示的連結都要抽查；收尾要多一份轉址清單，舊網址有多少要接、接去哪，切換前就要定案。同樣叫搬家，這三件事做與不做，結果差得很遠。

換主機加上換網域的完整流程，站內已有 換網域搬家的完整指南，步驟照那篇走。這裡先建立一個認知就夠：網址替換是整個搬家最容易出事的一步；至於怎麼把它做得安全，談執行紀律的段落會展開。

先有難度認知，工具的規格表才讀得出輕重；沒有它，每份比較文看起來都一樣有道理，你也只能跟著星評走。

四個診斷問題，把工具清單縮到兩三款

收斂清單的方法很機械：四個問題，照順序回答。每個答案都會淘汰一整類工具，四題答完，市面上數十款通常只剩兩三個候選。不同條件的人會得到不同答案，這正是搬家外掛沒有公認冠軍的根本原因：不是品牌之爭，是任務形狀之爭。

1. 網址會不會變？不變，以替換見長的重型工具先用不上；要變，所有只複製檔案、不碰序列化替換的工具直接出局。
2. 資料多大、還在寫入嗎？媒體庫到了數 GB 級，上傳與執行時間限制就會變成主角；持續有訂單、會員或預約寫入的站，還要再多一層切換劇本。
3. 誰來執行？能開 FTP、能敲指令的人，可走的路徑多一倍；完全不想碰技術細節的人，該優先考慮中繼傳輸或主機代搬，而不是硬著頭皮自學。
4. 能停機多久？能停十分鐘和一秒都不能停，走的是兩種完全不同的計畫，後者的成本主要花在維持資料一致。

四個問題之前，還有第零步：完整備份，並確認那份備份真的能還原。備份與搬家常被當成同一件事，其實一個在留存可回去的快照，一個在讓那份快照於新環境重生；兩種工具技術相鄰，目標各走各的。備份這條線的完整做法，看 備份與還原的總覽指南；習慣圖形介面的人，可以照 WPvivid 的備份還原教學 走一遍；本來就用 UpdraftPlus 做例行備份 的人，手上的備份檔就是現成的安全網。把「備份存在」與「備份可還原」分成兩件事驗證，是這一步最常被跳過的部分。

驗證還原不必複雜：找個空資料夾或測試網址，把備份實際還原一次，前台後台都進得去、文章讀得到、圖片顯示得出來，這份備份才算數。多數人停在「備份檔存在雲端」，出事那天才發現檔案是空的或格式不相容。搬家的安全網，是還原得出來的那一份，不是看得到的那一份。

停機窗口那一題要多想一下，因為它常在計畫末期才爆炸。內容站挑半夜流量低谷停機，切換只是幾分鐘的網域指向加上快取清理；不能停的站，必須安排寫入控制與收尾同步，驗收也得在壓力下完成。兩種計畫的準備時間差好幾倍，事前沒想清楚，事中就來不及。

執行中還有一個實用的判斷訊號：同一個階段重試兩三次都卡住，表示這條路對你的站走不通。把它讀成換路徑的訊號，而不是加大決心再試一次的提示。多數搬家事故來自後者，在同一面牆前反覆衝撞，把可以用來換路的時間燒光了。

五種搬移角色，對應不同的診斷結果

不排名，改看角色。把工具依「資料怎麼走」分成五種搬移角色，角色對應前一步的診斷結果；同一個角色裡換工具，成敗通常不變，因為資料走同一條路，斷的也是同一面牆。下面這張表本身就是挑選標準：先讀診斷條件，對上角色，採用前核對欄寫的是每條路天生的斷點，欄位看完，該問廠商的問題也跟著成形。

↔ 左右捲動檢視完整表格

診斷條件	搬移角色	代表工具	採用前核對
網域不變、不想碰細節、資料量大	中繼傳輸	Migrate Guru	連線條件、資料行經第三方服務、每月搬移額度
有技術底、需要可重複佈署	打包安裝	Duplicator	新主機的執行資源、安裝器相容性
新手、小站、網域不變	匯出匯入	All-in-One WP Migration	匯入端的上傳限制、工具版本限制
開發者、多環境同步	資料庫替換	WP Migrate	授權成本、命令列與拉送流程
網域不變、習慣傳統流程	備份還原	BackWPup、XCloner	網址替換需自行補上、還原步驟偏手動

中繼傳輸的角色，把打包、上傳、匯入串成一條由官方伺服器居中協調的流程：舊站邊打包邊送，新站邊收邊寫，兩邊都不必騰出空間放置巨大的封存檔，這對磁碟吃緊的站特別友善。這條路的斷點不在檔案大小，而在兩端的連線與流程條件，條件對不上，再小的站也會卡在握手階段。Migrate Guru 是這個角色的代表，官方在 外掛目錄的說明頁 列出支援環境與使用條件，採用前把整份讀完，比讀十篇心得有用。

官方流程需要 email 接收進度通知，並以 migration key 或必要的 FTP／cPanel 資訊連接目標，不宜概括為必須先另註冊一個網站帳號。資料會經過第三方服務，採用前應核對授權與資料處理需求；另有每位使用者每月可搬移網站數的額度。

打包安裝的角色走實體路線：工具產生一個安裝器與一個封存檔，你把兩個檔案放進新主機，用瀏覽器執行安裝器，讓它解壓、接上資料庫、完成網址替換。Duplicator 是代表。這條路對開發流程的意義在於可重複：同一份套件能反覆佈署到測試與正式環境，也是把站放上空白主機的標準解法。封存檔有多大，上傳就得扛多大，這條路的天花板就架在主機的上傳與執行參數上。代價是安裝器對新主機的資源有要求，記憶體與執行時間給得緊的共享主機，常在解壓階段就倒下。

匯出匯入的角色最直觀：舊站打包成一個檔案，新站裝同一款外掛把它吃回去，過程幾乎不用碰伺服器設定，這也是它常被當成新手起點的原因。匯出端通常可以排除部分內容來縮小檔案，媒體、外掛、佈景主題都能不打包，這正是「分開搬媒體」策略的源頭。All-in-One WP Migration 是代表，它的主要關卡不在匯出端而在匯入端：那個檔案會先撞上主機的上傳上限，再撞上工具自身版本的匯入限制。這兩面牆怎麼分辨、怎麼對付，下一節專門拆，這裡先記住角色定位就夠。

資料庫替換的角色以 WP Migrate 為代表，強項是序列化安全的搜尋替換，加上開發環境與正式環境之間的拉送同步；定位明確偏開發者，付費為主，一年搬不到一次站的站長不必勉強。備份還原的角色由 BackWPup 與 XCloner 這類老牌工具承擔：做出完整備份，在新站還原成可運行的網站，流程傳統、心裡踏實；弱點是網址替換不在主流程裡，換網域的情境要自行補上這道工。

五種角色的界線，也回答了一個常見的掙扎：需不需要買付費工具。答案取決於診斷落在哪一格，不是預算多寡。免費工具放在正確的格子裡夠用，付費工具放錯格子照樣卡住；把錢花在對的角色上，比花在最貴的那一款上有效。

還有一個不上表的角色：主機端代搬。不少主機對新申請的客戶提供搬站協助，品質與範圍差異很大，申請前先問四件事：資格條件、實際搬移範圍、停機怎麼安排、失敗時有沒有退回機制，並把答案留在信件往來裡當憑據。代搬通常搬的是網站本體，網域層的轉址與收尾仍在你手上。找主機的起點，可以從 官方的架站資源頁 出發，主機挑選的完整討論見 WordPress 主機的選擇指南。代搬再省事，驗收仍然是你的責任，這件事沒辦法一起外包。

匯入卡住時，限制出在哪一層？

匯入或打包卡住時，先別急著換外掛。限制有四層：PHP 的上傳上限、磁碟空間、執行資源，以及工具自身版本的匯入限制。前三層在你的主機上，第四層在外掛裡；分不清限制落在哪一層，換十款工具也會卡在同一個地方，因為卡住你的根本不是工具。

按症狀發生的階段定位，比盯著紅色錯誤訊息猜更可靠。檔案還沒開始跑就被告知過大，先查上傳上限那組參數，例如 upload_max_filesize 與 post_max_size；進度推到一半停住不動，輪到執行時間與記憶體限制說話；解壓階段炸開，指向磁碟空間或記憶體不足；到了寫入資料庫才斷，才比較可能是工具與資料庫端的問題。階段走完一輪，答案通常只剩一個，藥也就知道該下在哪裡。

匯入受限時，先辨識是 PHP 上傳、磁碟、執行資源，還是外掛目前版本的匯入限制。官方付費產品名為 Unlimited Extension，File 則是匯出選項。調整 php.ini 只處理主機端限制；若改採分開搬媒體，需要同步排除封存中的媒體並核對完整性，單純先傳 uploads 不會讓原封存檔自動變小。

付費擴充的決策照同一套分層走：瓶頸量出來在主機端，卻去買工具擴充，是把錢花在錯的層；瓶頸在工具端，先調主機參數也只是繞圈子。先量再買，順序對了，這筆開銷通常一次就到位，也不會把問題誤判成工具不好用。

主機端的參數不是每個方案都讓你改。共享主機常見三種情況：後台可以直接調、得寫進特定設定檔、或根本鎖死只能請主機商處理。先確認自己站在哪一種，再決定是調整、繞過，或把這個限制列入換主機的理由；對著鎖死的參數反覆重試，只是把力氣花在不能動的那層。

若決定把媒體手動分開搬，FTP 是基本工具，連線與傳輸的基礎操作看 FTP 檔案傳輸教學；媒體搬完記得核對檔案數量與資料夾結構，再回頭走剩下的匯入流程。拆開的重點在約定先後：媒體先就位，再執行資料庫與設定的搬移，兩邊的時間差越小，中間產生的不一致越少。採用任何工具前，也養成查更新紀錄與相容版本的習慣，官方外掛目錄 的頁面都有標示；太久沒更新的工具，不值得在搬家這種高風險任務上賭。

替換網址之前，先跑一次預演

網址替換的第一條紀律：破圖不等於自動是資料庫的問題。先打開瀏覽器的開發者工具，看顯示不出來的圖片實際請求了哪個網址、伺服器回了什麼碼。指向舊網域，才是資料庫殘留；回應找不到、路徑卻在站內，往漏傳檔案或大小寫不一致查；資源被瀏覽器擋下，混合內容的嫌疑最大。方向確認錯了，後面每一步都是白工。

確認要動資料庫之後，替換的執行照固定順序走，順序本身比選哪個工具重要。

破圖可能來自舊網址、漏傳檔案、權限、大小寫或 HTTP／HTTPS 混合內容。先查看實際請求與伺服器回應；確認是資料庫殘留網址後，再備份並用支援序列化的 Better Search Replace 或 WP-CLI search-replace。先 dry run 核對表與欄位範圍，避免把所有字串無差別替換。

堅持先預覽再執行，是因為無差別替換有兩種誤傷。一種是範圍過大：不該動的資料表也被換了一遍，快取與日誌類的內容被改寫後，事後對帳時你分不清哪些差異來自搬家、哪些來自替換。另一種更隱蔽：一般文章裡恰好提到舊網域的文字，也被一併改掉，句子的原意就變了。支援序列化的工具躲得開結構損毀，但哪些表納入、哪些排除，該由你看過再決定，不是交給預設值。

預覽報告出來後，看的重點是兩個數字：預計替換的筆數，以及它落在哪些資料表。筆數與你盤點的舊網域出現次數在同一個量級，範圍就合理；高出好幾倍，通常代表把統計或日誌類的表也算進去了，先排除再跑。多花這幾分鐘，比事後從一堆改壞的紀錄裡撈回原狀便宜。

替換完成後還有一串收尾動作：到後台的設定裡，把固定網址結構重存一遍，觸發網址重寫規則的重建；把新舊兩邊的快取清乾淨，避免看到假結果；再以舊網域當關鍵字，對資料庫跑一次唯讀查詢，確認殘留筆數歸零，或只剩能解釋的例外。這些動作不花什麼時間，卻能把「應該換乾淨了」變成「量得出來換乾淨了」。

配套也要補上，四個環節各管一段：舊網址用 301 永久轉址 接住，把累積的訊號交給新網址；協定殘留的判斷方式看 HTTP 與 HTTPS 的差異；新環境的加密層照 SSL 憑證的設定指南 逐項確認；網址結構若一併調整過，取捨先讀 網址結構的 SEO 考量。替換做得再乾淨，配套缺一段，就留一個洞給搜尋引擎與訪客。

還在收訂單的站，需要另一套切換劇本

內容站搬家，下場通常是文章暫時看不到；電商搬家，下場可以是訂單留在舊站、客人以為下單成功、出貨憑單卻不存在。WooCommerce 在 W3Techs 的電子商務系統追蹤 裡長期市佔居前，這類站的搬移需求又急又常見，出事時的商業代價也最高。

想像一個場景：一間小型商店挑週間下午複製網站，兩個小時的複製期間進了兩張訂單，一張刷卡成功，一張停在未結帳。切換完成後，新站看不到這兩張單，它們是在初次副本建立之後才寫進舊站資料庫的。（示意）事後得靠人工比對金流紀錄與信件把單找回來，還要向客人解釋延遲，成本遠高於事前的準備。

解法是把「初次複製」與「正式切換」拆成兩個動作，中間插入寫入控制，讓舊站在這段期間盡量只讀不寫。

搬家期間持續寫入的訂單可能留在舊站。先規劃結帳暫停或增量同步方式，並在最終一輪同步後核對訂單、會員、庫存及金流通知；僅隱藏購買按鈕不一定會阻止 API、訂閱扣款或背景工作寫入。切換時間與恢復條件應由測試結果決定。

寫入來源要一項一項找出來，因為它們不會因為你把購買按鈕藏起來就停止。至少把這五類過一遍：

• 結帳流程：以型錄模式或維護頁暫停，並公告預計恢復時間。
• 表單與留言：暫時關閉，或改留聯絡信箱。
• API 整合：物流、電子發票、會員系統的對接先停用或降頻。
• 訂閱扣款：與金流服務商確認扣款時段，避開同步窗口。
• 背景排程：清理、報表、自動信件的排程先停用。

結帳暫停與增量同步是兩種代價結構不同的選擇。暫停的代價是那段時間不收單，簡單、可控，適合流量低谷明顯的站；增量同步的代價是工程與核對時間，訂單不中斷，但每多同步一輪，就多一次對帳。沒有標準答案，只有你的流量形狀與人力配置能決定。

收尾同步完成後，核對四組數字：訂單筆數、會員資料、庫存數量、金流通知，對得上才切換；對不上，那筆差異就是切換前必須回答的問題。切換時點由測試結果決定，不是由日曆決定，測試沒過就延後，比照著專案時程表按下去安全得多。商店的金物流與發票設定細節，參考 WooCommerce 開店設定指南。

清單外的資料：自訂資料表與環境依賴

工具說「搬家完成」的時候，講的是它職責範圍內的資料都到了。範圍外的東西有兩類：一類是可能被漏在清單外的資料，一類是本來就不會跟著搬的環境設定；兩類都靠事前盤點與事後對帳接住，不靠運氣。

這一段的驗法比說法重要：與其問外掛會不會漏搬自訂資料表，不如先講清楚「怎麼證明沒漏」。把資料庫整份倒出來的匯出，自訂表通常一併在內，一口咬定工具必然漏掉並不成立；要防的是四個變數：多站台設定、藏在序列化字串裡的網址替換、搬移期間仍進來的新資料，以及工具對特定表的排除預設。完整的備份先落一份，然後進測試環境核對每張表的資料筆數、外部鍵與核心流程，數字能對齊，切換才有依據。

盤點本身不複雜，卻沒有捷徑：打開資料庫，列出所有非 WordPress 核心的資料表，來源多半可以從前綴或外掛名稱看出來；對照每個關鍵外掛的文件，確認它的資料放在哪幾張表、搬移時由誰負責。文件沒寫的，就當成「不保證會搬」，進測試環境驗證。這份清單同時就是驗收單：每張表都有預期筆數，對得上才算過關。

驗收因此要做成對帳，不是瀏覽。文章筆數對得上、訂單與會員筆數對得上、資料表之間的關聯欄位對得上、關鍵功能實際操作過一遍，四項全過才算搬完。只確認首頁渲染正常，是最低門檻；在測試環境多花的半天，就是正式上線後少熬夜的本錢。

環境依賴層是另一類：PHP 版本與參數、伺服器的網址重寫規則、排程工作、CDN 與 DNS 設定、憑證的自動更新排程，這些住在外掛搬不動的地方，不會自己長到新環境上，只能逐一重建，或確認新端已有等效設定。搬家後突然失效的功能，追到底常是這一層少了東西，而不是資料搬壞了。

環境層的重建順序，最好排在切換之前完成：PHP 版本與參數先對齊，重寫規則與排程在新站建立後先跑一輪，CDN 與 DNS 的指向留到切換那一刻才改。順序顛倒的常見代價，是網域已經指到新站、環境層還沒就位，訪客與爬蟲看到的是半成品。切換時間點，該由這張重建清單的完成度決定。

多站台與本機環境的搬移又多一層變數：資料表共用、路徑寫死、工具支援的邊界，都與單站不同，部分工具對這兩種情境有官方註記的限制。把文件翻到那一頁再動手，比事後修復省下的時間多好幾倍。

切換上線後，怎麼守住搜尋流量？

切換上線不是終點，是監控的起點。官方對變更網址的搬移指引，核心是三件事：網址對應、永久轉址、新舊站的持續觀察；整份流程的 SEO 全景在 網站搬移的 SEO 指南，這裡聚焦監控怎麼落成每天做得到的事。

切換後的監控是一個迴圈：先看錯誤率、重要頁面與訂單有沒有異常，再用 Search Console 和 Analytics 對照原有的流量基準；發現下降，依序檢查轉址、noindex、canonical、伺服器回應與量測設定，並把季節因素與流量來源納入判斷。需要排查方向時，可對照 排名恢復 與 流量恢復 的流程；監控期的長短依網站規模與處理進度調整，搜尋引擎重新處理的時間取決於網站本身，沒有固定完成保證。

基準是搬移前就該留下的：重要頁面的點擊與曝光、訂單量、錯誤率，切換前各匯出一份或截圖存檔。沒有基準，切換後的每個數字都只能憑感覺判斷好壞；有基準，異常從什麼時候開始、落在哪些頁面，答案自己會浮出來。基準要涵蓋搜尋與營運兩邊，只看流量會漏掉訂單面的異常，只看訂單會誤判搜尋面的波動。

警戒線比天數有用。與其記住「幾週沒恢復就要處理」，不如定義「連續幾天偏離基準趨勢就回查」，把它寫進行事曆，觸發了就照清單排查。監控是迴圈，不是日曆上的結束日期；沒有異常的日子也把數字記下來，基準會越對越準。

手機版要實際走一遍。搜尋索引以行動版本為準，這是 官方在 2023 年 10 月的公告 定調的常態；搬家後版面、字體或按鈕在手機上跑掉，等於把搜尋引擎真正看到的那個版本弄壞了。用自己手機走完首頁、讀文章、進結帳的路徑，比在桌機點一圈更有代表性。

轉址本身的品質也回頭查一次：舊網址指向新網址就好，不要串成兩三跳的鏈；確認用的是永久轉址而不是臨時轉址，兩者對搜尋引擎的意義不同。這類檢查在搬移當天容易在壓力下被略過，把它放進監控迴圈，讓它在切換後幾天內被補查一次。

搬完之後，讓新環境比舊的更健康

搬完的站，最好的用法是當成一次體檢報告。新環境的反應速度重測一次，建立新的基準線；速度明顯變差時，方向多半在新主機的效能與快取設定，處理思路看 網站速度優化指南，而不是急著再搬一次。

資安層也重檢一次：防火牆規則、檔案權限、登入保護在搬家後常回到預設狀態，補齊方式參考 WordPress 資安外掛攻略。趁外掛清單攤開的機會，把沒在用的停用並移除；新站比舊站輕，下一次搬家的成本就低一截。

回頭看這條決策線：先認情境，再答四個診斷問題，對角色挑工具，用預演與寫入控制壓住執行風險，切換後以對帳收尾。把這次的設定與數字留下來，下一次搬家，不管是再換主機或擴充成多站，起點都會比這次高。