WordPress 錯誤怎麼修？安全排查順序與常見修復方法

WordPress 錯誤先不要亂修：3 分鐘安全排查順序

WordPress 錯誤修復的安全順序是：先備份網站與資料庫，再記錄錯誤訊息與發生位置，最後判斷能不能進後台。不要一看到錯誤就刪外掛、改核心檔或清空資料表，很多網站是被第二次錯誤操作修壞的。

以網站維護經驗來看，真正棘手的通常不是第一個 WordPress 錯誤，而是站長在沒有備份、沒有記錄錯誤訊息的情況下連續改了好幾個地方。先把現場保留下來，後面才有機會判斷是外掛衝突、佈景主題問題、PHP 版本、資料庫連線、主機資源，還是 Gutenberg 與 REST API 被阻擋。

第一步：先備份網站與資料庫

在停用外掛、切換佈景主題、修改 wp-config.php、調整資料庫或還原檔案前，先做完整備份。至少要包含 WordPress 檔案與 MySQL 或 MariaDB 資料庫，因為文章、頁面、設定、使用者、訂單或表單紀錄多半都在資料庫裡。

如果主機控制台有備份功能，可以先下載一份目前時間點的備份；如果有備份外掛，也要確認備份真的產生完成。不要只備份 wp-content，也不要只備份資料庫。只備份一半，還原時很容易出現版本對不上、圖片遺失或外掛設定回不來的問題。

第二步：記下錯誤訊息與發生位置

請先記錄錯誤發生的 URL、時間、你剛剛做了什麼操作、錯誤文字，以及錯誤出現在前台、後台、登入頁、文章編輯器，還是特定文章頁面。這些資訊比「網站壞了」有用太多。

例如「文章更新失敗，顯示無效的 JSON 回應」通常會往 Gutenberg、REST API、固定網址、安全外掛或 WAF 查；「連接資料庫時發生錯誤」則會往 wp-config.php、資料庫服務與 PHP MySQL 擴充模組查。錯誤訊息越完整，排查時間越短。

第三步：判斷能不能進 WordPress 後台

能不能進後台，會決定 WordPress 疑難排解路線。能進後台時，先從外掛、佈景主題、固定網址、站點健康狀態開始。不能進後台時，改用主機檔案管理員、FTP、cPanel、Plesk 或 DirectAdmin 進行低風險恢復。

如果只有前台壞、後台正常，優先查佈景主題、快取與固定網址。如果後台也白屏或出現重大問題，優先停用外掛、切回預設佈景主題並查看錯誤日誌。如果連主機控制台都進不去，就先找主機商確認主機服務狀態。

WordPress 常見錯誤症狀對照表

WordPress 常見錯誤可以先用症狀分類：白屏與重大問題多半和 PHP、外掛、佈景主題有關；資料庫連線要查資料庫服務與設定；404 要查固定網址與重新導向；無效的 JSON 回應通常要查 REST API、WAF 或安全外掛。

錯誤症狀	常見原因	能否進後台	第一檢查位置	建議修法
網站發生重大問題	外掛、佈景主題或 PHP 致命錯誤	不一定	復原模式 Email、debug.log、主機 error log	停用最近更新的外掛，切回預設佈景主題，查錯誤檔案
整站白屏	PHP fatal error、記憶體不足、主題錯誤	常常不能	/wp-content/plugins/、/wp-content/themes/	改名停用外掛，測試預設佈景主題，檢查 PHP 記憶體限制
連接資料庫時發生錯誤	資料庫設定錯誤、服務停止、PHP MySQL 模組異常	通常不能	wp-config.php、主機資料庫狀態、phpMyAdmin	核對 DB_NAME、DB_USER、DB_PASSWORD、DB_HOST，確認 MySQL 或 MariaDB 正常
500 Internal Server Error	.htaccess、PHP 錯誤、權限、主機資源不足	不一定	主機 error log、.htaccess、PHP 版本	看 log 後再排除，重新產生固定網址規則，檢查外掛與主題
文章或頁面 404	固定網址規則失效、slug 改動、舊網址未轉址	通常可以	固定網址設定、Google Search Console	重新儲存固定網址；有排名或外部連結的舊網址做 301
無效的 JSON 回應	REST API 被擋、WAF、安全外掛、快取衝突	通常可以	站點健康狀態、REST API、固定網址、安全規則	重存固定網址，檢查安全外掛、ModSecurity、快取與編輯器外掛
記憶體耗盡或逾時	外掛消耗過高、匯入資料過大、主機資源不足	不一定	debug.log、主機資源、PHP 記憶體限制	停用高負載外掛，調整 WP_MEMORY_LIMIT，必要時找主機商

