2026.11.15

WordPress 更新後卡在維護畫面？確認更新狀態再處理 .maintenance

WordPress 更新時可能顯示「Briefly unavailable for scheduled maintenance」。如果畫面持續存在，不要立刻刪檔或重新執行更新：先確認背景更新是否還在進行，以免訪客進入尚未完成的網站。

先確認範圍及更新狀態

記下更新類型、開始時間、站台網址與主機時區。檢查主機控制台、更新工具或伺服器日誌，確認沒有更新程序仍在執行；若由代管平台執行，請主機商查詢。若使用維護外掛或 CDN 自訂維護頁，畫面可能不是核心維護機制；應先辨認來源。

WordPress 核心在網站根目錄建立 .maintenance，其內容的 upgrading 時間用於判定維護狀態。官方程式文件指出超過十分鐘後核心通常不再顯示該維護模式；若仍顯示，需檢查時間、其他維護機制及回應來源，不應只根據檔案存在推論。

確認中斷後處理檔案

確認更新已停止並保留現有備份後，使用 SFTP 或主機檔案管理員進入包含 wp-admin 的正確網站根目錄，啟用顯示隱藏檔。記錄 .maintenance 的時間與權限，下載到受保護的位置，再依官方常見錯誤文件移除殘留檔案。若站台共用部署工具或檔案內容不明，先請管理者確認。不要刪除 wp-content、更新目錄或其他隱藏檔。

驗證與復原

重新載入首頁、登入頁及後台，測試至少一個關鍵交易或表單的安全測試流程。確認版本、更新紀錄及錯誤日誌，畫面消失並不代表更新成功。如果更新中斷，先檢查備份、相容性與失敗原因，再依原更新工具的流程處理；不要反覆重試。若出現嚴重錯誤，參考WordPress 復原模式，必要時依維護計畫還原完整備份。若確需重新進入維護狀態，使用原維護工具；不要把舊 .maintenance 檔當成可靠的維護開關。

範例：分辨核心維護與其他回應

在獲准的測試電腦，可先檢查公開網址的狀態和回應標頭。請把網址換成自己的網站；Windows PowerShell 使用 curl.exe 以免別名影響。

curl.exe -i https://www.example.com/

核心維護畫面通常回應 503；若收到 200、301 或其他狀態，先檢查實際回應內容、Location、代理與維護外掛，不能單靠狀態碼判定是哪一層產生。輸出可能包含內部標頭或 cookie，分享前遮蔽；不要在命令中加入登入憑證。不同快取節點可能回應不同，必要時由管理者核對原站日誌與代理紀錄。

檔案管理員內可先查看 .maintenance 的修改時間與包含的 upgrading 時間，與網站主機目前時間及更新紀錄對照；修改時間不是唯一依據。若時間持續更新或工具仍在執行，維持現狀並等待或詢問管理者；若核心記錄的時間早已過期而畫面仍在，應查維護外掛或代理，移除檔案未必有效。復原前確認備份涵蓋檔案及資料庫，且不會覆蓋更新期間新增的訂單或資料；若涉及交易站，先由管理者規劃資料復原點。