WordPress 後台出現 PHP 版本過舊的提示，或主機通知即將調整 PHP 版本時，很多網站擁有者會遇到同一個問題：到底該選哪個版本？切換後網站會不會壞掉？
PHP 版本會影響網站程式的執行。選擇時，要同時考慮版本是否仍受支援，以及網站目前使用的 WordPress、佈景主題、外掛和自訂程式能否正常運作。
升級前先確認環境與測試方式，升級後再實際檢查網站功能，比只看版本號更能判斷這次調整是否完成。
PHP 是什麼？和 WordPress 版本有什麼不同？
PHP 是一種程式語言，WordPress 的許多核心功能、佈景主題與外掛都使用它。訪客開啟網站或送出表單時，主機會執行相關程式，再把結果回傳給瀏覽器。
因此，WordPress 版本和 PHP 版本是兩件事：
| 項目 | 代表什麼 | 通常在哪裡管理 |
|---|---|---|
| WordPress 版本 | 網站系統本身的版本 | WordPress 後台更新頁面 |
| PHP 版本 | 主機執行 PHP 程式的環境版本 | 主機後台或由主機商管理 |
更新 WordPress，不代表 PHP 也會一起升級。反過來，切換 PHP 版本，也不會自動把網站裡的外掛或佈景主題更新成相容版本。
即使網站大多是文字與圖片，後台登入、頁面編輯、表單與其他動態功能仍可能依賴 PHP。
WordPress PHP 版本該怎麼選？
先看官方建議，再看網站的實際組合
截至 2026 年 10 月 1 日，WordPress 官方的主機環境建議為 PHP 8.3 或以上。
但這是 WordPress 的環境建議，不能單獨用來保證整個網站都相容。網站裡還可能有舊外掛、第三方 Elementor 元件、自訂佈景主題，以及以前加入的程式碼。
選定目標版本前，先查目前 WordPress 版本的 PHP 相容資料，再查重要外掛與佈景主題的系統需求及更新紀錄。特別是負責表單、付款、會員或其他核心服務的工具，要優先確認。
如果使用 Elementor 和 Elementor Pro，兩者的版本關係也要一起檢查。第三方 Elementor 擴充外掛則需要另外確認，不能因為 Elementor 本身符合需求，就認定所有擴充工具都沒問題。
最低需求不等於長期維護建議
有些工具仍標示可在較舊的 PHP 上執行，這只是最低需求，不代表該 PHP 版本仍有官方安全更新。
PHP 官方會區分「積極支援」、「僅安全修正」與「停止支援」。截至 2026 年 10 月 1 日，各版本狀態如下：
| PHP 版本 | 當時的官方支援狀態 | 官方安全支援截止日 |
|---|---|---|
| 8.2 | 僅安全修正 | 2026-12-31 |
| 8.3 | 僅安全修正 | 2027-12-31 |
| 8.4 | 積極支援 | 2028-12-31 |
| 8.5 | 積極支援 | 2029-12-31 |
「僅安全修正」仍屬官方支援期間，但已不在一般錯誤修正的積極支援階段。停止支援的版本則不再由 PHP 官方提供修正。
這張表用來判斷維護期限，不是所有網站都可以直接切換到表裡最高的版本。實際選擇仍要看 WordPress、外掛、佈景主題的相容性，以及主機提供的版本。
在相容與支援期限之間安排升級
如果網站正在使用仍受支援的版本，功能正常，也有明確的維護安排，可以先在測試環境評估較新的版本，再排定正式站調整時間。
如果已經使用停止支援的版本，則需要優先安排相容性整理與升級。舊外掛只能在舊 PHP 上運作時，也要評估更新、替換或修正程式，不能只靠長期保留舊環境處理。
選版本的原則是：仍受支援、符合網站各項工具的需求，並且通過實際功能測試。
目前的 PHP 版本在哪裡看？
WordPress 後台可從 工具 → 網站健康狀態 → 資訊 → 伺服器，查看網站目前執行的 PHP 版本。
主機後台則用來查看與調整設定。例如 SiteGround 可從 Site Tools → Devs → PHP Manager 查看；實際選項與名稱以當前介面為準。
如果主機提供自動管理 PHP 的模式，先確認目前是主機管理還是手動指定版本，並留意相關通知。不要只憑自己有沒有按過升級，判斷環境是否曾經變動。
切換後，再回到 WordPress 的伺服器資訊確認實際版本。若讀值和預期不同，請主機商協助檢查設定是否套用到正確網站，以及是否存在其他設定覆蓋。
升級前，先把測試與復原方式準備好
記錄目前環境與目標版本
先記下目前 PHP 版本、預計切換的版本，以及 WordPress、重要外掛和佈景主題的版本。確認主機後台能否切回原版本，也要知道出錯後由誰處理。
如果同一個主機帳號管理多個網站，先確認這次設定會影響哪些網站、子網域或測試站。不要把單一網站的測試結果直接套用到其他網站。
整理相容性，再分開執行變更
重要外掛長期沒有更新，或作者已明確表示不支援目標 PHP 版本時，先處理這些問題，再測試 PHP 升級。
如果需要更新 WordPress、外掛或佈景主題，先分批完成並確認功能正常，再切換 PHP。避免在同一次操作裡，同時更新多個工具又更換執行環境，讓出錯後難以判斷來源。
確認完整備份與復原入口
升級前保留近期的網站檔案與資料庫備份，確認備份完成，也確認自己有權限使用主機的復原功能。
PHP 版本屬於主機環境設定。還原網站檔案與資料庫，不一定會把 PHP 版本一起還原，因此要另外記錄原本設定及切回方式。
若網站持續收到訂單、表單或會員資料，還要考慮還原資料庫是否會覆蓋備份後新增的內容。
先在 Staging 測試目標版本
有 Staging 測試站時，先在測試環境切換到目標 PHP 版本，確認重要功能後，再安排正式站操作。
不熟悉測試站用途，可以先看〈WordPress Staging 是什麼？網站改版為什麼不要直接在正式站操作？〉。
測試前要確認 Staging 實際執行的是目標 PHP 版本。如果主機設定會讓正式站與測試站共用環境，就先請主機商確認能否隔離測試。
Staging 的測試也要留意對外動作，例如寄信、付款或第三方服務串接。使用測試資料與適當的測試模式，避免送出真實通知或建立真實交易。
升級後，首頁能打開還不夠
正式站切換後，先確認 WordPress 顯示的 PHP 版本已符合預期，再使用無痕視窗與管理員登入分別檢查。
有快取的網站，訪客可能仍看到先前生成的頁面。因此需要按網站實際使用的快取工具清除相關快取，再測試會執行程式的功能。
| 檢查範圍 | 實際要做的事 |
|---|---|
| 前台重要頁面 | 開啟首頁、服務頁與文章，檢查圖片、選單及桌機／手機版面 |
| 後台操作 | 登入、編輯並儲存測試內容，確認沒有儲存失敗或錯誤訊息 |
| Elementor | 開啟編輯器、載入預覽，並在測試頁儲存一次修改 |
| 表單 | 送出測試資料，確認成功訊息、紀錄及收件端都正常 |
| 網站特有功能 | 依實際功能測試搜尋、會員、預約或購物流程 |
| 背景工作 | 確認備份、排程或同步任務能在接下來的執行時間正常完成 |
不是每個網站都有表格裡的全部功能，依網站實際用途測試即可。但用來承接詢問或交易的功能，不要只看畫面，要完成一次實際流程。
也要查看升級後的錯誤紀錄。已存在的舊訊息和切換後新增的錯誤應分開判讀，不能看到紀錄裡有 PHP 字樣，就認定這次升級失敗。
切換後出現錯誤，先恢復功能，再找原因
如果切換後立即出現白畫面、重大錯誤或後台無法登入，先記下發生時間、操作內容與錯誤訊息。
若主機仍提供原本可正常運作的 PHP 版本，可以先從主機後台切回，再確認網站是否恢復。切回後恢復，是排查相容性的線索，但還不能單憑這點認定是哪個外掛造成的。
接著請維護人員依錯誤紀錄中的檔案、訊息與發生時間，檢查外掛、佈景主題、自訂程式或環境設定。可以在測試站逐項確認，修正後再重新測試目標版本。
如果紀錄出現 Warning 或 Deprecated，表示警告或某些寫法已被標示為將淘汰，不一定會立刻讓網站停止運作。Fatal error 則可能中斷該次請求。處理時要看完整訊息與實際影響，不是只看錯誤名稱。
網站暫時切回舊版本後，仍要完成後續處理。尤其原版本已停止支援時，回退只是恢復服務的過渡措施，需要安排修正或替換不相容的工具。
如果同時做過其他更新，或切回 PHP 後仍未恢復，再評估是否需要還原備份。還原資料庫前，要確認會不會覆蓋新收到的內容。
WordPress PHP 版本的選擇，會隨官方支援期限與網站工具更新而改變。把目前版本、相容性、備份、測試結果及復原方式記錄下來，下次收到升級通知時，就能更清楚地安排處理。