看到「網站發生重大問題」

看到「網站發生重大問題」時，通常代表 PHP 執行時發生致命錯誤。常見原因是外掛更新失敗、佈景主題函式錯誤、PHP 版本不相容，或某段程式碼呼叫了不存在的函式。

先查 WordPress 寄出的復原模式 Email，裡面可能會指出是哪個外掛或佈景主題出錯。若沒有收到信，改查 /wp-content/debug.log 或主機 error log。可以先停用最近更新的外掛；如果錯誤和佈景主題有關，再暫時切回官方預設主題。不要直接改 WordPress 核心檔案，這通常修不到根因。

整站白屏或後台白屏

WordPress 白屏最常見是 PHP fatal error、記憶體不足或外掛衝突。前台白屏但後台可進，常見於佈景主題模板錯誤；後台也白屏，則外掛、PHP 版本或主機資源的機率更高。

能進後台時，先停用所有外掛再逐一啟用測試。不能進後台時，用 FTP 或檔案管理員把 /wp-content/plugins/ 改名，讓 WordPress 暫時停用外掛。若仍白屏，再檢查佈景主題資料夾，或上傳官方預設佈景主題測試。若 log 顯示 memory exhausted，可再評估調整 PHP 記憶體限制。

連接資料庫時發生錯誤

「連接資料庫時發生錯誤」不一定是帳號密碼錯。WordPress 需要 PHP 連到 MySQL 或 MariaDB，如果資料庫服務停止、DB host 不對、使用者權限異常，或 PHP 的 mysqli、pdo_mysql 擴充模組未啟用，都可能出現這個錯誤。

第一檢查位置是 wp-config.php 裡的 DB_NAME、DB_USER、DB_PASSWORD、DB_HOST。接著到主機控制台看資料庫服務是否正常，並用 phpMyAdmin 測試是否能登入。不要把帳密貼到公開論壇或交給不明外掛檢查，這是很基本但常被忽略的安全邊界。

500 Internal Server Error

WordPress 500 錯誤代表伺服器無法完成請求，但畫面本身通常不會告訴你真正原因。常見來源包含 .htaccess 規則錯誤、PHP fatal error、檔案權限錯誤、主機資源不足或外掛衝突。

先看主機 error log，再決定下一步。若 log 指向某個外掛，就先停用該外掛；若指向 .htaccess，可先備份舊檔，再透過後台固定網址重新產生規則。若是權限問題，不要把所有資料夾一律改成最高權限，這會留下安全風險。

404 找不到頁面或文章網址失效

WordPress 404 常見原因是固定網址規則失效、文章 slug 改了、分類路徑調整，或舊網址沒有做 301 重新導向。全站文章突然 404，通常先查固定網址；只有少數頁面 404，則要查網址是否曾經變更。

如果只是 rewrite rules 失效，進後台重新儲存固定網址通常就能修。若舊網址曾有搜尋流量、排名、外部連結或社群分享，就應該做 301 重新導向到最相關的新頁，不要全部導到首頁。亂導首頁可能讓 Google 判定為不相關轉址，反而影響搜尋結果表現。

文章更新失敗或無效的 JSON 回應

Gutenberg 編輯器需要透過 REST API 儲存文章，所以「更新失敗」或「無效的 JSON 回應」常見於 REST API 被擋、固定網址規則錯誤、安全外掛攔截、WAF 或 ModSecurity 規則誤判，也可能是快取外掛造成回應異常。

