多數人對 WordPress 自動更新只有兩種立場：一種覺得全部打開最安全，反正官方推的新版一定是好的；另一種被雷過一次之後全部關掉，寧可自己慢慢來。這兩種其實都不是正解。「昨天還好好的、今天打開網站就白屏」這種狀況，往往就是「一刀切設定」的產物。不是自動更新本身壞，而是把該分開處理的東西綁在同一個開關上。
先把一件事講清楚：WordPress 的更新根本不是一個開關。核心、外掛、佈景主題、翻譯檔，其實是四種各自獨立的更新，各自的預設行為、風險等級都不一樣。 有些預設就開著、關不掉才怪；有些預設是關的，你不去開它永遠不會自動更新。把它們當成同一件事，才是很多網站出狀況的真正起點。
這篇要給你的不是「全開或全關」的口號，而是一份「哪些該交給系統、哪些該留給自己」的 WordPress 自動更新設定判斷依據。先弄懂這四種更新各是什麼、預設在哪個狀態，後面要怎麼分層設定才會水到渠成。
WordPress 有哪幾種自動更新，各自預設狀態是什麼？
WordPress 後台那些「更新」提示，背後其實是四套獨立運作的機制，不是一個總開關。多數操作教學會直接教你去哪裡點，卻跳過這層認知。結果就是有人以為勾了一個設定全站就自動了，其實漏掉一大半。先把四種更新各自的預設狀態攤開來看。
- 核心小版本更新：這是唯一從一開始就預設自動、而且你幾乎不需要動它的一種。所謂小版本，指的是 6.6.1、6.6.2 這種維護與安全性修補；自 WordPress 3.7 導入自動更新以來，小版本一直是預設自動安裝的，這也是 WordPress 生態最重要的一道安全底線。安全漏洞的修補通常就靠這條管道在幾乎無感的情況下推到你的站上。
- 核心主版本更新：也就是 6.5 升到 6.6 這種大版本。這一種的預設狀態要看你的站是什麼時候裝的。自 WordPress 5.6 起，全新安裝的網站預設連主版本也一起自動更新；但如果你的站是 5.6 之前就建好、後來才升級上來的既有安裝，行為維持不變，只自動小版本，主版本要你自己到後台勾選才會自動。這個「新舊安裝不一樣」的分野，是很多人搞不清楚自己站到底會不會自動大改版的主因。
- 外掛與佈景主題更新：這兩種預設都是關的。自 WordPress 5.5 起，後台的外掛列表多了一欄「自動更新」、佈景主題也能在彈窗裡開關，讓你不用寫程式就能逐一設定；但官方把它預設成關閉，要你自己一個一個手動開。所以如果你從沒去點過那一欄，你的外掛其實一直是手動更新的狀態，這也是下面要談的風險重點。
- 翻譯檔更新：像繁體中文語系檔這種翻譯更新，預設是自動的，通常不太需要你操心。
看懂這張表，你會發現真正需要你做決定的，其實是「核心主版本」和「外掛佈景主題」這兩塊。剩下的，系統早就替你顧著了。
只顧著手動更新，網站可能承擔什麼風險？
那乾脆全部關掉、自己有空再手動更新不行嗎？問題就出在「有空再說」的那段時間差。攻擊者的掃描速度，遠比多數人想像得快。
先看漏洞集中在哪裡。根據資安公司 Patchstack 的《State of WordPress Security in 2025》報告，2024 年整個 WordPress 生態系新增了 7,966 個安全漏洞，比 2023 年成長了 34%；其中高達 96% 出現在外掛、只有 4% 在佈景主題。換句話說，網站真正的破口幾乎都在外掛這一層，偏偏這一層預設又是關著自動更新的。你不主動開，它就一直是手動。
更棘手的是修補的時間差。同一份報告指出，有 33% 的漏洞在被公開揭露的當下，官方根本還沒修好。這代表「等官方出新版我再手動更新」這個策略本身就有空窗期，因為有三分之一的情況，被公開的時候連新版都還沒有，你想手動也沒得更新。而漏洞資訊一旦公開，攻擊往往幾個小時內就來。報告記錄的 Bricks Builder 佈景主題遠端程式碼執行漏洞就是活生生的例子：漏洞公開後短短數小時內，就有多個 IP 位址跑起腳本化的大規模掃描攻擊，連多數主機商用的 WAF 防火牆都沒能擋下來。
把這個時間軸套到一個實際情境上：假設有一家中小企業的型錄網站，用了某個熱門外掛，站長習慣週末才有空登入後台一次。某個週三下午，這個外掛的嚴重漏洞被公開，攻擊腳本當晚就掃遍全網、逐一試探還沒更新的站。等站長週末登入時，網站可能早就被植入後門了。這中間的落差，不是站長不用心，而是「手動更新」這個節奏，天生追不上自動化攻擊的速度。安全性這一類的更新，是最不該押在「我有空再處理」上的。
全部自動更新又可能踩到什麼雷？
聽起來全部自動更新最安全吧？可惜另一個極端也有它的坑。全自動更新真正的風險不是安全性，而是相容性，尤其對客製化過的網站來說。
最常見的是外掛之間、或外掛與佈景主題之間的版本衝突。某個外掛推了新版，剛好跟你站上另一個外掛的某個功能或某段程式碼對不起來，輕則某個區塊顯示異常，重則整個頁面出現錯誤甚至當機。這種衝突在單純的部落格站上或許很少遇到，但只要你的站堆疊了較多外掛、或用了彼此有相依關係的功能，機率就會上升。
第二個坑，是直接改過佈景主題檔案的站。如果你當初為了調整版面，直接動了佈景主題資料夾裡的 PHP 或樣式檔，那麼一旦佈景主題自動更新，新版檔案會直接覆蓋掉你的自訂修改，改的東西就這麼不見了。這也是為什麼有經驗的人都建議客製化要走子主題（child theme），而不是動原始檔案。但如果你的站當初沒這樣做，開佈景主題自動更新就要格外小心。
第三個要考量的是營收。對企業官網、購物網站來說，即使只是短暫的當機或結帳流程出錯，都可能直接對應到訂單流失。這類站台不該讓更新「上了才知道有沒有問題」，比較穩妥的做法是先在測試環境（staging）裡驗證過這一版沒問題，再推到正式站。國際知名的 WordPress 教學站 WPBeginner 也提醒，設定與客製化越複雜的網站，處理自動更新就越要謹慎，不能跟一個簡單的個人部落格套同一套邏輯。
所以你會發現，「全開」和「全關」之間，其實不是二選一，而是有一整片可以按風險分層的中間地帶。而且好消息是，新版 WordPress 已經幫你把「全開」的風險降低了不少。
好消息：新版 WordPress 已經內建更新失敗的安全網
很多人對自動更新的恐懼，其實停在幾年前的舊印象裡，那個「一旦某個外掛更新失敗，整個網站就白屏、你完全不知道發生什麼事」的年代。這件事其實已經被 WordPress 官方修掉了大半。
起點是 WordPress 6.3。從這一版開始，你手動更新外掛時，如果新版本一啟用就觸發 PHP 致命錯誤（fatal error），系統不會硬把這個出問題的外掛重新啟用，而是讓它保持停用，避免整站被一個壞掉的外掛拖垮。這是「更新失敗保護」的第一步，但當時只涵蓋手動更新。
真正的轉折在 WordPress 6.6。這一版把同樣的保護延伸到了自動更新，當某個外掛自動更新後導致 PHP 致命錯誤時，系統會偵測到，並自動把這個外掛回滾（rollback）到更新前的舊版本，讓網站繼續正常運作，而不是丟給你一片白屏。它的運作方式是在更新後對首頁發一個內部請求做檢查，一旦發現致命錯誤，就判定這次更新不安全、還原成舊版，然後繼續處理佇列裡其他的更新項目。回滾發生後，系統還會寄一封通知信到管理員信箱，告訴你哪個外掛更新失敗、已經被還原。
這層安全網把「開自動更新等於賭網站會不會爆」的焦慮降了很多。不過有兩件事要提醒你，別把它當成萬能保險。第一，它只抓得到首頁的 PHP 致命錯誤，抓不到版面跑掉、JavaScript 出錯、或購物車結帳流程壞掉這種「不會噴致命錯誤、但功能其實壞了」的狀況。第二，那封通知信終究要有人去看。這個機制降低的是「當機」風險，不是「你完全不用管」。所以它不是讓你可以撒手不理，而是讓你在「開自動更新」這個決定上，多了一層可以放心的底氣。
該怎麼幫網站分層設定自動更新？
前面鋪陳到這裡，核心的判斷框架其實已經浮現。自動更新不是全開或全關的二選一，而是依風險等級分層。同樣一個「要不要自動」的問題，套在不同類型的更新上，答案本來就該不一樣。
分層的原則可以這樣抓：
- 核心小版本、安全性更新：永遠維持自動。這是風險最低、影響最小、卻最攸關安全的一類，交給系統處理最省心，沒有理由關掉。
- 核心主版本：看站台複雜度決定。單純的部落格或內容站，開著自動主版本更新通常沒問題；但如果是重度客製、堆了很多外掛、或營收吃緊的商業站，把主版本留給人工，先在測試環境驗證再手動升級會更穩。
- 外掛與佈景主題：逐一評估，不要一鍵全開。沒動過原始碼、來源可靠的外掛，可以放心開自動更新（尤其有了 6.6 的自動回滾當後盾）；但被你客製修改過、或牽動核心功能的重要外掛與佈景主題，建議先留給人工，測過再更。
原則抓好之後，剩下的就是「用哪種方式去設定」。下面三種管道，從最直覺到最進階，你依自己熟悉程度挑一種就好，不需要全部都會。
用後台介面逐一開關外掛與佈景主題自動更新
這是最直覺、完全不用碰程式碼的方式，適合絕大多數使用者。自 WordPress 5.5 起，這些開關就內建在後台了。
想開關外掛的自動更新，到後台的「外掛」列表，你會在最右邊看到一欄「自動更新」，每個外掛旁邊都有一個切換連結。想讓哪個外掛自動更新，就點「啟用自動更新」，不想要的維持關閉即可，可以一個一個獨立設定。
佈景主題則是到「外觀」的「佈景主題」頁，點進某個主題的詳細資訊彈窗，裡面也有一個開關可以切換該主題要不要自動更新。
這種方式的好處是所見即所得、隨時可改，而且天生就是「逐一評估」的操作邏輯。你會被迫一個一個看過去，而不是無腦全開。對大多數中小型網站來說，光靠這個後台介面就足夠應付日常需求了。
用 wp-config.php 常數統一控制核心更新
如果你想更精準地掌控核心版本、又不想每次都手動到後台按，可以直接在網站根目錄的 wp-config.php 檔案裡定義常數。這適合稍微熟悉檔案操作、想一次把規則寫死的人。
控制核心更新的主角是 WP_AUTO_UPDATE_CORE 這個常數，它有三種官方支援的值：
// 全部自動：小版本與主版本核心更新都自動安裝
define( 'WP_AUTO_UPDATE_CORE', true );
// 全部手動：關閉所有核心自動更新，小版本也不自動
define( 'WP_AUTO_UPDATE_CORE', false );
// 只自動小版本：主版本留給手動（穩定版安裝的預設值就是這個）
define( 'WP_AUTO_UPDATE_CORE', 'minor' );Code language: PHP (php)設成 true 是連主版本都交給系統；設成 false 則連小版本安全修補都會停掉，這一點要特別謹慎。把安全更新一起關掉，等於自願承擔前面講的那些風險，一般不建議。而 'minor' 正好對應「核心小版本自動、主版本手動」這個對多數站都相當穩妥的分層原則，它其實也就是穩定版安裝在你什麼都不設時的預設行為。
另外還有一個層級更高的常數要認識，叫做 AUTOMATIC_UPDATER_DISABLED。
// 關掉所有類型的自動更新（核心、外掛、佈景主題、翻譯全部停）
define( 'AUTOMATIC_UPDATER_DISABLED', true );Code language: PHP (php)它和 WP_AUTO_UPDATE_CORE 的差別在管轄範圍：後者只管核心，前者一設下去，是把核心、外掛、佈景主題、翻譯全部的自動更新一次關光。這通常只有在很特殊的情境（例如整站交由外部流程統一控管更新）才會用到，對一般網站來說幾乎不需要，設錯了反而會把安全防線整個拆掉，要用之前先想清楚。
用篩選器批次管理多個外掛與佈景主題
如果你同時管理好幾個站、或想一次性批次決定哪些外掛要不要自動更新，而不想一個一個到後台勾，那可以走篩選器（filter）這條路。這是給進階使用者的做法。
WordPress 提供了 auto_update_plugin 和 auto_update_theme 這兩個篩選器，讓你用程式碼決定自動更新的規則。舉例來說，你可以掛一段 callback，讓它針對一份指定的外掛清單回傳要不要自動更新，不是全有全無：
// 只讓清單裡列出的外掛自動更新，其餘維持原設定
add_filter( 'auto_update_plugin', function ( $update, $item ) {
$auto_update_slugs = array(
'akismet/akismet.php',
'woocommerce/woocommerce.php',
);
if ( in_array( $item->plugin, $auto_update_slugs, true ) ) {
return true;
}
return $update;
}, 10, 2 );Code language: PHP (php)透過 $item 帶進來的外掛資訊（例如 slug 或路徑），你可以精準地只針對特定外掛開啟或關閉自動更新，把「哪些信得過、交給系統，哪些要留人工」的判斷直接寫成程式邏輯。
擺放這段程式碼的位置也有講究，建議放進 wp-content 底下的 mu-plugins（must-use plugins）資料夾。放在這裡的程式碼會被 WordPress 自動啟用、不會出現在外掛列表裡，也就不會有人不小心把它停用，確保你的更新規則穩穩地一直生效。對管理多站的人來說，把同一份規則檔複製到各站的 mu-plugins，就能讓所有站台維持一致的更新策略。
開了自動更新之後，還要做哪些事才安心？
設定完自動更新的開關，很容易讓人以為從此一勞永逸，這是最後一個要破除的迷思。開自動更新降低的是「該更新卻沒更新」的風險，但它取代不了幾個更新之外的維運習慣。真正讓網站長期安穩的，是把自動更新放進一套完整的作業流程裡。
第一件事是備份。自動更新再聰明，也不保證每一次都零意外，所以定期備份是底線；而在遇到核心主版本這種重大更新之前，最好額外手動備份一次，留一個明確的還原點。萬一更新真的出了自動回滾也救不了的狀況（例如資料庫結構被改動、版面壞掉但沒噴致命錯誤），你手上有一份剛備份好的完整檔案，就能從容還原，而不是對著壞掉的站乾著急。
第二件事是善用測試環境。如果你的主機或代管方案有提供測試環境（staging），養成「先在測試站更新、確認沒問題再推正式站」的習慣，尤其對商業型網站來說很值得。這一步能把前面提到的相容性風險，攔在還沒影響到真實訪客與訂單之前。
第三件事是定期看更新通知信。前面提過，WordPress 6.6 的自動回滾會在更新失敗時寄信通知你。但這封信要有人去看才有意義。養成定期檢視這些通知、留意有沒有失敗項目的習慣，你才會知道站上是不是有某個外掛一直更新不成功、需要你介入處理。
第四件事，也是最容易被忽略的：盤點並移除閒置的外掛。你的站上很可能躺著幾個當初裝了、後來根本沒在用的外掛。這類外掛的危險在於，如果它已經被官方從外掛庫下架、沒有人再維護，那它的漏洞就永遠不會被修補，自動更新也救不了它，因為根本沒有新版可更。前面那份 Patchstack 報告就提到，2024 年因為安全問題未修補而被移出官方外掛庫的外掛與佈景主題，總共多達 1,614 個。這些留在你站上的「殭屍外掛」，等於一直開著一道沒人守的後門。定期清掉不用的外掛，比多裝一個安全外掛還實在。
自動更新從來不是一個「你信不信任 WordPress」的問題，而是一個「你有沒有分層」的問題。把風險低、影響小的更新交給系統自動處理，把有客製修改、牽動營收的部分留給自己在測試環境驗證後再上線。這樣配置好，你既省下天天盯更新的力氣，又不必擔心某天一覺醒來網站白屏。真正讓網站「昨天好好的、今天壞了」的，很少是自動更新本身，而是那個從來沒被分過層的、一刀切的設定。今天就打開你的外掛列表看一眼，那一欄「自動更新」，設對了沒有。