WPTOOLBEAR網站工具熊WordPress 無效 JSON 怎麼修？區塊編輯器儲存排查
WordPress 無效 JSON 錯誤，通常表示編輯器沒有收到預期的資料格式。先找出儲存失敗的 REST API 請求，再依回應內容處理固定網址、外掛、安全規則或 PHP 錯誤，才能避免改錯設定。
遇到「更新失敗」時，請先複製尚未儲存的內容，並在修改前完成檔案與資料庫備份。接著依照以下順序排查，每次只改一項，再重試原本失敗的操作。
重點整理
- 修改前先複製未儲存的內容並備份檔案與資料庫；每次只調整一項，再重試原本失敗的操作。
- 在瀏覽器開發者工具的 Network 面板找出失敗的 REST API 請求，查看狀態碼與 Response 內容。狀態碼 200 也可能回傳 HTML 或 PHP 錯誤訊息。
- 依回應內容排查固定網址、
.htaccess、HTTPS 設定、登入驗證、外掛或佈景主題衝突、防火牆規則及 PHP 錯誤，不要直接關閉防護或大幅修改權限。 - 修正後重新開啟文章，確認內容確實保存，並測試相關網址或表單；完成後停用臨時除錯設定，恢復暫停的防護。
先理解 WordPress 無效 JSON 代表什麼
JSON 是資料格式，HTML 是網頁內容
區塊編輯器透過 REST API 儲存文章，預期收到 JSON 格式的資料。如果伺服器回傳登入頁、防火牆驗證頁，或在資料前面插入 PHP 警告，編輯器就可能無法解析。
因此，「response is not a valid JSON response」描述的是收到的回應異常，單看提示還無法定位來源。
先保存內容與可還原的設定
備份至少保留一份在站外，並記下近期更新的外掛、佈景主題及主機設定。修改 .htaccess 或 wp-config.php 前，也要另外下載原檔。
我們建議優先在測試站操作。正式站若持續產生訂單或會員資料，不能直接覆蓋舊資料庫來測試。
用 Console 與 Network 找出失敗請求
開啟開發者工具，再重現一次
在 Chrome 或 Edge 按 F12，開啟 Browser Developer Tools（瀏覽器開發者工具），或從選單開啟「開發人員工具」。在 Developer Tools 中先查看 Console（主控台），再按一次儲存，記下同時出現的紅色錯誤。
接著切換到 Network（網路），選取 Fetch/XHR，再次儲存文章，檢查送出的 REST request。文章請求通常包含 /wp-json/wp/v2/posts/，頁面則包含 /wp-json/wp/v2/pages/。
如果 Console 顯示「response is not a valid JSON response」，請接著檢查失敗請求的回應內容。
若要檢查 Contact Form 7 表單，必須在送出表單時尋找 /wp-json/contact-form-7/.../feedback。這筆請求與文章儲存不同。
狀態碼與 Response 要一起看
點選失敗請求，查看 Headers 中的 status code，並記下數值，再開啟 Response tab 檢查原始回應內容。
| 觀察結果 | 優先排查方向 |
|---|---|
| 200，但內容是 HTML | 登入頁、驗證頁或錯誤頁 |
| 401、403 | 登入驗證、帳號權限、安全攔截 |
| 404 | 網址重寫、端點或請求方法 |
| 500、502、503 | PHP、上游服務或主機錯誤紀錄 |
排查時要看回應內容。即使狀態碼是 200，也不代表文章已成功儲存。
/wp-json/首頁能開啟，只能證明該次讀取成功，無法證明帶有登入驗證的文章儲存請求也正常。
重新儲存固定網址，再檢查 .htaccess
如果失敗請求回傳 HTML 404，先到後台「設定 > 固定網址」，保留原有結構，按「儲存變更」。SureForms 的無效 JSON 排查文件也將固定網址列為檢查項目。
接著回到編輯器重試。儲存後重新開啟文章，確認內容確實保留，才算這一步通過。
若仍失敗，Apache 環境可檢查 .htaccess 近期新增的轉址或拒絕存取規則。是否讀取此檔，仍取決於伺服器設定；純 Nginx 不讀取 .htaccess。
不要直接刪除整份檔案。重新產生 WordPress 固定網址規則，也不會補回原本的客製安全設定。調整後，除了儲存文章，也要測試既有文章網址。
排除 SSL、混合內容與過期登入
在「設定 > 一般」核對 WordPress 位址與網站位址的網域及 HTTPS 協定。若 WordPress 安裝在子目錄，兩個位址的路徑可以不同，不要強行改成相同。
接著查看 Console 是否出現 Mixed Content。HTTPS 後台若向 HTTP API 發送請求，瀏覽器可能阻擋。應修正錯誤網址、轉址或反向代理的 HTTPS 設定，不能靠略過憑證警告處理。
如果 Response 顯示 rest_cookie_invalid_nonce，先保存文字，再登出重新登入，重新開啟編輯器。完成修正後清除相關快取，確認請求送往正確的 HTTPS 網址，且重新開啟文章仍看得到修改。
逐項測試外掛與佈景主題
從最近變更的項目開始
先在測試站停用最近新增、更新或調整設定的外掛，再儲存同一篇文章。若儲存恢復正常，可能是外掛或佈景主題衝突（conflict）。逐項重新啟用並重試，搭配日誌縮小問題範圍。
仍找不到來源時，再測試其他外掛，以及切換已安裝的 WordPress 預設佈景主題。詳細操作可搭配我們的外掛衝突排查教學進行。
Contact Form 7 要保留表單本身測試
WordPress.org 支援討論曾有停用 AntiSpam 後，Contact Form 7 恢復送出的案例。這可作為相容性調查線索，實際原因仍須依該筆請求回應判斷。
測試時保持 Contact Form 7 啟用，再暫停相關防垃圾訊息功能。這類功能可能造成 compatibility issue（相容性問題），也可能介入請求驗證。仍須依實際請求回應判斷，不能只憑外掛名稱下結論。
重試時，在 submitting the form（送出表單）時觀察請求，確認沒有 JSON 錯誤，並檢查表單結果與通知信是否正常。
遇到防火牆攔截，依紀錄做最小修正
網站可能同時使用 Cloudflare、安全外掛及主機端 ModSecurity。停用安全外掛，不會解除其他層的規則。
遇到 403 或驗證頁時，記下請求路徑、GET／POST 方法、失敗時間與時區，以及請求識別碼，再比對各層安全事件。可依我們的WordPress 403 排查方法區分權限與防火牆問題。
若紀錄確認合法操作命中特定規則，交由主機商或維護人員針對必要欄位、路徑或規則建立例外。不要永久關閉防火牆，也不要把檔案權限全部改成 777。
修正後恢復其他防護，再以原帳號儲存相同內容，確認沒有新增攔截。
啟用 WP_DEBUG_LOG，找出 PHP 輸出
WordPress 的 debug modes（除錯模式）可記錄錯誤，並避免 PHP 訊息顯示在前台。
若 Response 出現 Warning、Deprecated 或 Fatal error，PHP 訊息可能污染回應，或讓請求提前中止。
備份 wp-config.php 後，在「停止編輯」註解前設定除錯。已有同名設定時請修改原值，避免重複定義：
- 將
define( 'WP_DEBUG', true );設為啟用。 - 加入
define( 'WP_DEBUG_LOG', true );，記錄錯誤。 - 設定
define( 'WP_DEBUG_DISPLAY', false );，避免公開顯示。
依 WordPress 官方除錯教學，儲存設定後再次操作，並記下 reproducing the problem（重現問題）的時間，方便透過 SFTP 或主機檔案管理員讀取 wp-content/debug.log 時比對。
對照發生時間、檔案路徑與錯誤行號，修正對應外掛或客製程式。若沒有產生紀錄，改查主機 PHP 錯誤日誌；這不代表 PHP 一定正常。
隱藏警告只是避免輸出干擾，仍須處理來源。修復後重試，確認回應不再混入錯誤文字，最後停用臨時除錯並妥善保存紀錄。
常見問題
管理員能儲存，作者卻失敗，怎麼處理？
使用同角色的測試帳號重現，查看是否出現 401、403 或權限錯誤。不要直接給予管理員權限，可先依非管理員編輯錯誤排查檢查 REST API 限制。
圖片上傳或 Elementor 更新失敗，也能照做嗎？
可以沿用查看請求與回應的方法，但端點可能不同。圖片可能使用 /wp-json/wp/v2/media，Elementor 操作也可能走 admin-ajax.php，應以實際失敗請求為準。
修復完成，要以內容確實保存為準
處理 WordPress 無效 JSON，最有效的起點是同一筆失敗請求的證據。修正後重新開啟文章，確認文字與圖片仍在，再測試前台和相關表單。
若需我們或外掛作者（Plugin Author）協助，請提供重現步驟、版本與失敗時間，並附上 Console 或 Network 的 screenshot（螢幕截圖）。分享前，請遮蔽 Cookie、授權標頭、個資與 API 金鑰，並恢復所有臨時停用的防護。