先重新儲存固定網址，接著到站點健康狀態查看 REST API 是否正常。若問題只發生在文章儲存，請暫停快取外掛、區塊編輯器相關外掛或安全外掛測試。若主機有 WAF 或 ModSecurity，應請主機商查封鎖紀錄，不要把防護整個關掉後就放著不管。

能進後台時，WordPress 錯誤怎麼排查？

能進 WordPress 後台時，先做低風險排查：停用全部外掛並逐一測試、暫時切回預設佈景主題、重新儲存固定網址，再看站點健康狀態。這些動作能排除多數 WordPress 錯誤，而且不需要修改核心檔案。

停用全部外掛，再逐一啟用測試

外掛衝突是 WordPress 錯誤修復裡最常見的路線。先記錄目前啟用的外掛清單，再停用全部外掛，確認錯誤是否消失。若錯誤消失，就一次只啟用一個外掛，啟用後重複原本造成錯誤的操作。

高風險外掛類型通常包含快取、安全、表單、SEO、會員、編輯器擴充與自動最佳化外掛。我的判斷是，不要在同一輪測試同時開關三四個外掛，因為你最後只會知道「某一批外掛有問題」，卻不知道是哪一個造成錯誤。

切回預設佈景主題測試

如果停用外掛後錯誤仍在，下一步檢查佈景主題。先備份網站，再暫時切回 WordPress 官方預設的 Twenty 系列佈景主題，觀察白屏、500、版面錯誤或特定頁面錯誤是否消失。

若切換後恢復正常，問題多半在目前佈景主題、子主題或模板客製程式碼。這時不要急著刪主題，可以先把錯誤日誌交給維護者確認。客製主題常和外掛、PHP 版本、短代碼或自訂欄位綁在一起，粗暴切換可能影響前台版面。

重新儲存固定網址

文章頁、分類頁或自訂文章類型突然 404 時，先到「設定」裡的固定網址頁面，不更改結構也可以直接儲存一次。這個動作會讓 WordPress 重新產生 rewrite rules。

如果重新儲存後恢復正常，代表主要是網址規則失效。若儲存後仍 404，再查 .htaccess 是否可寫、是否被安全外掛或主機規則覆蓋，以及是否有網址被改名或刪除。

檢查 WordPress 站點健康狀態

站點健康狀態可以快速看到 PHP 版本、HTTPS、REST API、背景更新、資料庫與外掛相關警告。它不是唯一答案，但很適合當作第一輪診斷儀表板。

如果站點健康狀態顯示 REST API 錯誤，優先處理無效 JSON 回應、Gutenberg 儲存失敗與安全規則阻擋。如果顯示 PHP 版本過舊或模組缺失，則要找主機商確認 PHP Selector、擴充模組與主機環境設定。

不能進後台時，如何安全停用外掛與佈景主題？

不能進後台時，仍可透過 FTP 或主機檔案管理員停用外掛與佈景主題。安全做法是改資料夾名稱讓 WordPress 暫時停用，不要直接刪除外掛資料，也不要在沒有備份的情況下改資料庫。

用主機檔案管理員或 FTP 停用外掛

進入主機控制台的 File Manager，或用 FTP 連到網站檔案，找到 /wp-content/plugins/。把整個 plugins 資料夾改名，例如改成 plugins-off，WordPress 會因為找不到原資料夾而暫時停用所有外掛。

如果網站恢復，再把資料夾名稱改回 plugins，進後台逐一啟用外掛測試。不要直接刪除外掛資料夾，因為有些外掛的設定、快取或授權資料可能會跟著遺失。用改名測試，比刪除更容易回復。

用檔案方式切換佈景主題

如果停用外掛仍無法恢復，進入 /wp-content/themes/ 檢查目前使用的佈景主題。可以暫時改名目前主題資料夾，讓 WordPress 嘗試切換到可用的預設佈景主題。

若網站裡沒有官方預設主題，先從 WordPress 官方來源取得乾淨的預設佈景主題並上傳。不要從不明網站下載主題包，也不要任意修改主題內的 PHP 檔。若錯誤來自客製主題，最好保留原檔案與錯誤日誌，交給工程師定位。

還原最近一次正常備份

