蓋房子的人都知道，工序有先後之分：先把地基打好、讓地基完全定型，才輪到上面的裝潢動工。順序要是顛倒過來，壁紙才貼好、家具都搬進去，結果地基後續又得微調，前面做的裝潢多半就得整批拆掉重弄一次。
WordPress 網站的核心、外掛、主題，其實也是同一種「下層先決定上層規格」的關係，核心是地基，外掛和主題則是蓋在地基上的裝潢。外掛與主題的開發者，永遠是先看著當下最新的核心版本長什麼樣子，才調整自己的更新去對齊；核心版本一天沒跟上，外掛新版本要用的新規格就沒有地基可以踩。這也是為什麼 WordPress 更新順序一旦顛倒，相容性衝突或白費工夫就特別容易發生，不是核心、外掛、主題哪一個先更新都沒差，而是誰該先對齊誰、為什麼要照這個順序、更新前後又各自該做什麼，這幾件事得串在一起才真的管用。
先從順序背後那層因果關係講起，再一路拆到動手更新的具體步驟、更新後該盯著看什麼，以及真的出狀況時還有哪些後路。
為什麼更新順序會影響相容性？
順序不是形式主義，而是把「誰該先對齊誰」這件事講清楚。外掛與主題的開發者，在測試與調整自己更新的時候，基準永遠是當下最新的 WordPress 核心版本，他們看的是新版核心開放了哪些功能、調整了哪些底層規格，再決定外掛或主題這次更新要跟上什麼。核心版本要是沒跟上，外掛新版本用到的新規格，自然就找不到對應的地基可以踩。
反過來，核心跳版時，也不只是加新功能，還會逐步淘汰一些舊的底層函式。這些函式通常先被標記為已淘汰，過一段時間才真正從程式碼裡移除。外掛如果還在呼叫這些被淘汰、甚至已經被移除的函式，遇到核心大版本更新，就可能出現無法預期的錯誤，甚至整頁空白。
WordPress 官方文件也特別提醒，更新過程會覆蓋既有的核心與主題檔案，若曾經修改過這些檔案，改動內容就會遺失。這句警告背後的道理其實相通，你依賴的底層東西一旦被換掉，原本靠著它運作的部分自然跟著出狀況。這也點出一個容易被忽略的認知，核心先更新完，不代表外掛和主題可以放著不管，核心只是把地基換成新規格，真正要適應新規格的是蓋在上面的外掛與主題，沒有跟著檢查，新地基上的舊裝潢遲早會出問題。
更新前，兩件事沒做，順序再對也沒用
就算完全照著正確順序，先核心、再外掛、後主題一路來，也不代表這次更新一定順利。順序管的是衝突發生的機率，備份與測試環境管的是衝突真的發生之後，你還剩多少退路。這兩件事，是動手更新前最容易被跳過，卻也最容易讓一次小狀況變成沒辦法收拾的麻煩的準備工作。
沒做完整備份，一旦更新後網站出問題，你能做的選擇就只剩硬著頭皮往下修，連退回更新前的狀態都做不到。沒有測試環境，任何一次更新的第一個試驗場，就會是正式站，也就是你的訪客親眼看到的那個版本。
備份要包含什麼，存在哪裡才安全
很多人講到「備份」，想到的只是文章內容，但 WordPress 真正該備份的範圍比這大得多。資料庫存著你的文章、頁面、留言與各種設定；媒體檔案庫存著上傳過的圖片與附件；外掛與主題的程式檔案，決定了網站現在的功能與外觀；設定檔像是 wp-config.php 與 .htaccess，則掌管資料庫連線和網址規則這類底層行為。這幾個部分只要缺一塊，備份就稱不上完整。
WordPress 官方文件也把這幾樣列進建議的備份範圍，資料庫、WordPress 目錄下的所有檔案（含 .htaccess）都要含在內，並且提醒務必驗證備份確實存在、真的可以還原，而不是設定了自動備份就當作萬事俱備。
備份放的位置同樣重要。備份不能只留在主機本身，主機出狀況，不管是被入侵、硬碟故障，還是更新搞砸整個環境，跟著遭殃的往往連備份檔一起賠進去。至少要留一份放在主機以外的地方，雲端儲存空間或自己的電腦都可以，確保就算主機那端徹底出問題，你手上仍有一份能拿來重建網站的完整副本。
沒有測試站，更新前先開維護模式
有測試站的話，先在那裡完整走一次更新流程，把核心、外掛、主題都更新過一輪，再確認前台、後台、表單這些關鍵功能都正常運作，最後才把同樣的步驟搬到正式站執行。測試站原則上是正式站的私人複本，任何更新途中冒出來的問題，都只會在那裡出現，不會被任何一位訪客看到。
沒有測試環境的情況下，退而求其次的做法是，更新期間先開啟維護模式，並且挑離峰時段執行。維護模式會在更新進行的當下，把前台換成一個簡單的告示頁面，訪客不會看到更新過程中殘破、跑版，甚至整頁空白的畫面。多數主機服務都提供一鍵把正式站複製到臨時網址的功能，如果平常沒有固定的測試環境，也可以在真的要動大版本更新前，先臨時複製一份出來練習。
正確順序：核心、外掛、主題，一次一個
順序背後的邏輯前面已經講完，這裡把「怎麼做」具體攤開成三個步驟。核心優先的理由不再重複，這一段的重點在操作順序，以及每一步做完之後你該停下來檢查什麼，而不是把所有更新一次按下去。
第一步：先更新 WordPress 核心
從後台的「更新」頁面，先處理核心版本。點下更新之後，不要急著關掉分頁，先到前台看幾個關鍵頁面，像是首頁、文章頁、聯絡表單，確認畫面正常顯示；再回後台登入一次，確認可以正常進入儀表板。
核心版本本身相對穩定，近幾年核心層級出的問題也不多，但這一步是後面所有判斷的基準點。跳過這道檢查、核心一更新完就直接處理外掛，萬一核心真的出了狀況，你很可能會誤判成是後面某個外掛造成的，反而抓錯方向，白花時間排查。如果更新過程中 WordPress 判斷需要進行資料庫升級，畫面會自動偵測並提示，這時候盡快完成即可，不需要額外操作。
第二步：外掛要一個一個更新，別按下「全部更新」
外掛不要一次全部更新，而是一個一個處理。每更新完一個，就到前台看一次，確認沒有異狀再處理下一個。這樣做的理由很單純，萬一真的出問題，你會立刻知道是哪一個外掛造成的，不必面對好幾個外掛同時更新完、卻抓不出問題出在哪一個的窘境。
更新前，可以先看一眼該外掛的「檢視版本詳情」，也就是它的變更紀錄。寫著安全性修補的版本要優先處理，單純的功能更新則可以先觀察社群回報幾天，確認沒有大量負評再動手也不遲。資安公司 Patchstack 針對 2025 年的分析指出，當年 WordPress 生態系新發現的漏洞裡，91% 出現在外掛、9% 在主題，核心本身只有 6 個且都屬於低風險等級；當年新增漏洞數量達 11,334 個，比前一年成長 42%，其中約半數高風險漏洞，在被公開揭露的 24 小時內就會遭到鎖定攻擊，46% 的漏洞在公開揭露當下甚至還沒有可用的修補版本。換句話說，外掛才是相容性與安全風險真正比較密集出現的地方，而且威脅來得很快，安全性修補優先處理不是保守，而是這組數字撐出來的合理判斷。
變更紀錄常常落落長，而且多半是英文，逐行讀很花時間。看不懂的時候，可以把整段變更紀錄貼給 AI 助手，像是 ChatGPT、Claude，請它抓出有沒有提到「breaking change」「deprecated」這類關鍵字，速度比自己一行一行對照英文快得多，尤其是外掛數量多、時間又有限的時候特別好用。
牽涉版面呈現或金流、購物流程的外掛，更新後值得多留意一下，別急著關掉分頁就去忙別的事。這類外掛一旦更新後出狀況，影響到的往往不是單一頁面的顯示，而是訪客能不能順利完成結帳，或者整個網站的版面有沒有跑掉。
第三步：外掛都沒問題，才輪到主題
外掛全部更新完、狀況都排除之後，才輪到主題。主題排在最後，是因為它對網站運作邏輯的直接影響通常小於外掛，主題出問題大多反映在版面與樣式，而不是後端功能整個失效。更新完主題之後，一樣要到前台巡一次，尤其是首頁、單篇文章頁這類模板差異比較大的頁面，看排版有沒有跑掉、字體或間距是不是跟更新前不一樣。
如果你用的是子主題架構，更新父主題前要特別留意自訂的樣式或程式碼有沒有可能被覆蓋。父主題本身的檔案在更新時會被整批替換，子主題原本用來覆寫父主題的那些自訂內容，理論上不會受影響，但保險起見，最好先確認子主題和父主題之間的修改沒有衝突，再動手更新父主題。
WordPress 官方文件也明確提醒，曾經修改過主題檔案的話，更新會直接覆蓋這些修改，改動內容會遺失。子主題架構原本要解決的正是這個問題，更新前多留意一次，能避免辛苦調整過的樣式一夕之間全部消失。
更新後，多久要盯著網站看？
更新按下去、進度跑完，不代表這次更新已經結束。接下來這一小段時間，才是真正該盯著網站看的時候，而不是確認畫面沒有立刻報錯，就關掉分頁去忙別的事。
具體要看的項目其實不多。前台幾個流量比較大的頁面要重新整理看一次，確認排版和圖片正常顯示；後台要重新登入一次，確認能正常進入儀表板；如果網站有表單或結帳這類關鍵流程，實際跑一次測試，確認送出、付款這些步驟都能順利完成；瀏覽器的開發者工具也可以打開看一下，確認有沒有跳出新的錯誤訊息。
檢查之前，記得先把快取清乾淨。如果網站有安裝快取外掛，或者主機本身就有快取機制，你看到的畫面很可能還是更新前的舊版本，這時候即使外掛真的出了問題，畫面看起來卻一切正常，等於是被快取誤導，以為更新沒有任何影響。清完快取再檢查一次，才是網站當下真正的樣子。
更新後網站真的壞了，還有哪些後路？
WordPress 本身設計了幾層安全網，但這些安全網保護得到的範圍，其實比多數人以為的窄。搞清楚它們能擋什麼、擋不住什麼，才不會誤以為反正 WordPress 自己會擋，而掉以輕心。
從 WordPress 6.3 開始，手動更新外掛或主題如果失敗，系統會自動把更新前的版本復原，讓網站維持在可以正常運作的狀態，不會卡在一半、變成外掛檔案缺東缺西的殘破狀態。到了 6.6，這個保護再往前推一步，涵蓋自動更新。如果自動更新之後首頁跑出 PHP 致命錯誤，WordPress 會發出一個迴環請求到首頁確認狀況，一旦真的偵測到錯誤，就自動把該外掛回滾到更新前的版本，同時寄一封通知信到你網站設定的管理員信箱，告訴你哪個外掛更新失敗、已經復原。
這個機制聽起來很完整，但侷限也很明確。它只認得出首頁的 PHP 致命錯誤，版面跑掉、JavaScript 出錯、結帳流程失敗，這些問題它完全偵測不到，因為這些狀況通常不會讓首頁直接跳出 PHP 錯誤，對系統來說，頁面有正常回應就算過關。換句話說，自動回滾抓得到的是網站整個當機這種最極端的狀況，抓不到網站表面上還在動、某個功能卻已經壞掉這種更常見、也更容易被忽略的問題。
真正能兜底的，還是完整、驗證過可以還原的備份，這件事文章一開始就講過。內建的自動回滾機制值得慶幸有它在，但它是最後一道、範圍最窄的防線，不是唯一的防線；把備份和測試站顧好，才是不管出什麼狀況都能全身而退的根本做法。
自動更新，哪些該開、哪些該關？
很多人不確定自動更新該不該打開，答案得先分清楚 WordPress 預設的行為長什麼樣子。核心的次要版本更新，也就是維護與安全性修補，WordPress 早就設定成預設自動套用，不用你動手，背景就會默默完成。核心的主要版本更新則要看情況。如果你的網站是 WordPress 5.6 以後才新安裝的，主要版本也是預設自動更新；如果網站是從更早的版本一路用到現在，大版本更新預設仍然維持手動，需要你自己按下更新按鈕才會進行。至於外掛與主題，絕大多數預設也是手動，除非你自己去打開自動更新開關。
後台的「外掛」列表，可以針對每一個外掛單獨切換自動更新開關，不必整批設定同一種行為；某些外掛你放心讓它自動跑，某些外掛你想每次都自己盯著，兩種做法可以並存在同一個網站上。
判斷原則其實不複雜，不太會動到版面呈現、也不涉及金流或結帳流程的外掛，適合打開自動更新，讓它在背景默默跟上安全性修補；會直接影響網站門面，或者牽涉交易流程的外掛與主題，建議維持手動，照前面提到的順序自己一個一個來，更新完立刻檢查。
比較進階的做法，是透過設定檔控制核心自動更新的層級，而不是只能整批開或整批關。這個設定值有三種：全部開啟（開發版、次要版、主要版都自動）、全部關閉，或者只開啟次要版本、次要版本以外一律手動，對想要精準拿捏自動化程度的人來說，這是比後台勾選更細緻的做法。
根據 W3Techs 的統計，WordPress 目前用於全球約 41% 的網站，在已經安裝內容管理系統的網站當中，市占更超過 59%。用的人這麼多，代表更新策略沒設定好，牽動到的網站數量從來都不是小事，自動更新該開哪些、該關哪些，值得花時間想清楚，而不是裝好就再也沒檢查過。
回到蓋房子的比喻，順序從來不是形式主義，而是把「誰該先對齊誰」這條責任鏈交接清楚，核心先動，外掛與主題才有明確的地基可以對齊。備份、測試、逐步檢查，做的其實是同一件事，把每一次更新都變成一個可以收回的決定，而不是賭一把，賭這次不會出狀況。
下次後台又跳出更新通知，不用急著把所有勾選框都打勾再一次按下去。先核心，再外掛，最後才是主題，每一步後面都停下來看一眼，這幾秒鐘的耐心，換到的是一個不用擔心哪天更新完就再也回不去的網站。