「這個網站發生嚴重錯誤」是什麼意思，又該怎麼修

這句訊息代表 PHP 在組建頁面時遇到了嚴重錯誤，而 WordPress 在它變成一片空白之前先攔了下來。錯誤是真實存在、內容具體、而且有被記錄下來的 —— WordPress 只是拒絕把它印在瀏覽器上，因為在公開頁面上顯示堆疊追蹤，等於把檔案路徑和程式碼洩漏給每一個來訪的人。

所以修這個問題從來不需要猜。順序是：先讀出真正的錯誤，再照它說的去做。

實際上發生了什麼事

自 WordPress 5.2 起，核心內建了一個嚴重錯誤處理器。當 PHP 在請求中途死掉，處理器會介入，把崩潰的輸出換成那句客氣的通用訊息，並且 —— 如果它能判斷出是哪個外掛或佈景主題造成的 —— 試著寄一封含有復原模式連結的信給網站管理員。

這就是為什麼你現在看到的是這句話，而不是以前的白屏死機。這是進步，但也代表診斷資訊預設被藏起來了。這句訊息有兩種版本：

你看到的內容	出現位置	它告訴你什麼
「這個網站發生嚴重錯誤。」	前台，未登入狀態	發生了嚴重錯誤，沒有進一步細節
同一句話再加上「進一步了解如何為 WordPress 進行疑難排解」	前台或 wp-admin	同樣的錯誤，WordPress 順便給你官方手冊頁面
「…請檢查網站管理員信箱以取得說明。」	前台	處理器認為它已經寄出復原模式郵件

第三種才是最有用的。它代表 WordPress 已經把崩潰歸咎到某個特定的外掛或佈景主題，並且試著給你一條進去的路。

步驟一：檢查復原模式郵件

WordPress 會把復原連結寄到網站管理員信箱，也就是「設定 → 一般」裡的那一個 —— 那通常不是你登入時用的信箱。去那個信箱找，也記得看垃圾郵件匣。

信裡有一條很長的連結，結尾類似 ?action=enter_recovery_mode。打開它會讓你以復原模式登入 wp-admin，闖禍的外掛或佈景主題會被暫停，並在頁面頂端以紅色提示標示出來。從那裡你就可以正常停用它。

有兩件事必須老實說。第一，這封信是由剛剛才崩潰的同一個 PHP 程序產生的，而主機本身可能根本沒有可用的郵件傳輸設定 —— 寄不出去是常態，信沒來完全不代表錯誤的性質。第二，復原連結會過期（預設大約一天），所以信箱裡那封舊信可能單純是失效了；重新載入網站觸發一次新的崩潰，等新的信寄來。

如果你希望這封信寄到你真的會看的地方，就在 wp-config.php 裡明確指定：

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

步驟二：讀出真正的錯誤

這一步能把一個壞掉的網站變成五分鐘就能解決的小事。在 wp-config.php 裡、那行叫你別再往下編輯的註解上方，加入這幾行：

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

把 WP_DEBUG_DISPLAY 設為 false 很重要 —— 它讓錯誤不出現在瀏覽器上，同時仍然寫進磁碟，這樣你在除錯的時候就不會把路徑攤給訪客看。

重新載入一次故障的頁面，然後打開 wp-content/debug.log。最後一筆紀錄大概長這樣：

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

檔案路徑就是答案。如果它指向 wp-content/plugins/，那個外掛就是原因。如果它指向 wp-content/themes/，那就是佈景主題 —— 很多時候是最近才貼進 functions.php 的某段程式碼。

如果 debug.log 沒有出現，可能是該目錄沒有寫入權限，或是某個安全外掛把記錄位置改到別的地方了。這時改看主機的 PHP 錯誤記錄檔 —— 大多數控制台都有「錯誤記錄」或「記錄檔」的區塊，同一筆嚴重錯誤會帶著時間戳記出現在那裡。