如果網站正在營運，且錯誤已影響詢問單、收款、會員登入或搜尋流量，還原最近一次正常備份通常比長時間試錯更務實。還原前要確認備份時間點，以及這段時間新增的文章、訂單、留言或表單資料會不會遺失。

主機備份、外掛備份與手動備份的還原範圍可能不同。有些只還原檔案，有些會連資料庫一起還原。這裡一定要看清楚，因為把資料庫回到昨天，可能會讓今天新增的內容消失。

如何開啟 WordPress Debug 並查看錯誤日誌？

WordPress Debug 的重點是把真正錯誤寫進 log，而不是把錯誤顯示給訪客看。正式站建議開啟 WP_DEBUG_LOG、關閉畫面顯示錯誤，查完 debug.log 與主機 error log 後再關閉除錯。

wp-config.php 的 Debug 設定

在修改 wp-config.php 前先備份檔案。常見設定如下，放在「停止編輯」提示文字之前：

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

WP_DEBUG 會開啟 WordPress 除錯模式，WP_DEBUG_LOG 會把錯誤寫入 log，WP_DEBUG_DISPLAY 設為 false 可以避免把路徑、外掛名稱或伺服器資訊顯示在前台。正式站不建議長時間把錯誤直接顯示給訪客。

debug.log 通常在哪裡？

WordPress 的 debug.log 通常在 /wp-content/debug.log。如果沒有產生，可能是權限問題、錯誤沒有重現，或主機限制了寫入位置。

主機控制台也常有 error log 入口。cPanel 可能在 Errors、Metrics 或 File Manager 附近；Plesk 通常有 Logs；DirectAdmin 也有網站層級的錯誤紀錄。不同主機商介面不完全一樣，所以找不到時直接問主機商「PHP error log 在哪裡看」比自己亂翻更快。

Debug 開完後要關閉顯示錯誤

錯誤日誌查完後，至少要確認前台不顯示錯誤。錯誤訊息可能包含主機路徑、外掛名稱、主題檔案位置、資料庫錯誤或函式名稱，這些資訊不該公開給訪客或搜尋引擎看到。

比較穩妥的做法是保留必要 log、關閉畫面顯示，並在修復後把 Debug 設回正式站適合的狀態。若網站疑似被植入惡意程式、出現異常重新導向或安全警告，排查方向應轉到 網站安全完整防護，不要只當成一般外掛錯誤。

資料庫連線錯誤怎麼修？

資料庫連線錯誤要分四層查：wp-config.php 設定、MySQL 或 MariaDB 服務、資料庫使用者權限、PHP MySQL 擴充模組。只檢查帳號密碼不夠，因為主機服務停止或模組缺失也會讓 WordPress 連不上資料庫。

可能原因	檢查位置	處理方向
資料庫名稱或帳密錯誤	wp-config.php、主機資料庫管理頁	核對 DB_NAME、DB_USER、DB_PASSWORD
DB host 錯誤	DB_HOST、主機商文件	確認是否為 localhost 或主機商指定位置
MySQL 或 MariaDB 停止	主機控制台、VPS 或 NAS 服務狀態	請主機商處理，或自行重啟資料庫服務
PHP MySQL 模組未啟用	PHP Selector、站點健康狀態、主機設定	啟用 mysqli 或 pdo_mysql，非工程讀者可請主機商確認

檢查 wp-config.php 的資料庫名稱、帳號、密碼、主機

打開 wp-config.php，核對 DB_NAME、DB_USER、DB_PASSWORD、DB_HOST。這些值要和主機控制台中的資料庫設定一致。

不要把帳密貼到公開社群、論壇或截圖裡。若需要請工程師協助，可以用臨時權限或安全通道交付，修完再更換密碼。資料庫帳密外洩，比一次網站錯誤麻煩得多。

確認 MySQL / MariaDB 服務是否正常

台灣常見虛擬主機通常由主機商管理 MySQL 或 MariaDB 服務，站長能做的是查看控制台狀態、測試 phpMyAdmin，或請主機商確認資料庫服務是否正常。VPS 或 NAS 架站則不同，資料庫服務可能需要自己檢查與重啟。

