後台選單裡的「工具」底下，有一個叫「網站健康」的頁面，不少人是被裡面一整排紅色的「嚴重問題」嚇到，才第一次點進去研究這個功能在講什麼。畫面上寫著 PHP 版本過舊、迴圈請求失敗、REST API 發生錯誤，術語一個接一個，讀起來像是網站已經出了大事，甚至懷疑自己是不是被駭客入侵了。
其實這正是 WordPress網站健康這項自我診斷功能，從 5.2 版起就內建在後台，只掃描 WordPress 自己認得出的設定與環境問題，不是外部資安公司出具的健檢報告，更不會檢查網站有沒有被植入惡意程式碼。把每一項警示都當成火燒眉毛，反而容易花時間去改一些對網站其實沒什麼幫助的設定，真正該優先處理的項目卻被埋在一堆雜訊裡。
先弄清楚這個頁面在哪裡看、分成哪兩個頁籤，再照六大類警示一項一項拆開來看，才分得清紅字背後是主機該調整的環境設定，還是可以慢慢排進維護排程的小事。
WordPress網站健康是什麼？
打開 WordPress 後台，在「工具」選單底下就能找到「網站健康」這個項目，官方文件把它定位得很清楚，這是後台內建的自我診斷畫面，分成「狀態」與「資訊」兩個頁籤。
「狀態」頁籤是多數人會先看到的畫面，顯示的是關於這個 WordPress 設定目前狀態的關鍵資訊，結果依嚴重程度分成三類：「嚴重問題」代表確實需要處理的資安或效能疑慮，「建議改善」代表可以做但不急迫的優化項目，「已通過測試」代表這一項目前沒有問題。「資訊」頁籤則完全是另一回事，裡面蒐集的是伺服器版本、PHP 設定、資料庫版本這類技術細節，主要給站長或主機商的技術人員參考，本身不會修復任何問題，單純是給你複製貼上去問客服用的資料。
這個功能只回報 WordPress 自己認得出的設定與環境問題，例如 PHP 版本、更新機制、通訊功能有沒有正常運作。頁面明明看起來壞掉、表單送出沒反應、外觀跑版，這類肉眼看得到的視覺或功能異常，網站健康完全不會發現，因為它檢查的是底層環境，不是前台畫面本身；同樣地，它也不掃描惡意程式碼、不比對檔案有沒有被竄改，看到滿版綠燈也不代表網站沒被駭。看懂這一層分工，才不會誤把它當成萬能的資安健檢。
現在的網站健康判定只分兩種狀態不再顯示百分比
不少人對「網站健康」的第一印象還停留在一個像信用分數的百分比，覺得沒衝到 100%就代表哪裡沒做好，但現在的判定方式早就不是這樣運作。
WordPress 5.2 版在 2019 年 5 月推出這項功能時，畫面頂端的確會顯示一個百分比，但同年 11 月的 5.3 版就把它拿掉了，改成只顯示「良好」或「應改善」兩種狀態，底下另外列出嚴重問題、建議改善、已通過測試各有幾項。WordPress 核心開發團隊在說明這次調整時提到，原本那個百分比容易讓人誤會成這個網站有多完美，實際上它只是在算有多少項測試通過而已；拿掉百分比之後，頂端那個圓形指示只剩提醒還有事可做的作用，不再帶著分數不及格的負面感受。
判定邏輯是每一項測試各自回傳良好、建議改善、嚴重三種狀態的其中一種，頂端的整體狀態再依這些結果加權判斷。同一篇說明也提到，5.3 版起只要出現任何一項嚴重問題，整體一律顯示為應改善，不會因為其他項目全部通過就被稀釋掉；建議改善的權重則刻意調低，避免外掛自行加掛的檢查項目一多就左右整體結果。從 WordPress 核心的程式碼來看，嚴重問題的權重是建議改善的三倍，沒有嚴重問題時，換算出來的分數要達到 80 以上才會顯示良好，這個分數不會以百分比出現在畫面上。所以建議改善累積得夠多，即使沒有任何嚴重問題，整體狀態一樣可能變成應改善，判斷時還是要回到每一項的實際內容，而不是盯著頂端那兩個字。
PHP 版本項目比對的是官方支援期限而非版本新舊
看到「PHP 版本過舊」這句警示，很多人直覺反應是自己沒跟上最新版，但 WordPress 比對的其實是這個 PHP 版本還在不在官方支援期限內，不是有沒有用到最新的大版本號。
判定機制本身不是寫死在 WordPress 程式裡的一張版本清單，而是即時呼叫 api.wordpress.org 提供的 Serve Happy API，取得目前這個 PHP 版本的建議版本、是否仍受支援、是否還有安全性修補等資訊，查詢結果會快取大約一週。如果這支 API 連不上，畫面顯示的會是無法存取 WordPress.org 服務，而不是直接判定為嚴重問題。這也代表 PHP 版本這一項的結果，其實是跟著 WordPress.org 依 PHP 官方支援政策設定的判定在變動，不是寫死在你手上這一版 WordPress 裡。
超過官方支援年限，PHP 版本就被判定為安全隱憂
PHP 官方把支援政策分成兩個階段：先進入積極支援，這段期間同時提供錯誤修復與安全性修補；之後轉入僅安全性支援，只補安全性問題，不再修復一般錯誤；兩階段合計的年限一到，就正式進入生命週期終止，官方不再提供任何修補。WordPress 把這套政策換算成三種判定：目前版本達到 WordPress 建議的版本就是良好；版本偏舊但還在官方支援範圍內（包含只剩安全性支援的階段）是建議改善；版本已經或即將完全不再受支援，就直接列為嚴重問題。
以查證當下（2026 年 10 月）的狀態來看，PHP 8.4 與 8.5 還在積極支援階段，8.2 與 8.3 已經進入僅安全性支援，8.1 及更早的版本則已經全數生命週期終止。不過 WordPress.org 這支 API 的判定不一定跟 PHP 官方時程同步，同一時間實際查詢 Serve Happy API，它給的建議版本是 8.3，而且仍把已經終止支援的 8.1 標成還有安全性修補，所以跑 8.1 的網站在後台看到的是建議改善，不是嚴重問題；反過來說，只剩安全性支援的 8.3 也會被判為良好。後台的判定只能當提醒，版本到底還有沒有支援，要以 PHP 官方清單為準。這張支援時程表每年都會往前推進一年，讀者對照自己網站的 PHP 版本時，建議直接查 PHP 官方目前公布的最新支援清單，而不是照抄任何一篇文章裡列出的年份。另外要提醒的是，PHP 版本通常是由主機商在伺服器端統一設定，站長沒辦法自己在 WordPress 後台切換，需要的話得向主機商申請調整，或是到主機控制台裡找 PHP 版本切換的選項，調整前也建議先做一次備份。
必要模組、時區與 PHP 工作階段的環境檢查
除了版本新舊，還有三種比較少被單獨拿出來講、但確實可能出現在嚴重問題清單裡的環境警示，共通點都是 PHP 執行環境本身的設定出了狀況，而不是 WordPress 核心版本的問題。第一種是缺少 WordPress 運作需要的 PHP 模組，例如官方文件舉例的 json_last_error 這一項沒有安裝或被主機端停用，會讓部分功能沒辦法正常運作。第二種是 PHP 的預設時區在 WordPress 載入之後被更動，這會干擾日期與時間的計算，連帶影響排程發佈、快取到期這類跟時間有關的功能。
第三種是偵測到一個沒有正常關閉的 PHP 工作階段，也就是有程式碼呼叫了 session_start() 卻沒有在對的時機關閉，這種未關閉的工作階段會干擾 REST API 與迴圈請求的運作，正確做法是在發出 HTTP 請求之前先呼叫 session_write_close() 把工作階段關掉。這三種都屬於需要調整 PHP 設定才能解決的問題，站長自己在 WordPress 後台改不了，遇到時最實際的做法是把警示內容整理清楚，拿去跟主機商的客服或工程團隊反映，讓對方在伺服器端處理。
HTTPS 加密連線缺席時的安全性警示
HTTPS 這一項在網站健康裡算是最單純的一類，不需要鋪陳太多背景，重點放在 WordPress 怎麼判斷這件事、以及判定沒有使用 HTTPS 之後該怎麼處理。檢測結果會列在狀態頁籤，只要偵測到網站位址還在用 http，就會列為建議改善、提示切換；資訊頁籤裡另有一個「這個網站是否使用 HTTPS」的欄位，直接標示目前是或否。
WordPress 5.7 版之後，只要主機已經裝好 SSL 憑證、環境本身支援 HTTPS，網站健康的 HTTPS 項目就會出現一個切換按鈕，把網址從 http 改成 https 可以直接在後台一鍵完成，不必再手動修改資料庫或另外裝外掛。不過切換完成不代表全部處理好，還要核對兩件事：網址列是不是真的全站顯示為 https，以及頁面裡的圖片、字型這類資源會不會還在引用 http 路徑，也就是常見的混合內容問題，只看網址列有沒有出現鎖頭圖示並不足以代表全站都設定完成。至於 SSL 憑證本身，通常是由主機商提供，或透過 Let’s Encrypt 這類機制核發，並不是 WordPress 自己核發或管理的東西。
背景更新、迴圈請求與對外連線的三種警示
這一類警示涵蓋三種機制：背景更新、迴圈請求，還有網站對外連到 WordPress.org 的通訊。三者的共通點是平常都在背景默默運作，正常運作時完全感覺不到它們的存在，一旦出問題，影響的往往不是眼前看得到的頁面內容，而是原本該自動處理的事情其實已經停擺一段時間，只是還沒被察覺而已。
這幾項要特別留意的是，WordPress 說明文件把「自動更新其實已經被停用，後台卻還照樣顯示自動更新設定」這種顯示與實際不一致的狀態，直接標記為資安類的嚴重問題，因為這會讓站長誤以為安全性更新會自動裝上，實際上完全沒有運作。
背景更新沒有生效，關掉的其實是安全更新的自動安裝
背景更新是 WordPress 遇到安全性更新時，能不經站長手動操作就自動裝上的機制，跟站長自己到更新頁面按下按鈕是完全不同的兩件事，這項警示代表這套自動安裝的管道目前沒有正常運作。
另一種常見情況是外掛或佈景主題的自動更新，已經在程式層被停用，後台卻還照樣顯示自動更新的開關，這種顯示狀態與實際行為不一致的狀況，會讓站長以為打開開關就會自動更新、安全性更新已經自動處理好，實際上外掛與佈景主題早就停在舊版本沒有跟著更新。這正是這項警示被列為安全性類嚴重問題的原因，問題不在於自動更新這個機制本身，而在於它沒有照畫面顯示的那樣真的運作。
迴圈請求失敗多半出在主機端的安全規則
迴圈請求，英文叫 loopback request，指的是 WordPress 對自己網域發出的請求，主要用來啟動排程事件，例如定時發佈的文章、外掛設定的排程任務，都要靠這個機制在背景觸發。佈景主題與外掛內建的程式碼編輯器，也會用迴圈請求來確認改動存檔之後網站還能不能正常回應，避免存了一段會讓網站掛掉的程式碼卻沒被發現。
這項測試的做法，是對 wp-cron.php 發出一個帶有登入 cookies 與特定參數的 POST 請求，逾時設定是 10 秒；之所以用 POST，是為了讓 wp-cron.php 提早結束，不會真的觸發一次排程任務。迴圈請求失敗時，通常不是 WordPress 本身壞掉，而是主機的防火牆規則、網站本身設了密碼保護、DNS 設定有問題，或是某個外掛彼此衝突，把這個內部請求擋在半路上，需要回頭檢查的方向是主機環境與外掛相容性，而不是 WordPress 核心程式碼。
連不上 WordPress.org 意味著版本回報功能已經中斷
WordPress 需要能連到 api.wordpress.org，才能確認目前這個版本是不是最新的，也才能安裝核心、外掛、佈景主題的更新。這項警示出現，代表網站目前沒辦法跟 WordPress.org 的伺服器正常通訊。
這種故障通常代表網站對外的連線被擋住了，常見原因是主機端的防火牆規則、網站上裝的資安外掛，或是 DNS 設定出了問題，並不是 WordPress.org 那端的伺服器有異常。實務上遇到這項警示，檢查方向應該放在自己網站的對外連線設定，而不是等著 WordPress.org 那邊修復什麼。
常數封鎖對外連線後的外掛與佈景主題風險
WP_HTTP_BLOCK_EXTERNAL 是 WordPress 提供的一個設定常數，站長可以用它封鎖網站對外部服務的全部或部分通訊，多半是出於安全考量刻意設定，想讓網站盡量不要跟不必要的外部服務往來。
問題是，如果封鎖清單設定得不夠完整，原本需要對外溝通的外掛與佈景主題功能，例如檢查外掛本身的更新、串接金流服務、發送通知信件，就會連帶一起失效，而且這類故障通常不會直接顯示某個功能壞掉這種明確訊息，往往要回頭查網站健康這個頁面，才會發現問題的源頭其實是這個常數設定不完整。設定這個常數前，建議先列清楚網站實際需要對外連線的服務有哪些，再把允許清單一次設定完整，而不是先封鎖再慢慢補漏洞。
除錯模式資訊外洩的兩種警示管道
除錯模式原本是開發階段用來蒐集錯誤細節的工具，正式上線的網站如果忘記關掉，原本只該給開發者看的系統路徑、資料庫結構、程式碼片段這類細節，就有可能被暴露出去。這一類警示分成兩種，差別只在於外洩的管道不同：一種是外洩到訪客眼前，一種是寫進一個可能被外部存取到的檔案，分別對應 WP_DEBUG_DISPLAY 與 WP_DEBUG_LOG 兩個設定值。這裡要先釐清一個容易誤會的地方，問題不在於除錯功能本身不能開，而在於除錯的輸出結果不該讓正式站的訪客或外部存取到。
顯示在前台的錯誤訊息，可能露出檔案路徑與程式細節
WP_DEBUG_DISPLAY 會被觸發，通常是因為 WP_DEBUG 本身開著，或是設定檔裡直接寫了這個值。一旦啟用，錯誤訊息就會直接印在網站前台，任何訪客都看得到，不只是站長自己。
這些錯誤訊息裡，常常帶著伺服器的檔案路徑、外掛或佈景主題的程式碼片段，這些資訊對一般訪客沒有意義，但對想找漏洞的人來說，等於是現成的線索，能讓對方更快摸清網站用了哪些外掛、程式架構長什麼樣子。正式上線的網站，這個設定值原則上應該保持關閉，除錯需求留在測試站或本機環境處理就好。
除錯紀錄寫進的檔案不一定只有網站管理者讀得到
WP_DEBUG_LOG 的做法是把錯誤寫進一個紀錄檔，而不是直接顯示在前台，聽起來比較安全，但 WordPress 官方文件特別提醒，這個紀錄檔本身很可能是任何人都能存取得到的檔案。
如果沒有額外做存取限制，例如把檔案放在對外不可讀取的目錄，或設定伺服器規則擋掉對這個檔案的直接請求，等於把同一批系統路徑與程式碼細節換一個地方外洩，只是外洩的對象從所有訪客，變成知道檔案位置就能讀到內容的人。這也是為什麼網站健康把這項也列為需要留意的警示，而不是因為看不到就代表沒有風險。
REST API 出現錯誤，通常是資安機制動的手腳
REST API 這一項警示，測試方式是用目前登入的使用者身份，實際向/wp-json/wp/v2/types/post?context=edit這個網址發出一次請求，逾時設定是 10 秒。如果這次請求整個連不上、逾時都沒收到回應，會被判定為嚴重問題；如果請求有收到回應，但狀態碼不是 200（例如回傳 403、404、500 這類錯誤代碼），或是回應內容不是預期的 JSON 格式，則會被判定為建議改善，還沒到嚴重問題的等級，但同樣代表請求半路被擋下來了。
這項測試之所以重要，是因為 REST API 並不是一個可有可無的附加功能，而是區塊編輯器、應用程式密碼登入、還有大量外掛的管理畫面在背後實際仰賴的溝通管道。REST API 被完全封鎖之後，不會馬上跳出某功能故障這種明確訊息，前台看起來可能一切正常，但某些操作背後開始出現說不出原因的失敗，例如編輯器存檔變慢、某些外掛設定畫面讀不到資料，回頭一查才發現源頭在這裡。
資安外掛或伺服器防火牆常見的封鎖來源
多數情況下，REST API 出錯不是 WordPress 核心本身的問題，而是網站上裝的資安外掛主動限制了 REST API 的存取範圍，或是伺服器層（包含 CDN、WAF 這類服務）的防火牆規則，把特定路徑的請求擋在門外。
遇到這項警示，實際的檢查方向是回頭確認是不是自己（或委託代管的廠商）設定的資安規則正在生效，而不是假設 WordPress 本身壞了。REST API 是 WordPress 與其他應用程式交換資料的標準通道，多數官方功能與第三方整合都要透過它運作，不建議直接把它整個關掉，遇到資安考量，更精準的做法是限制特定端點的存取範圍，而不是一刀切全部封鎖。
檔案上傳功能被伺服器設定停用
另一個比較單純、但同樣被列為嚴重問題的警示，是伺服器的 file_uploads 設定被關掉，或是 ini_get() 這個函式本身被停用。這個設定一旦被關，整個網站會完全沒辦法上傳檔案，包括在媒體庫裡新增一張圖片都做不到。
這是伺服器層的 PHP 設定，WordPress 後台本身沒有對應的開關可以調整，遇到這項警示，需要做的是聯絡主機商，請對方確認並開啟這個設定，而不是在 WordPress 裡面找半天找不到解法。
閒置外掛與佈景主題，才是最常出現的改善建議
這一類收的多半是「建議改善」等級裡最常見的維護類項目，加上兩個比較新的效能建議；其中外掛有更新待安裝是例外，WordPress 把它列為嚴重問題。這幾項的共通點是不影響網站現在能不能正常運作，跟前面幾類「某個機制正在失效」不是同一種急迫程度，但放著不處理，長期會累積成資安與效能的隱性成本，包括多一個潛在的攻擊面，以及多佔用一點主機資源，不能因為不緊急就當成不用處理。
沒在用的外掛與佈景主題建議直接刪除而非停用就好
已經安裝但沒有啟用的外掛與佈景主題，會被網站健康列出來，原因跟停用與刪除的差別有關。外掛或佈景主題停用之後，程式碼不會被載入，不會直接拖慢網站速度，但檔案本身還留在主機上，等於多一個潛在的安全掃描對象。
留著不用的外掛，還有被誤點重新啟用，或是被有心人士利用舊版本已知漏洞的風險，官方建議的做法因此是確定不會再用就直接刪除，而不是停用之後留著備用。真的擔心之後還要用，備份設定或匯出資料會比留著整支閒置外掛更安全。
外掛有更新待安裝，牽動的是資安更新的速度
外掛有更新待安裝這一項，官方文件把它列在嚴重問題的範例裡，理由是外掛能深入存取網站的各個角落，從聯絡表單到金流串接都可能是外掛在處理，這代表外掛保持更新，是拿到安全性修補最直接的一條路。
不過這不代表每次跳出更新提示，都要不假思索立刻全部按下去。比較穩妥的做法是先看一下這次更新的說明，確認有沒有重大變更，備份過網站再處理，尤其是牽動金流或會員資料的外掛，更新前多一道確認，能避免因為版本不相容，反而讓網站當掉或功能跑掉。
持久化物件快取和自動載入選項的進階效能建議
這兩項是比較晚才加進網站健康、也比較少人聽過的效能類建議，看到這兩個名詞不代表網站設定有錯，而是 WordPress 在提醒，流量或資料庫查詢量已經到了某個規模，做這些調整會有感。持久化物件快取，像是 Redis 或 Memcached，能減少同一批資料被重複查詢資料庫的次數；WordPress 6.1 版新增了這項偵測，只有判定網站處於正式環境時才會出現這項建議。共享虛擬主機不一定支援安裝 Redis 或 Memcached，需要的話得先跟主機商確認方案等級允不允許，不是自己在 WordPress 後台就能開關的功能。
自動載入選項則是資料庫裡另一種狀況，指的是每次頁面載入時，都會被整批讀進記憶體的一批設定資料。這批資料如果累積過大，會拖慢每一次頁面請求的速度。WordPress 6.6 版加入了這項檢測，預設的判定門檻是 800,000 位元組，大約 800KB，總量超過這個門檻就會直接被判定為嚴重問題，這項測試只有良好與嚴重兩種狀態，沒有中間的建議改善。遇到這項警示，實際要處理的是找出哪些外掛在資料庫裡塞了過量的自動載入資料，而不是自己動手去修改資料庫內容。
六大類警示同時出現時，判斷優先順序看這幾個條件
網站健康頁面同時跳出好幾種警示是常態，排優先順序該看的是這項警示代表主動攻擊面、還是某個原本會自動運作的機制正在停擺，或者只是單純的維護債，而不是警示顯示的顏色或位置。
- 官方文件明確標記為資安類的嚴重問題，例如自動更新沒有真的生效、PHP 版本過舊，加上外掛有更新待安裝，這幾項牽涉的是主動攻擊面，原則上排最前面處理。
- 背景更新、迴圈請求、REST API 出錯、連不上 WordPress.org，這幾項共通點是某個原本會自動運作的機制正在失效。即使暫時沒看到具體影響，也代表網站已經有一部分自動化在停擺，拖得越久，越難回溯是哪個設定或哪次變更造成的，不建議放著不管。
- 除錯設定外洩到前台或寫進可公開存取的檔案，正式站不該留著這種設定，屬於一旦發現就該立刻關掉的低成本高風險項目，處理起來通常只是改一個設定值，沒有理由拖。
- 閒置外掛佈景主題、持久化物件快取、自動載入選項這類建議改善，可以排進固定的維護排程，例如每次要更新核心或外掛前，先看一眼這個頁面，不必當下立刻處理，但也不該放到無限期不管。
同一類警示，在不同網站上的急迫程度也可能不一樣，例如背景更新失效這件事，在幾乎沒人維護的網站上，會比每天都有人手動更新的網站更值得優先處理。實際的檢視習慣，不必等紅字自己跳出來才想到要處理，而是把例行更新前先看一眼這個頁面，當成固定的維護動作。
WordPress網站健康這個頁面的用意，從來不是要每個人都衝到滿版綠燈的完美狀態，而是幫你把心力放在真正牽動資安與穩定度的項目上。下次點開工具選單看到一排紅字，先分辨這是主動攻擊面、自動化機制停擺，還是可以排進維護排程的維護債，遠比把每一條都當成同一種緊急程度更實際。