網站前一刻明明還好好的，重新整理一次，畫面卻只剩下一片空白，或是跳出一行看不懂的英文錯誤訊息，連後台都登入不進去。眼前這片空白什麼都沒說，沒有紅色警示，也沒有一句話解釋是哪裡壞了，只留下一個像世界末日的畫面，讓人猜不出是外掛出狀況、主機資源不夠，還是自己剛剛哪個設定按錯了。
這種狀況多半就是 WordPress 500 錯誤，正式名稱叫 500 Internal Server Error，意思是伺服器在處理這次請求時發生了未預期的錯誤，卻沒有義務說明原因究竟是什麼。它不挑網站規模，小型部落格和大型購物網站都可能發生，而且往往一發生就是整站癱瘓，訪客進不來，後台也可能一起打不開。拖得越久，流失的不只是這幾分鐘的流量，還可能牽動搜尋引擎往後怎麼看待這個網站。
好消息是，多數 500 錯誤都逃不出幾個固定的環節，只要照順序一項一項排查，通常不必真的動用工程師就能自己解決。接下來就先從分辨問題出在哪裡開始，一路排查到真的得找主機商求助的那一步，排到自己對應的那一關就可以先停下來動手，不必整套流程都跑完。
WordPress 500 錯誤是什麼？和白畫面死機是同一回事嗎？
很多人看到瀏覽器跳出一整頁 500 錯誤代碼，和看到單純一片空白的頁面，會以為是兩種不同等級的災情。其實兩者的根本原因，往往一模一樣。
500 Internal Server Error 是一種 HTTP 狀態碼，用來告訴瀏覽器伺服器在處理這次請求的過程中出了問題，但它只負責回報有錯，不負責說明錯在哪裡。這跟 404（找不到頁面）不同，404 明確知道問題出在網址；500 則是伺服器端自己都還沒搞清楚狀況就先中斷了，所以畫面上常常只剩一行 500 Internal Server Error，或是乾脆什麼都沒有。
至於白畫面死機（White Screen of Death），本質上跟 500 錯誤是同一回事，都是 PHP 程式碼在執行到一半時掛掉，沒辦法把完整的頁面內容送到瀏覽器手上。差別只在於瀏覽器與伺服器的設定不同，呈現方式跟著不同，有的伺服器設定會顯示完整的 500 錯誤頁面，有的則因為 PHP 沒有把錯誤訊息輸出出來，最後只留下一片空白。看到的是一整頁英文錯誤，還是純白畫面，差的是表現形式，不是壞掉的原因。
WordPress 從 5.2 版開始內建一套嚴重錯誤保護機制，讓這種情況不再只能對著空白頁面猜半天。一旦偵測到嚴重的 PHP 錯誤，前台訪客看到的不會再是一片空白，而是一句這個網站發生技術問題的友善提示；同一時間，系統會自動寄一封通知信到網站管理員的信箱，信裡附一組復原模式（Recovery Mode）的專屬連結，點進去就能在有問題的外掛或佈景主題先被暫停的狀態下登入後台，直接找出問題所在再處理，不必透過 FTP 或直接改程式碼才能挽救。
500 之外，還有 502、503、504 這幾個同樣以 5 開頭的狀態碼，同屬伺服器端的錯誤家族，但成因並不相同，502 多半跟閘道器或反向代理的溝通有關，503、504 則常與伺服器暫時無法回應或逾時有關。這幾個代碼的排查方式跟 500 不完全一樣，這裡先不展開，把焦點留在最常見的 500。
500 錯誤通常卡在這四個環節
進入逐一排查之前，先看一張大地圖比較有效率。500 錯誤九成以上逃不出四個環節：.htaccess 檔案的設定壞掉、PHP 記憶體被吃光、外掛或佈景主題彼此衝突，以及主機資源或環境設定本身出狀況（權限跑掉、PHP 版本不相容、伺服器負載過高）。
這四個環節不是憑感覺亂猜，通常從什麼時候開始出現就能抓到大概方向。剛裝好一個新外掛或剛按完更新就出現，多半是外掛衝突或記憶體不夠用；改了固定連結設定、或裝了快取類外掛之後才發生，方向通常是 .htaccess；平常都正常運作，只有流量突然衝高那幾天才出狀況，問題多半出在主機資源。心裡先有這張對照表，接下來排查就不必從第一項試到最後一項。
怎麼判斷問題出在自己這邊，還是主機那邊？
在動手改任何設定之前，還有一個更省時間的做法，先確認這個 500 錯誤是全世界都打不開，還是只有自己這台裝置連不上。做法很簡單，換一支手機、切到行動網路（不要用 Wi-Fi）打開同一個網址，或是把網址丟進線上的網站存活檢測服務看看結果。如果別的裝置、別的網路都能正常打開，問題多半出在自己這端的瀏覽器快取或 DNS 快取，先清一次瀏覽器快取再重新整理看看，說不定根本不用進到後面的排查。確認過真的是伺服器端出問題，才進入下面六個修法，一項一項來。
500 錯誤沒有馬上處理，會有什麼後果？
網站打不開的這段時間，損失的不只是當下畫面。任何在這幾分鐘裡想進站的人，不管是想找聯絡方式的潛在客戶，還是準備結帳的買家，多半會直接放棄轉頭離開，而且未必會記得晚點再回來試一次。
更關鍵的是搜尋引擎那一端的反應。Google Search Central 的官方文件提到，如果伺服器真的暫時過載到沒辦法正常回應，建議回傳 503 或 429 這兩種狀態碼，讓 Googlebot 知道先別急著放棄，過一陣子再回來試，通常會耐心重試大約兩天。但同一份文件也講得很清楚，這種暫時不可用的狀態如果拖過兩天，Google 就會開始永久調降這些網址的抓取頻率，再拖下去甚至會直接把受影響的網址從索引中移除。500 錯誤雖然是不同的狀態碼，但對搜尋引擎來說，傳達的訊號同樣是伺服器沒能正常把內容交出來，擺著不處理，承受的風險也是同一套邏輯。
那只當機個幾分鐘，會不會已經傷到排名？通常不會，Google 之後重新抓取一次，發現網站恢復正常，多半不會有太大影響。真正該緊張的是放著不管、一拖就是好幾天的情況，那才是排名回不去的風險所在。
修法一：重新產生 .htaccess 檔案，多數 500 錯誤到這步就解決
四個環節裡，.htaccess 壞掉是機率最高、也最容易排除的一種，值得從這裡先下手。「.htaccess」是 Apache 伺服器用來處理固定連結、網址重新導向的設定檔，聽起來冷門，卻是整個網站能不能正常顯示文章頁面的關鍵。快取外掛、安全性外掛特別喜歡在安裝或設定時自動改寫這個檔案，一旦寫進去的語法有錯，輕則某些頁面連不上，重則整站直接跳出 500 錯誤。
第一步是先確認問題是不是出在這裡，做法是用 FTP 軟體或主機控制台附的檔案管理員，找到網站根目錄下的 .htaccess，把它改名成 .htaccess_old 這種暫時不會被讀取的名字，重新整理網站看看有沒有恢復。如果恢復了，代表兇手就是它，而且可以先鬆一口氣，因為接下來要做的事很單純。
恢復正常之後，不需要手動重寫內容，回到 WordPress 後台的「設定→固定連結」頁面，什麼都不改，直接按一次「儲存變更」，WordPress 就會自動重新產生一份乾淨的 .htaccess。這是最推薦的做法，因為產生出來的內容一定跟目前的固定連結設定吻合。
萬一連後台都進不去，沒辦法用上面這個方法，就只能靠 FTP 手動建立一個新的 .htaccess 檔案，把 WordPress 預設的重寫規則貼進去：
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressCode language: plaintext (plaintext)貼上存檔後，先用最基本的固定連結格式測試網站能不能開；能開的話再回到後台把固定連結設定重新儲存一次，讓規則跟目前的設定完全對齊。
修法二：拉高 PHP 記憶體限制，讓耗資源的外掛跑得完
.htaccess 沒問題，下一個該懷疑的是記憶體。記憶體被吃光的過程其實很單純，一個頁面在載入時，同時要跑好幾個外掛的程式碼，加上主題本身的運算，PHP 配到的記憶體用完了卻還沒跑完整個流程，伺服器只能強制中斷，回傳 500 錯誤收場。外掛裝得多、有安裝 WooCommerce 這類本身就吃資源的購物外掛，或是正在匯入大量商品、會員資料的時候，特別容易踩到這個上限。
拉高 PHP 記憶體限制有三種做法，擇一使用就好，不必三個一起做。第一種是改 wp-config.php，在檔案裡加一行：
define('WP_MEMORY_LIMIT', '256M');Code language: PHP (php)如果錯誤發生在後台管理畫面，可以另外再加一行拉高後台專用的上限：
define('WP_MAX_MEMORY_LIMIT', '512M');Code language: PHP (php)第二種是直接改 php.ini，這個做法需要主機有開放完整的設定權限，或本身是用 VPS 這類可以自己管理伺服器的環境：
memory_limit = 256MCode language: plaintext (plaintext)第三種則是回到 .htaccess 加一行對應設定：
php_value memory_limit 256MCode language: plaintext (plaintext)不過拉高記憶體限制只是治標，如果調高之後過一陣子又發生同樣的 500 錯誤，代表真正的問題是某個外掛本身耗用記憶體異常，該做的是回頭找出是哪一個外掛在吃資源，而不是把數字一路往上加，加到最後主機根本負荷不了。
修法三：停用外掛逐一排查，揪出真正衝突的那一個
如果記憶體也沒問題，接下來輪到外掛登場。外掛之間彼此衝突，是 500 錯誤裡數一數二常見的原因，尤其是剛升級 PHP 版本，或剛把 WordPress 核心更新到新版之後，原本相安無事的外掛組合突然就對不上了。
如果還能登入後台，排查方式很直接，先到「外掛」頁面把全部外掛一次停用，確認網站恢復正常之後，再一個一個重新啟用，每啟用一個就重新整理一次網站，直到 500 錯誤再度出現，出現的那一刻，剛剛啟用的那個外掛就是兇手。
進不了後台的話，得靠 FTP。到 wp-content/plugins 資料夾，把整個 plugins 資料夾改名（例如改成 plugins-old），WordPress 會因為找不到這個資料夾，自動把所有外掛都視為停用狀態，網站通常就能恢復。確認恢復後，先把資料夾名稱改回 plugins，再逐一進到裡面，把單一外掛的子資料夾一個個改名測試，同樣是改一個、測一次，找到讓網站再度出現 500 錯誤的那一個資料夾，就是問題所在。
幾種類型的外掛特別容易惹禍：頁面快取外掛的設定跟其他外掛衝突、安全性外掛的防火牆規則設得太嚴格、連正常的請求都一併擋下，還有太久沒更新、跟不上新版 PHP 語法的老外掛。找到兇手之後，能更新的先更新，更新不了的就得考慮換一個功能類似的外掛。
修法四：切換回預設佈景主題，排除主題本身的問題
外掛都測過一輪還是沒找到兇手，下一個該檢查的是佈景主題。尤其是自己動過 functions.php，或是用了很久、作者早就不再更新的舊主題，升級 PHP 版本或 WordPress 核心之後，特別容易顯現出相容性問題。
能登入後台的話，直接到「外觀→佈景主題」，啟用一款隨 WordPress 內建、版本較新的官方預設主題（例如 Twenty Twenty-Four 這類），確認網站是否恢復正常。
進不了後台，就要透過主機提供的 phpMyAdmin 連進資料庫。在 wp_options 這張資料表裡，找到 template 與 stylesheet 這兩個欄位，它們記錄的正是目前啟用中的佈景主題資料夾名稱，把兩個欄位的值都改成想切換的預設主題資料夾名稱（例如 twentytwentyfour），存檔後重新整理網站確認。
如果切換主題之後問題真的消失，代表確實是主題造成的，而且如果原本有動過主題檔案自己客製化過，之後應該改用子主題來保留這些客製內容，不要繼續直接改父主題的檔案，不然主題只要一更新，自己加的東西就會被覆蓋掉，等於白費工夫。
修法五：檢查主機資源、檔案權限與 PHP 版本相容性
前面四個環節都排除，問題還在，通常代表原因不在 WordPress 本身，而是在它運作的環境裡，這一節處理的正是最容易被忽略的環境層級成因。
檔案與資料夾權限跑掉是其中之一。一般標準是資料夾設定為 755、檔案設定為 644，wp-config.php 因為裡面存有資料庫連線資訊，建議收得更緊，設成 600 或 644 都可以；把權限開到 777 等於幫自己的網站開一個資安漏洞，不少主機商甚至會直接把這種設定擋下來，不讓它生效。
共用主機資源被同一台伺服器上的其他網站排擠，或是自己網站流量突然暴增，同樣可能讓伺服器一時撐不住而回傳 500。這種情況通常沒辦法靠改 WordPress 端的設定解決，得看主機方案能不能負荷，或考慮升級到資源更充足的方案。
主機商在背景把 PHP 版本升級之後，舊外掛或舊主題如果用到已經被移除的 PHP 函式，就會整片跳出 500 錯誤。這常常就是網站明明放著沒動，卻突然壞掉背後真正的原因，值得回頭檢查最近有沒有被動升級過 PHP 版本。
多數文章沒講清楚的一點是，如果網站前面掛了 CDN 或 WAF 這類服務（例如 Cloudflare），瀏覽器看到的 500 錯誤畫面有可能其實是那一層服務自己回報的，不是 WordPress 本身。這種畫面通常會帶有對應服務的品牌樣式，還會附一組追蹤代碼。遇到這種情況，要先確認問題是不是出在那一層，不然照著改 WordPress 端的設定，不會有任何效果。
修法六：重新上傳核心檔案，處理更新中途損毀的情況
前面幾個修法都試過還是沒解決，代表問題可能出在 WordPress 核心檔案本身，在某次更新過程中途中斷，導致部分檔案損毀或缺漏。
處理方式是回到 WordPress.org 下載目前最新版本的安裝包，解壓縮之後，透過 FTP 把裡面的 wp-admin 與 wp-includes 這兩個資料夾，整批覆蓋上傳到網站原本的位置。這兩個資料夾裝的都是 WordPress 核心程式碼，直接覆蓋不會影響任何既有內容。
有兩樣東西絕對不能覆蓋：一是 wp-content 資料夾，外掛、佈景主題、上傳過的媒體檔案全部放在裡面，覆蓋等於把這些東西整批換掉；二是 wp-config.php，這個檔案存著資料庫連線資訊，一旦被新版覆蓋，網站會直接找不到自己的資料庫，等於整站斷線，比原本的 500 錯誤還嚴重。
只要避開這兩樣，重新上傳核心檔案不會動到任何一篇文章、頁面、媒體或資料庫裡的內容，可以放心操作，不必擔心資料不見。
找主機商前，先準備好這三項資訊
六個修法都做完，網站還是持續出現 500 錯誤，代表問題大概真的出在伺服器層級了，可能是資料庫本身損毀，或是伺服器端的軟體、資安規則出了狀況，這時候該找主機商幫忙。但要讓客服人員一次就抓到重點，而不是來回問半天才進入狀況，先把三項資訊準備好再開單：
- 問題發生的確切時間與範圍：是整站都打不開，還是只有特定頁面才會，大概從什麼時候開始。
- 事發前做過的變更：更新過哪個外掛、換過佈景主題、升級過 PHP 版本，或是剛搬過家，這些都是主機商用來縮小排查範圍的重要線索。
- 錯誤紀錄檔裡完整的那一行錯誤訊息：連同對應的檔案路徑與行號，這是最有價值的診斷線索，主機商拿到這行往往能省下大半來回確認的時間。
打開除錯模式，才能看到第三項需要的那行錯誤訊息。做法是到 wp-config.php 裡加上這幾行：
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Code language: PHP (php)打開之後，錯誤紀錄會寫進 wp-content 資料夾底下的 debug.log 這個檔案，把那一行完整的錯誤訊息複製給主機商即可。
問題排除之後，記得把這段除錯設定拿掉，不需要讓網站一直記錄除錯資訊，也要避免有人不小心把 WP_DEBUG_DISPLAY 改成 true，讓錯誤細節一直曝露在前台給訪客看到。
500 錯誤第一次遇到通常會讓人心裡發毛，畫面一片空白又不知道從何下手。但真正拆開來看，多半只是前面某個環節出了個小差錯，照著順序一項一項排查，通常幾分鐘到十幾分鐘之間就能揪出問題所在，不必真的動用工程師。
比排查更值得養成的習慣，是在重大異動之前先做好準備：更新外掛、換佈景主題、搬家這類動作之前，先備份一次網站，或是先在測試環境跑過一輪確認沒問題再上線。下次真的再遇到類似狀況，至少能照著這份清單一步步操作，不必邊冒冷汗邊臨場摸索。