如果 phpMyAdmin 也無法登入，或主機控制台顯示資料庫異常，這就不只是 WordPress 後台問題。虛擬主機使用者應先找主機商；自管 VPS 或 Synology NAS 使用者則要檢查服務是否啟動、資源是否耗盡、資料庫是否損壞。

確認 PHP MySQL 擴充模組是否啟用

WordPress 需要 PHP 透過 MySQL 相關擴充模組連線資料庫，常見是 mysqli 或 pdo_mysql。若 PHP 版本切換後擴充模組沒有啟用，網站可能突然出現資料庫連線錯誤。

在 cPanel、Plesk 或 DirectAdmin 裡，這類設定可能放在 PHP Selector、PHP Settings 或主機商自訂介面。非工程讀者可以直接問主機商：「目前網站使用的 PHP 版本是否啟用 mysqli 或 pdo_mysql？」這比自己猜設定可靠。

500、白屏、重大問題：外掛、主題與 PHP 錯誤排除

500、白屏與「網站發生重大問題」通常要從 PHP 版本、外掛衝突、佈景主題錯誤、記憶體限制、.htaccess 與檔案權限排查。正確做法是先看 log，再回頭驗證最近更新或變更過的項目。

PHP 版本不相容

WordPress、外掛與佈景主題都跑在 PHP 上。當主機升級 PHP 版本，舊外掛或舊主題可能因語法、函式或相依套件不相容而出錯。反過來，PHP 版本過舊也可能讓新版外掛無法執行。

升級或降版前都要先備份，最好在測試站確認。不要為了讓一個舊外掛能跑，就長期停在過舊 PHP 版本。我的建議是先找出不相容外掛或主題，再決定更新、替換或請工程師修，不要把 PHP 降版當成永久解法。

記憶體不足與 execution timeout

錯誤日誌如果出現 memory exhausted 或 max execution time，通常代表某個請求消耗太多資源。常見情境包含大型匯入、備份外掛、圖片處理、頁面產生器、快取重建或外掛程式迴圈錯誤。

可以評估在 wp-config.php 設定 WP_MEMORY_LIMIT，但這不是萬用答案。如果網站常常因資源不足出錯，應該檢查外掛負載、主機方案與效能瓶頸。這類問題可延伸參考 網站速度與效能優化指南，但排錯當下先以恢復網站為優先。

.htaccess 或檔案權限錯誤

Apache 環境常見 .htaccess 規則造成 500 或 404。WordPress 固定網址、安全外掛、快取外掛都可能寫入這個檔案。若最近修改過固定網址、安裝安全外掛或搬家後出錯，就應該檢查它。

做法是先備份 .htaccess，再透過固定網址頁面重新儲存，讓 WordPress 重新產生規則。檔案權限方面，不要把全部檔案與資料夾設成可寫給所有人。若不確定正確權限，請主機商協助確認，特別是虛擬主機環境。

404、重新導向與 SEO：修錯誤時不要讓排名流失

WordPress 404 修復要先分辨是系統性錯誤、網址變更，還是頁面本來就該移除。全站文章突然 404 可先重存固定網址；有排名、流量或外部連結的舊網址要做 301；修復後用 Google Search Console 驗證狀態。

情境	建議處理	SEO 判斷
全站文章突然 404	重新儲存固定網址，檢查 .htaccess	通常是規則失效，優先恢復原網址
單一頁面改過網址	舊網址 301 到最相關的新網址	有流量、排名或外部連結時要保留訊號
內容已刪除且沒有替代頁	可保留 404 或 410	不要硬導首頁，避免不相關轉址
分類或文章架構調整	建立對應轉址表	高流量頁、收錄頁與外部連結頁優先處理

什麼時候重新儲存固定網址就好？

如果原本正常的文章突然全部 404，而後台文章仍存在，通常先重新儲存固定網址就好。這種狀況多半是 rewrite rules 失效，不一定代表文章被刪除。

重新儲存後，測試首頁、文章頁、分類頁與幾個重要頁面。如果只有部分頁面仍 404，就不是單純固定網址規則問題，應回頭查 slug、分類路徑、轉址規則或快取。

