《銀河系漫遊指南》（The Hitchhiker’s Guide to the Galaxy）封面上，唯一敢對讀者保證的兩個字是「別慌」（DON’T PANIC）。這句話拿來形容 WordPress 網站忽然白屏的當下，意外貼切：畫面沒有錯誤訊息、沒有紅字警告，只剩一片死白，滑鼠點哪裡都沒反應，直覺反應通常是慌，是不是被入侵了，資料庫是不是壞了，要不要立刻找人搶救。
多數時候，WordPress 白屏並不等於資料流失，而是 PHP 執行到一半遇到錯誤，直接中止顯示畫面的一種保護性反應，說白了是程式在自我防衛，不是網站被摧毀。真正麻煩的地方在於它不會告訴你原因，逼著你一項一項排除。這篇會先教你怎麼分辨眼前這個白屏屬於哪一種，再依外掛、主題、除錯模式、記憶體四個最常見的根因，一步一步收斂到真正的兇手，最後補一段連五個步驟都試過仍是空白時的緊急還原手段。
要先確定的不是急著改哪個檔案，而是先弄清楚現在後台還進不進得去。
白屏出現時，後台還進不進得去？
當網站畫面忽然變成空白，第一件該做的事不是找人，而是自己動手做一次簡單的分流。打開瀏覽器分別測試兩個網址：網站的前台首頁，以及網址列輸入「你的網域/wp-admin」進入後台登入頁。兩個都測完，結果會落在三種情況之一：前台跟後台一起白屏、只有前台白但後台登入頁正常、或是前台正常但一登入後台就白屏。這三種範圍決定了根因的方向不一樣，也決定了下面每一個步驟該從哪個入口著手。
更關鍵的岔路，是能不能登入 wp-admin。如果後台登入畫面能正常打開，帳號密碼也能送出去，代表你還有主控台可以用，底下每個步驟都能直接在後台介面操作；如果連登入頁都白屏，或是登入之後整片空白，就得換一條路，靠 FTP 連上主機，或是進主機商提供的控制台去動檔案。接下來每一個排查步驟，都會分別交代這兩種前提下該怎麼做。
在動手之前，先破除一個常見的誤解：白屏不等於網站被摧毀，資料也通常沒有不見。它的技術本質，是 PHP 程式執行到一半碰到無法處理的錯誤，直接中止繼續往下跑，畫面因此停在一片空白，這其實是一種保護性的行為，而不是資料庫損毀的證據。至於「是不是中毒被駭」這個疑慮，答案是白屏絕大多數時候是外掛、主題或伺服器環境的相容性問題，跟入侵沒有關係；但如果同時發現後台多出陌生的管理員帳號，或是網站被導向了完全不相關的網址，那就要往資安方向另外處理，不在這篇的排查範圍內。
步驟一：快取常常是禍首，看起來當機其實只是舊畫面
如果剛才的分流結果是後台一切正常，只有前台一片空白，快取通常是第一個該懷疑的對象。快速的判斷法是打開瀏覽器的無痕視窗，或換一台裝置重新開一次前台網址，如果無痕視窗顯示正常，問題多半出在快取，而不是網站程式本身壞掉。
要清的快取，分成三層：
- 瀏覽器快取：清除瀏覽紀錄，或用強制重新整理（Ctrl+F5）重新載入頁面。
- WordPress 快取外掛：多數快取外掛的後台設定頁都有一個「清除快取」按鈕，按下去就會把已經產生的靜態頁面全部作廢，之後重新產生一份新的。
- 主機或 CDN 端的快取：如果網站有掛 CDN，或主機商本身提供伺服器層級的加速快取，即使外掛的快取清乾淨了問題依然存在，就要另外登入主機控制台或 CDN 後台清一次。
三層都清完之後，回到前台網址重新整理確認畫面是否恢復。如果恢復了，這一步就結束；如果前台依然空白，代表問題不在快取，得往下一步排查外掛。
步驟二：外掛衝突最常見，停用之後才知道兇手是誰
外掛衝突是 WordPress 白屏最常見的成因，尤其是外掛剛更新完，或是同時裝了兩個功能重疊、彼此搶著改動同一個設定的外掛。排查的原則很單純，先把所有外掛都停用，確認網站恢復正常，再一個一個重新啟用，抓出真正讓網站又變白的那一個。
如果後台還能登入，直接進外掛頁面，把清單裡全部外掛一次性停用，回頭確認前台是否恢復。恢復之後，再逐一把外掛重新啟用，每啟用一個就重新整理一次前台頁面，一旦畫面又變白，剛剛啟用的那一個就是兇手。
如果後台連登入頁都進不去，就得換成 FTP 路徑。用 FileZilla 之類的工具連上主機，找到 wp-content/plugins 資料夾，把整個資料夾改名，例如加一個底線或後綴，WordPress 抓不到外掛資料夾就會自動當成沒有安裝任何外掛，前台通常會立刻恢復。確認前台正常之後，把資料夾名稱改回來，再進去逐一把裡面每個外掛的子資料夾改名，一次只改一個，改完就回前台檢查，抓到讓網站又變白的那個子資料夾，就是兇手所在。
找到問題外掛之後，有三條路可以選：回報給外掛開發者，說明遇到的錯誤內容，等對方修正；找一款功能相近的替代外掛換掉；或是先讓這個外掛保持停用狀態，等官方推出新版本再重新啟用。不建議直接刪除外掛本身，保留下來才有機會等到修正。
步驟三：主題出包也會讓網站變白，先換回預設版本測一次
外掛都排除之後，下一個該查的是目前使用中的佈景主題。做法跟外掛類似，先換成一款單純的官方預設主題，確認網站是否恢復，就能判斷問題是不是出在主題本身。
後台能登入的情況下，進外觀選單裡的佈景主題頁面，啟用一款 WordPress 官方的預設佈景主題，例如 Twenty Twenty-Five，啟用之後回前台檢查是否恢復。這款主題出問題的機率最低，適合當作排除法的對照組。
後台進不去的情況，一樣改用 FTP。連上主機找到 wp-content/themes 資料夾，把目前正在使用的主題資料夾整個改名，WordPress 偵測不到原本啟用的主題，就會自動切換成系統裡有的最新預設主題，前台照理說會恢復顯示。
比較麻煩的狀況是，如果 themes 資料夾裡剛好沒有安裝任何一款官方預設主題可以退回去，就得先去 WordPress.org 的官方佈景主題目錄下載一份免費的預設主題，用 FTP 把整個主題資料夾上傳到 wp-content/themes 底下，再回後台啟用，或是在改名原主題資料夾之前，先把新下載的這份放進去，讓 WordPress 有東西可以自動切換過去。
確認前台恢復之後，就能斷定問題出在主題，接下來聯絡主題開發者回報，或是考慮換一款維護比較穩定的主題。
步驟四：開啟除錯模式，才看得到白屏背後的真正錯誤
前面三個步驟都排除不了，或者你想直接定位是哪一個檔案出了問題，這時候該打開 WordPress 內建的除錯模式，讓白屏底下真正的錯誤訊息浮出來。
做法是用 FTP 或主機控制台的檔案管理員打開 wp-config.php，找到檔案裡 /* That's all, stop editing! Happy blogging. */ 這一行，在它的上方加入三行設定。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Code language: PHP (php)WP_DEBUG 負責打開整個除錯模式的開關；WP_DEBUG_LOG 讓 WordPress 把偵測到的錯誤全部寫進一個叫 debug.log 的檔案，存放路徑在 wp-content 資料夾底下；WP_DEBUG_DISPLAY 則決定要不要把錯誤訊息直接印在網頁畫面上。正式上線的網站建議只開 LOG、把 DISPLAY 設成 false，原因是把詳細的錯誤路徑跟程式碼片段直接攤在畫面上，等於把伺服器的內部結構秀給任何訪客看，是額外的資安風險。
打開之後重新整理一次出問題的頁面，再用 FTP 或文字編輯器打開 wp-content/debug.log，裡面通常會看到像 Fatal error、Parse error 或 Cannot redeclare 這類字眼開頭的訊息，後面接著出錯的檔案路徑跟行數。看到檔案路徑落在 wp-content/plugins 底下的某個資料夾裡，就知道兇手是哪個外掛；落在 wp-content/themes 底下，兇手就是主題；如果指向 wp-includes 或 wp-admin 這些 WordPress 核心資料夾，問題就比較可能出在核心檔案本身或版本不相容。
排查完成，不管有沒有找到答案，都要記得把 WP_DEBUG 改回 false。除錯模式長期開著會拖慢網站速度，也會讓 debug.log 越長越大，甚至造成前面提過的資安疑慮，用完就關是基本習慣。
步驟五：記憶體被吃光，網站一樣會變成一片空白
如果剛才打開的 debug.log 裡看到一句「Allowed memory size of X bytes exhausted」，代表這次白屏的根因不是外掛壞掉或主題出錯，而是 PHP 可以使用的記憶體被用光了。
WordPress 有兩個跟記憶體有關的常數可以在 wp-config.php 裡調整。WP_MEMORY_LIMIT 管的是網站一般運作，包含前台瀏覽時可以用的記憶體上限，單一網站預設是 40MB，多站點模式預設是 64MB；WP_MAX_MEMORY_LIMIT 管的是後台管理作業，像是匯入資料、更新外掛這類比較吃資源的操作，預設值拉高到 256MB。兩者分開設計的原因，是後台管理任務本來就比一般瀏覽需要更多記憶體。
define( 'WP_MEMORY_LIMIT', '128M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );Code language: PHP (php)不過這兩個常數只能在 PHP 本身允許的範圍內往上調，調不過主機端設定的天花板。PHP 官方手冊定義的 memory_limit，是單一次請求能分配到的記憶體上限，預設值是 128MB，多數主機控制台都有一個可以查看目前 PHP 設定的頁面，能看到目前配額是多少、還能不能繼續往上加。如果主機商的方案本身就卡在很低的額度，單靠改 wp-config.php 是沒有用的，得聯絡主機商調整方案或升級主機規格。
調高記憶體上限之後，如果白屏還是反覆出現，代表問題不是單純的容量不夠，而是某個外掛或某段程式碼本身異常地在吃記憶體，這時候該回頭做步驟二、步驟三的排查，把可疑的外掛或主題揪出來，而不是把記憶體上限無止盡往上調高。
五步都排查完仍是白屏，該怎麼緊急還原？
如果快取、外掛、主題、除錯模式跟記憶體五個步驟都做過一輪，網站還是打不開，還有幾個收尾的手段可以用。
WordPress 從 5.2 版開始內建了復原模式（Recovery Mode）。當網站發生致命錯誤，系統會自動寄一封信到管理員信箱，信裡附上一組專屬連結，點開之後不需要碰 FTP，就能直接在後台暫停造成錯誤的外掛或主題，拿回網站的控制權，登入後還會看到目前被暫停的外掛或主題清單，可以直接停用或退出復原模式。只要你的網站版本晚於 WordPress 5.2，這封信通常會比你自己一步步排查更快找到問題所在，收到信之後第一時間先去信箱裡找一下。
如果手上有定期備份，從備份還原是最直接的辦法，但還原前務必先對現在這個壞掉的狀態做一次備份。這聽起來多此一舉，但一旦還原過程中又出了別的問題，至少還留得住現在的檔案跟資料庫，不會連退路都沒有。
另外一個容易被忽略，卻常常一刪就能解決的根因，是自動更新中途被中斷，在網站根目錄留下一個叫 .maintenance 的檔案。這個檔案本來是 WordPress 更新時用來暫時切換成維護模式的機制，正常情況下更新完會自動刪除，但如果更新過程中網路斷線或逾時，它就會殘留下來，讓網站卡在維護模式，畫面因此變成白屏或維護提示。用 FTP 連進網站根目錄，找到 .maintenance 這個檔案直接刪掉，通常就能恢復。
如果上面每一種方法都試過，網站依然一片空白，問題多半已經不在 WordPress 本身，而是在主機端，比如伺服器資源被排擠、資料庫本身出狀況。這時候該做的是聯絡主機商，請對方提供 PHP error log 或伺服器資源使用記錄，讓真正懂伺服器環境的人去看，而不是繼續在自己這一端瞎找。
回到最初那句「別慌」，白屏看起來嚇人，但多數時候只是相容性問題，不是資料毀損，也不是網站被摧毀。只要照著分流的邏輯，先確認後台進不進得去，再依快取、外掛、主題、除錯模式、記憶體這五個步驟一項一項排查，通常十幾分鐘之內就能找到根因，把網站救回來。
與其每次都在網站真的變白之後才臨場排查，更值得養成的習慣，是把「更新前先在測試環境跑一次」跟「固定排程備份」變成例行公事。外掛跟主題的更新永遠有可能踩到雷，差別只在於下一次白屏出現時，你手上有沒有一份乾淨的備份可以退回去，又或者這次意外根本沒機會發生，因為你早在測試環境先擋下來了。