把那筆紀錄貼進 WordPress 錯誤記錄解讀工具，它會把 PHP 的用詞翻成實務上的意思，並告訴你該先看哪個檔案。

做完之後請把這些除錯設定刪掉。 在正式站上一直開著 WP_DEBUG 會把磁碟塞爆，而且萬一 WP_DEBUG_DISPLAY 哪天被翻回來，伺服器路徑就會被公開印出來。

步驟三：重新進入 wp-admin

如果 wp-admin 也掛了、復原郵件又沒來，那就直接從檔案系統層級停用所有外掛。用 SFTP（或主機的檔案管理員）連上去，把一個資料夾改名：

mv wp-content/plugins wp-content/plugins-off

WordPress 找不到外掛，就會把它們全部停用，後台幾乎一定能回來。接著：

1. 把資料夾名稱改回 plugins。所有外掛仍然是停用狀態 —— WordPress 已經把它們記錄成未啟用。
2. 一次啟用一個外掛，每啟用一個就載入一次前台。
3. 讓錯誤重新出現的那一個，就是元凶。

如果所有外掛都關掉了網站還是壞的，那嫌疑就落在佈景主題上。把 wp-content/themes/ 裡使用中佈景主題的資料夾改名，只要有安裝預設佈景主題，WordPress 就會自動退回去用它。

三個值得認識的原因

外掛或佈景主題更新後 fatal。 這是最常見的，沒有之一。記錄檔會直接指名檔案。把那個外掛降回上一個版本，或是先讓它停用著，然後把那行記錄貼給開發者。

PHP 版本不相容。 主機會照排程升級 PHP，有時候幾乎沒有事先通知。為舊版 PHP 寫的程式碼，在新版上可能連剖析都過不了。判斷的線索是：你這邊什麼都沒動，卻整個一起壞掉。在主機控制台把 PHP 降一個小版本是合理的診斷手段 —— 但把它當成爭取時間，不是修好了。舊版 PHP 不再收到安全性修補。

記憶體耗盡。 記錄檔會寫「Allowed memory size of X bytes exhausted」。在 wp-config.php 裡把上限拉高是合理的做法：

define( 'WP_MEMORY_LIMIT', '256M' );

但要誠實看待它的作用：這只是把天花板拿掉，並沒有解決「渲染一個頁面竟然吃掉 256MB」這件事。如果這個上限一直得往上調，那真正的問題另有其人 —— 通常是某個匯入作業、頁面編輯器，或是一段寫得很糟的查詢。

可以安心忽略的建議

「把記憶體上限調高就好。」 只有在記錄檔真的寫了記憶體耗盡時才適用。否則它什麼都不會改變，只會掩蓋你從頭到尾沒讀過錯誤這件事。

「重新安裝 WordPress 核心。」 核心檔案很少是原因，而換掉它們浪費掉的時間，本來足夠你讀完那一行記錄。

「把嚴重錯誤處理器關掉。」 確實有一個常數可以停用它，結果就是原始錯誤會被直接印在你的公開網站上，而不是被攔下來。那等於把檔案路徑攤給訪客看。改用 WP_DEBUG_LOG 搭配關閉的 WP_DEBUG_DISPLAY —— 一樣的資訊，沒有外洩。

「清一下快取。」 嚴重錯誤發生在 PHP 裡，在快取外掛能送出任何東西之前就已經結束了。如果目前被送出的是錯誤頁的快取副本，清快取是在你修好原因之後才有幫助 —— 絕對不是拿來取代修復。

還是卡住？

如果記錄檔指向的是核心檔案而不是 wp-content 裡的東西，比較可能的解釋是：某個更早載入的外掛破壞了核心所依賴的狀態，而不是核心檔案損毀。用改資料夾名稱的方式把所有東西關掉，確認網站能乾淨載入，然後一個一個把外掛加回來 —— 錯誤重現前你啟用的最後那一個，就是該回報的對象，記得附上那行記錄。