什麼時候要做 301 重新導向？

舊網址曾有搜尋流量、排名、外部連結、社群分享，或已被 Google 收錄時，改網址後應做 301 重新導向到最相關的新頁。301 的目的不是把所有錯誤藏起來，而是把使用者和搜尋引擎帶到合理替代內容。

不要把全部 404 導向首頁。這種做法看起來省事，但對使用者與搜尋引擎都不精準。若你正在評估自己修、請維護商處理，或把網站維護納入長期成本，可以參考 網站建置費用 或 自己架站與委外架站比較。

修復後如何用 Google Search Console 檢查？

修復後，到 Google Search Console 使用「網址檢查」測試重要頁面，確認 Google 能抓取正確狀態。若是大量 404，可查看網頁索引報告，確認錯誤網址是否逐步下降。

對重要頁面，可以檢查目前收錄狀態並重新提交索引。對已做 301 的舊網址，應確認它真的轉到相關新網址。GSC 不會立刻更新所有狀態，觀察趨勢比盯著單一天結果更有意義。

文章無法更新、無效的 JSON 回應與 REST API 錯誤

文章無法更新或出現無效的 JSON 回應，通常和 Gutenberg 透過 REST API 儲存文章失敗有關。優先檢查固定網址、站點健康狀態、REST API、安全外掛、WAF、ModSecurity、快取與編輯器外掛衝突。

可能原因	檢查位置	處理方式
固定網址規則異常	後台固定網址設定	重新儲存固定網址後再測試文章更新
REST API 被阻擋	站點健康狀態、主機 log	確認 REST API 回應，查安全規則
WAF 或 ModSecurity 誤擋	主機控制台、主機商封鎖紀錄	請主機商調整規則，不要永久關閉防護
快取或編輯器外掛衝突	外掛清單、快取設定	一次停用一個變因並重測

先重新儲存固定網址與檢查 REST API 狀態

第一步先重新儲存固定網址，因為 REST API 路由也可能受 rewrite rules 影響。接著到站點健康狀態查看 REST API 是否正常，或觀察是否有「REST API 遇到錯誤」相關提示。

如果文章能打開但不能儲存，問題通常集中在編輯器請求被阻擋或回應格式不正確。這是 2026 年 WordPress 維護很常遇到的錯誤，尤其是安全規則、快取策略與區塊編輯器一起使用時。

檢查安全外掛、WAF、ModSecurity 是否阻擋

安全外掛、WAF、ModSecurity 可能把 Gutenberg 儲存文章的 REST API 請求誤判成攻擊。這種情況下，前台看起來正常，但文章一按更新就失敗。

可以暫時停用安全外掛測試，但測完要恢復防護。若主機層 WAF 或 ModSecurity 擋住請求，請主機商查封鎖紀錄，針對特定規則調整。不要用「全部關閉防火牆」當長期解法，這會把網站暴露在更高風險裡。

檢查快取與編輯器外掛衝突

快取外掛、最佳化外掛、Classic Editor、區塊編輯器擴充外掛，都可能影響文章儲存流程。排查時一次只停用一個變因，測試文章是否能更新，再決定下一步。

如果停用某個快取或最佳化功能後恢復，問題不一定是外掛本身爛，也可能是設定太激進。常見情況是 API 請求被快取、壓縮或安全規則處理錯誤。這時應調整排除規則，而不是把整個快取系統永久關掉。

台灣常見主機環境下，錯誤日誌與修復入口在哪裡？

台灣常見 WordPress 主機環境包含 cPanel、Plesk、DirectAdmin、虛擬主機、VPS 與 NAS。排錯入口通常在 File Manager、Error Log、PHP Selector、phpMyAdmin、WAF 設定與資料庫服務狀態，不同環境責任邊界不同。

