一場真正的心肺復甦，急救人員不會在病患倒下的當下先問「為什麼會倒」，而是先做兩件事：壓胸、給氧，讓生命徵象回來，診斷病因留到送醫之後再做。網站半夜掛掉時，多數人的反應剛好相反，一邊瘋狂重新整理頁面，一邊打開後台亂點，想同時弄清楚哪裡壞了、又要怎麼修好，結果兩件事都做不成，只剩下越來越慌的自己。
WordPress 更新後網站掛掉，是幾乎所有自己管理網站的人遲早會遇到一次的處境，外掛按下更新，重新整理頁面卻換來一片空白，或是一行看不懂的錯誤訊息。WordPress 目前是全球市占最高的網站系統，根據 W3Techs 的最新統計，全球約四成網站都建置在這套系統上，這也代表外掛更新出包不是少數人技術不好才會遇到，而是規模夠大之後遲早會撞上的機率問題。這篇要給的不是一長串修法讓你自己挑，而是一條先做什麼、再做什麼的搶救順序：先定位是哪個畫面、哪個外掛出的問題，再讓網站先恢復呼吸，接著判斷要修好還是降級，最後把預防的習慣補起來。
順序顛倒，越急就越亂。所有排查的起點，都是先看清楚你現在螢幕上看到的是哪一種畫面。
網站掛掉的當下，你看到的是哪一種畫面？
半夜爬起來看網站，螢幕上出現的畫面不會只有一種，看到哪一種，決定了你接下來該往哪個方向查。花三十秒先分清楚自己屬於哪一類，比每種修法都硬試一遍要快得多。
- 整頁空白，前台後台都進不去：瀏覽器打開什麼都沒有，連標誌、選單都跑不出來，通常代表某段程式碼讓伺服器直接中斷了整個回應。
- 畫面顯示「這個網站發生嚴重錯誤」的提示：這跟純白畫面不一樣，是 WordPress 5.2 版之後才有的正式錯誤畫面，代表系統有偵測到問題、也留了記錄，比什麼都看不到的白畫面好處理。
- 卡在「網站因排定維護而短暫無法使用」不動：這通常不是程式衝突，而是更新過程被打斷、沒有收尾乾淨，修法跟外掛衝突完全是兩回事。
- 後台能登入、前台打不開，或者反過來：代表問題只影響一部分功能，還沒整個癱瘓，通常比前面幾種好處理。
- 版面跑掉、樣式不見了但內容還在：文章、商品資料都還讀得到，只是外觀跑版，問題多半出在佈景主題或跟版面相關的外掛，而不是整個系統。
看到哪一種，決定了要先查外掛衝突，還是直接處理更新中斷、記憶體不足這類單純問題。這也是為什麼下一步要先搞懂，一個外掛更新，怎麼會連累整個網站一起出問題。
為什麼一個外掛更新，就能讓整個網站掛掉？
外掛跟 WordPress 核心，其實是同一個 PHP 執行環境一起跑出來的結果，不是各自獨立運作的兩個程式。這代表外掛的程式碼一旦出錯，受影響的不會只有它自己的功能，而是整個網站的程式全部跟著中斷，瀏覽器最後看到的空白畫面，就是伺服器判斷程式已經無法安全往下執行，乾脆停止輸出任何內容。會走到這一步，常見成因有幾種。
新版外掛用到的函式，需要比較新的 PHP 版本才能執行。如果主機的 PHP 版本沒跟著升級，程式碼一執行到那一行就會直接觸發嚴重錯誤，這是外掛更新後最常見讓網站掛掉的原因之一。
更新過程中網路突然中斷，或是主機處理逾時，會讓外掛的檔案只更新到一半，程式碼結構本身就不完整，伺服器讀到殘缺的檔案自然無法正常執行。
外掛之間，或外掛跟佈景主題彼此互搶同一個功能，例如兩支外掛剛好都想改寫同一段程式邏輯，平常各過各的相安無事，只要其中一個版本一換，原本勉強共存的寫法就會打架起來。
伺服器的記憶體被瞬間吃光，也是常見的一種，新版外掛功能變重，執行時需要的記憶體超過主機原本配置的上限，程式跑到一半就被系統強制中止，畫面同樣會停在空白。
但不管是哪一種原因，動手處理之前，其實有個更關鍵的判斷要先做，就是你打算花多少時間排查，值不值得。
是先排查，還是先還原備份？
排查跟還原備份，兩條路只能先選一條，選錯順序，原本半小時能處理完的事，常常會拖成一整天。判斷的依據不是感覺，而是幾個具體條件。
如果網站正在收單、收預約、收表單，每多一分鐘停機都是直接的營收損失。這種情況下，有乾淨的備份就先還原上線，把網站救回正常運作，原因留到之後再慢慢查。
一般網站或部落格沒有立即的收入壓力，能承受二十到三十分鐘的排查時間，這種情況就照下面的步驟一步步定位問題，不急著跳過。
排查已經超過三十分鐘還是毫無頭緒，或是過程中發現資料庫的內容本身看起來已經被動過，這時候就該直接轉向還原備份，不要再繼續硬排查下去，這種情況多耗的時間，通常換不回等值的答案。
先還原不代表這件事就結束了。備份救回來的只是暫時恢復正常，更新造成問題的根本原因還沒解決，之後仍然要照後面找出兇手的方法，在測試環境裡把問題找出來，不然同一個更新，下次還是會用同樣的方式讓網站再掛一次。
決定要排查的話，第一步不是急著開 FTP 亂翻檔案，而是先做一件成本更低的事，打開信箱看看。
第一招：先檢查 WordPress 有沒有寄復原信給你
多數人一遇到網站掛掉就直接開 FTP 翻檔案。其實 WordPress 從 5.2 版開始，內建一套完全不用碰程式碼的自救機制，很多人根本不知道它存在，這也是本篇要優先講的原因，它成本最低，而且十之八九能一次到位。
系統偵測到嚴重錯誤時，會自動寄一封信到後台設定的管理員信箱，主旨類似「你的網站發生技術問題」。信件裡附了一個復原模式的登入連結，就算網站前台已經完全打不開，這個連結仍然能讓你安全登入後台，不需要額外密碼或其他驗證步驟。
登入復原模式之後，後台上方會直接標示出是哪一個外掛、或哪一個佈景主題無法正常載入，不用自己一個個排除去猜。照畫面指示把被標記的外掛停用，如果是佈景主題出問題就切換回另一個，重新整理前台確認網站恢復正常，再退出復原模式即可，整個過程通常幾分鐘內能完成。
如果信箱裡完全找不到這封信，先檢查垃圾信件匣，再確認後台設定的管理員信箱是不是還有效，有些網站換過負責人，信箱早就沒人在看了。如果連寄信功能本身都跟著掛掉，收不到任何通知，才需要進到下一招，直接用 FTP 找出問題所在。
第二招：登不進去後台，用 FTP 揪出真正的兇手外掛
沒收到復原信，或者後台也整個打不開，代表要換一套更直接的方法，透過 FTP 連進主機，自己找出真正出問題的外掛。整個流程分成三步，先開偵錯模式讓系統直接點名出錯的檔案，如果還是看不出頭緒，就整批停用外掛確認方向對不對，最後再一個個叫回來，抓到真正讓網站掛掉的那一支。動手之前有一件事一定要先做，把現在的狀態備份起來，哪怕只是把整個 wp-content 資料夾下載一份存著也好。改資料夾名稱這個動作本身不會動到資料庫或任何內容資料，純粹只是讓 WordPress 暫時讀不到那個資料夾而已。
開偵錯模式，讓 PHP 直接點名出錯的檔案
比用猜的準確得多的做法，是打開 WordPress 內建的偵錯模式，讓 PHP 自己把哪個檔案、第幾行出錯直接寫下來。用 FTP 或主機提供的檔案管理員連進網站，打開根目錄下的 wp-config.php，找到「就是這樣，不能再編輯了！」這行，在它前面加入三行設定：
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Code language: PHP (php)這三行的作用分別是啟用偵錯功能、把錯誤內容寫進記錄檔、但不讓錯誤訊息直接顯示在畫面上讓訪客看到。存檔之後重新整理網站一次，回頭到 wp-content 資料夾底下找，通常會看到一個剛剛才新出現的記錄檔。打開它看最後幾行，只要出現「Fatal error」字樣，後面接著的檔案路徑就會直接指出是哪一個外掛的資料夾出的問題，不用再一個個排除去猜。確認完之後記得把偵錯模式關掉，把上面那幾行改回 false 或整段刪除，避免錯誤訊息長期暴露在網站上被其他人看到。
把外掛資料夾整批改名，先確認是不是外掛的問題
如果記錄檔看不出頭緒，或只是想先確認問題的方向對不對，還有一個更粗暴，但也最有效的做法，讓 WordPress 完全找不到外掛資料夾，逼所有外掛一次自動停用。做法是連上 FTP 或主機的檔案管理員，找到 wp-content 底下的 plugins 資料夾，把整個資料夾改成別的名字，名字本身不重要，只要不再叫 plugins 就行。改完用無痕視窗重新整理網站一次，如果畫面恢復正常，代表問題確實出在某個外掛身上；如果還是掛著沒反應，代表問題不在外掛，接下來要往佈景主題或其他方向查。這個動作只是讓所有外掛暫時停用，不會刪除任何資料、設定或內容，把資料夾名稱改回來，外掛的所有設定都還完整保留在原地，不用擔心資料流失。
一個個重新啟用，找出真正讓網站掛掉的那個
確認問題出在外掛之後，下一步是把範圍縮小到只剩哪一支，而不是讓二十支外掛全部停在停用狀態不管。先把 plugins 資料夾的名稱改回來，這時候後台的已安裝外掛列表會重新看到所有外掛，但每一支都會顯示成停用狀態，並不會自動全部啟用。接下來從後台一個一個手動啟用，每啟用一支就重新整理一次前台檢查，啟用到哪一支外掛時網站又掛掉，那一支就是真正的兇手，先讓它維持在停用狀態就好。如果前面從記錄檔已經知道兇手是誰，這一整套整批停用的流程都可以省略，直接在 plugins 資料夾裡只改名那一支外掛的子資料夾，會更省時間。
抓到兇手後，先讓網站恢復上線
找到問題出在哪個外掛，或哪個佈景主題之後，第一件要做的事，不是急著把那個外掛修好，而是先讓網站恢復上線。這也是這整套搶救順序裡最重要的一條原則，先穩定，治療是之後的事。如果問題外掛停用之後不影響核心功能運作，維持停用狀態、確認前台恢復正常即可，之後再慢慢決定要修好還是換掉。如果問題出在佈景主題，記錄檔裡的路徑指向 wp-content/themes 底下的檔案，用同樣的改名方式，讓 WordPress 自動切換回內建的預設佈景主題，網站外觀會變得很陽春，但至少能先正常運作，不至於整站空白。
除了外掛跟佈景主題衝突，還有兩個常讓人卡住的岔路，不一定跟這次的更新衝突有關，但常常剛好在更新過程裡一起發生。
卡在「維護中」畫面動彈不得，怎麼辦
網站卡在「網站因排定維護而短暫無法使用」不動，代表的是更新程序本身被中斷、沒有正常收尾，通常是網路斷線或主機處理逾時造成的，跟外掛彼此衝突是完全不同的兩回事，修法也單純很多。用 FTP 或主機的檔案管理員連到網站根目錄，找一個檔名開頭有一個點的暫存檔案，直接把它刪掉，再用無痕視窗重新整理網站，通常立刻就會恢復正常。刪除之前建議先確認一下更新是不是已經真的完成，到外掛列表看一下版本號有沒有成功更新到最新版，避免刪掉暫存檔之後，一個沒真正更新完成的外掛繼續留著問題。
記憶體不夠，同樣會造成白畫面
另一個常被忽略的成因，是伺服器的記憶體不夠用，外掛更新後功能變重，執行時需要的記憶體超過主機原本設定的上限，程式跑到一半就被迫中止，畫面同樣會停在空白。這種情況下，前面提到的記錄檔裡通常會出現「記憶體用盡」相關的字樣，可以用來確認是不是這個原因。解法是在 wp-config.php 裡加入一行：
define('WP_MEMORY_LIMIT', '256M');Code language: PHP (php)把 WordPress 可用的記憶體上限調高。如果調高之後問題依然存在，代表主機方案本身配置的記憶體上限太低，這需要聯絡主機商協助調整，不是單靠網站端的設定能解決的問題。如果記憶體吃緊的狀況三不五時就發生一次，代表網站的規模其實已經超過原本購買的主機方案，這是該長期檢討升級主機規格的訊號，不只是這次事件當下的止血動作而已。
外掛還要用，該怎麼降回舊版本？
找到兇手外掛之後，如果這支外掛的功能還需要用、沒辦法直接刪掉換別支，這一節要處理的是怎麼把它退回上一個還能正常運作的版本。第一步是先到這支外掛在 WordPress.org 上的頁面查看更新紀錄，確認新版本改了什麼、有沒有寫明需要更高的 PHP 版本才能執行，這能幫你判斷降版本是不是真的解得了問題。
如果外掛是從 WordPress.org 官方目錄安裝的，最簡單的做法是安裝一支叫 WP Rollback 的免費外掛，它是 WordPress.org 官方收錄的版本回溯工具。裝好之後，在已安裝外掛頁面就會出現一個「安裝指定版本」的連結，點進去選回更新之前的版本號、確認執行，幾十秒內就能完成整個回溯，不用碰任何程式碼。
如果外掛是付費的、來源不是 WordPress.org，例如直接向外掛開發商的官網購買，這支免費的版本回溯外掛就不適用了。這種情況要回到開發商網站的會員後台，下載前一個版本的安裝檔，再用後台的「上傳外掛」功能手動安裝，取代掉目前有問題的版本。
不管走哪一條路，降版本前都一定要先備份現況，而且降版本只是暫時止血，不是長期的解法，舊版本很可能存在已經被發現的安全性問題，長期還是要等開發商推出修好這次問題的新版本再升級回去，不能就這樣永遠停在舊版本上不動。如果降版本之後網站確實恢復正常，代表問題真的是這次更新造成的，這時可以考慮到這支外掛在 WordPress.org 的支援論壇留言回報這個狀況，或是先觀望，等官方釋出下一個修正版本再更新。
這些方法都試過，該直接還原備份了
上面的排查跟降版本都試過，問題還是沒解決，或是排查途中發現資料本身已經被動過，這時候該做的不是繼續硬排查，而是果斷轉向還原備份。判斷依據很清楚，內容本身消失或看起來已經損毀，不只是前台顯示不出來，連後台的編輯畫面裡都看不到內容；或是排查時間已經遠遠超過合理範圍卻毫無頭緒。這兩種情況下，直接還原備份都是最划算的選擇。
還原備份實際上在做的事，是把網站的檔案跟資料庫，一起換回更新之前那個時間點的狀態。這代表更新造成的問題，會連同更新這個動作本身一起被抹掉，網站恢復正常了，但根本原因並沒有被解決，之後還是得在測試環境裡重新嘗試一次那個更新，才能真的把問題找出來、修好。
如果同樣的問題連續發生好幾次，或是懷疑問題出在主機環境本身的變動，例如主機商自行調整了伺服器的 PHP 版本，這種情況該聯絡的是主機商，已經超出外掛開發商能處理的範圍。如果是自己手動管理備份，操作上要先把資料庫檔案匯入回去，再把網站檔案覆蓋回去，而且兩者一定要對應同一個備份時間點，檔案版本跟資料庫版本對不上，反而會造成新的錯亂，比原本的問題還難處理。
下次更新前，先把這幾件事做好
這次的搶救結束之後，值得花點時間把它轉成往後的習慣，而不是等下次半夜再重演一次同樣的驚魂。
更新之前一定要先手動觸發一次備份，就算主機商每天都有自動備份，多存一份自己觸發的備份，能確保時間點剛好卡在更新前的那一刻，還原起來更精準。有能力的話，先在測試環境，也就是一個跟正式站分開的複本網站，跑過一次同樣的更新，確認沒問題再更新到正式站，多數主機商的方案其實都有一鍵建立測試環境的功能，只是很少人用過。外掛也別一次全部按下更新，改成一支一支更新，每更新完一支就重新整理網站確認一次，一旦出事能馬上知道是哪一支造成的，不用事後從一堆更新紀錄裡大海撈針。遇到比較重大的版本更新，更新前可以先到這支外掛在 WordPress.org 的支援論壇，看看最近兩三天有沒有其他人也在回報網站掛掉、白畫面這類討論，如果剛好碰上其他人也在抱怨同一件事，先緩一天，等官方推出修正版再更新，通常比急著更新划算。
心肺復甦救的是當下這一條命，真正的病根還是要回到醫院，好好做檢查、對症治療。網站也是一樣的邏輯，這次的搶救讓網站先恢復了呼吸，重新正常上線，但事後有沒有把手動備份、測試環境、一支一支更新這幾個習慣落實下去，才是決定半夜爬起來搶救網站這件事會不會再發生一次的關鍵。