環境	常見入口	適合處理的 WordPress 錯誤
cPanel	File Manager、Errors、MultiPHP、phpMyAdmin	停用外掛、查 log、切 PHP 版本、查資料庫
Plesk	Files、Logs、PHP Settings、Databases	查 PHP 錯誤、REST API 問題、資料庫連線
DirectAdmin	File Manager、Site Summary、PHP Settings、MySQL Management	檔案層恢復、PHP 設定、資料庫檢查
虛擬主機	主機商控制台、客服支援	PHP 模組、WAF、資料庫服務、主機資源
VPS 或 NAS	系統服務、Web 服務、資料庫服務、錯誤日誌	服務停止、資源不足、資料庫異常、權限問題

cPanel / Plesk / DirectAdmin 的常見檢查位置

cPanel、Plesk、DirectAdmin 都常見於台灣 WordPress 主機，但名稱與位置不一定相同。找檔案通常看 File Manager 或 Files；找錯誤看 Error Log 或 Logs；查 PHP 看 PHP Selector、MultiPHP 或 PHP Settings；查資料庫看 phpMyAdmin 或 MySQL Management。

不要假設每家主機介面都一樣。比較有效的問法是把錯誤訊息、發生時間、網址、你剛做過的操作交給主機商，請他們協助查 PHP error log、WAF 封鎖紀錄、資料庫服務與主機資源。

虛擬主機、VPS、NAS 架站的責任邊界

虛擬主機的 PHP、MySQL、MariaDB、WAF 與主機資源大多由主機商管理，所以資料庫服務異常、PHP 模組未啟用或主機資源受限時，應先問主機商。VPS 或 NAS 架站則多半是自管責任，服務停止、權限、磁碟空間與資料庫狀態都要自己查。

這裡的責任邊界很重要。很多中小企業以為「網站是 WordPress，所以都找網站工程師」，但如果是主機層 PHP 模組、WAF 或資料庫服務問題，主機商通常更快能看到原因。反過來，客製外掛、客製主題或資料庫資料結構問題，就不應期待主機商幫你改程式。

哪些 WordPress 錯誤可以自己修，哪些應該找主機商或工程師？

低風險 WordPress 錯誤可以先自己修，例如備份、停用外掛、切預設佈景主題、重存固定網址。涉及主機服務、PHP 模組、WAF 時先問主機商；涉及客製程式、資料庫損壞、長期 500 或資安感染時找工程師。

處理對象	適合情況	應提供的資訊
自己先處理	外掛衝突、固定網址失效、暫時切主題、查看站點健康狀態	備份、錯誤截圖、發生時間、測試紀錄
主機商	資料庫服務、PHP 模組、主機資源、WAF、ModSecurity、error log	網址、錯誤時間、錯誤訊息、你的主機帳號或網域
工程師	客製主題、客製外掛、資料庫損壞、反覆 500、安全感染	備份、log、最近變更紀錄、主機與後台權限

可以先自己做的低風險操作

可以先自己做的操作包含：完整備份、記錄錯誤訊息、停用外掛、一次啟用一個外掛測試、切回預設佈景主題、重新儲存固定網址、查看站點健康狀態、清除快取後重測。

這些動作的共同點是可回復、風險低、能縮小範圍。不要一開始就改核心檔案、刪資料表、重裝 WordPress，或把所有 404 導到首頁。排錯不是看誰改得多，而是看誰能用最少變更找出根因。

應該先問主機商的情況

如果錯誤和資料庫服務、PHP 版本、PHP MySQL 擴充模組、主機資源、WAF、ModSecurity、SSL 或 error log 有關，應該先問主機商。主機商能看到的紀錄，通常比 WordPress 後台更多。

詢問時請附上：錯誤網址、發生時間、錯誤訊息截圖、你剛做過的操作、是否能進 WordPress 後台、是否只影響特定頁面。這些資料會讓客服更容易查到對應的 log，而不是來回問基本問題。

應該找工程師的情況

如果錯誤涉及客製外掛、客製佈景主題、資料庫資料損壞、反覆出現 500、重大問題找不到來源，或網站疑似被植入惡意程式，就應該找工程師。這類問題不適合新手照網路文章硬改。

找工程師時，最好提供最近正常備份、錯誤日誌、主機控制台權限、WordPress 後台權限與最近變更紀錄。若網站是公司官網或有詢問單，維修目標應先放在恢復營運，再處理長期優化。

WordPress 出現「網站發生重大問題」是什麼意思？

通常代表 WordPress 執行 PHP 時發生致命錯誤，常見來源是外掛、佈景主題、PHP 版本不相容或客製程式碼。先查復原模式 Email、debug.log 與主機 error log，再停用最近更新的外掛或切回預設佈景主題測試。

WordPress 白屏但沒有錯誤訊息，第一步要查哪裡？

第一步先確認能不能進後台。能進後台就停用全部外掛並逐一啟用測試；不能進後台就用 FTP 或主機檔案管理員把 /wp-content/plugins/ 改名。接著開啟 Debug，把錯誤寫入 /wp-content/debug.log。

WordPress 連接資料庫時發生錯誤，一定是帳號密碼錯嗎？

不一定。除了資料庫名稱、帳號、密碼、DB host 之外，也可能是 MySQL 或 MariaDB 服務停止、資料庫使用者權限異常，或 PHP 的 mysqli、pdo_mysql 擴充模組沒有啟用。應同時查 wp-config.php、主機控制台與 phpMyAdmin。

我不能進 WordPress 後台，還能停用外掛嗎？

可以。用 FTP 或主機檔案管理員進入 /wp-content/，把 plugins 資料夾改名，例如 plugins-off，WordPress 會暫時停用所有外掛。網站恢復後再改回原名，進後台逐一啟用測試。

WordPress 500 錯誤通常是主機問題還是外掛問題？

兩者都有可能。500 只是伺服器無法完成請求的結果，根因可能是外掛 PHP 錯誤、佈景主題錯誤、.htaccess 規則、檔案權限或主機資源不足。先看主機 error log，再判斷要停外掛、改固定網址規則，還是找主機商。

文章或頁面更新失敗，顯示無效的 JSON 回應怎麼辦？

先重新儲存固定網址，再檢查站點健康狀態中的 REST API。若仍失敗，測試安全外掛、WAF、ModSecurity、快取外掛與編輯器外掛是否阻擋 Gutenberg 的儲存請求。不要永久關閉安全防護，應找出被擋的規則。

WordPress 文章突然全部 404，會影響 SEO 嗎？

如果持續存在，會影響使用者體驗、搜尋結果點擊後的可用性，也可能影響 Google 對頁面的存取。全站文章突然 404 時，先重新儲存固定網址並檢查 .htaccess。恢復後再用 Google Search Console 查看錯誤是否下降。

修復 404 後，需要到 Google Search Console 做什麼？

用「網址檢查」測試重要頁面，確認 Google 能抓取正確狀態。若是已修復的重要頁面，可以重新提交索引。若是大量 404，查看網頁索引報告的趨勢，確認錯誤網址是否逐步下降。

wp-db.php 出現錯誤代表資料庫壞掉嗎？

不一定。wp-db.php 是 WordPress 處理資料庫連線與查詢的核心檔案，錯誤訊息出現它，不代表這個檔案壞了。更常見的是資料庫連線設定、資料庫服務、查詢錯誤、外掛或主題呼叫資料庫時出問題。不要直接修改核心檔案。

WordPress 升級後網站壞掉，可以直接降版嗎？

不建議把降版當第一步。先備份並查錯誤日誌，確認是外掛、佈景主題、PHP 版本還是核心升級相容性問題。直接降版可能帶來安全風險，也可能讓資料庫版本與檔案版本不一致。必要時應先在測試環境驗證。

留言頁或留言送出後變 404，要檢查什麼？

先檢查固定網址、留言設定、快取外掛、安全外掛與 WAF。留言送出涉及表單請求，可能被安全規則誤擋，也可能因快取或重新導向設定異常而跳到錯誤網址。測試時請用未登入視窗重現一次，並記錄送出後的網址。

記憶體耗盡錯誤可以自己改 wp-config.php 嗎？

可以，但要先備份，且只把它當成排查的一部分。可評估設定 WP_MEMORY_LIMIT，但如果錯誤反覆出現，根因可能是外掛消耗過高、匯入資料太大、圖片處理過重或主機資源不足。這時應同時查 log、外掛與主機資源。