When WordPress says publishing failed because the response is not valid JSON, inspect the response to the actual save request. The editor may have received a login page, firewall page, PHP warning, empty response, or unexpected redirect instead of the expected API data. The banner identifies a parsing failure, not its cause.
First preserve your unsaved content in a secure draft location. Avoid repeated publishing attempts until you check whether an earlier request already saved it. A failed browser response does not prove the server made no change.
Capture one save attempt
Open browser developer tools, select Network, and reproduce once. Find the request triggered by Save or Publish. Record its route, method, timestamp, status, response content type, and a redacted description of its body.
Do not copy cookies, nonce values, authorization headers, or unpublished content into a public ticket. A full network export can contain all of them. The host usually needs the route and timestamp before it needs any private payload.
Classify the response before changing settings
| Response evidence |
Investigate |
| HTML login page or redirect |
Expired session or wrong host |
| HTML 403/challenge |
Hosting, WAF or security rule |
| HTML 404 |
Route or server rewrite mismatch |
| PHP warning before JSON |
Unexpected application output |
| Valid JSON error object |
Its error code, capability or validation |
The REST authentication handbook explains that dashboard requests use cookies and a REST nonce, with the appropriate user capability still required. Do not remove those checks to repair a save.
Evidence guide for this investigation. Record your own observations; the fields are not test results.
Follow the matching path
For a session problem, preserve the draft, sign in again through the correct admin hostname, and retry on a fresh editor page. Check whether a proxy or canonical redirect changed the request destination. WordPress installation and public addresses can legitimately differ in some setups, so do not blindly force both fields to the same value.
For a 403, use the REST API WAF guide and match the exact request to the rule log. Keep the exception narrow and verify unauthorized requests remain denied. A public GET to the API index cannot prove an authenticated POST save is allowed.
For a 404, compare the failing route with the site's server configuration and permalink routing checks. Do not reset the full web-server configuration to repair one route.
For unexpected PHP output, capture the underlying error in a private debug log. Suppressing display can protect API formatting, but the component producing the warning or fatal error still needs investigation.
Prove persistence, not just a green notification
Save a harmless revision on staging, reload the editor, and confirm the expected content persisted. Check the public result when appropriate. Test with the role that originally failed, since an administrator's capabilities can hide an editor-specific problem.
Retest a second affected content type or widget operation if the same endpoint serves it. Keep the original response classification and repaired result in the incident record.
HandL WP can trace the failed save across the editor, API, and hosting layers. Bring the route, time, and redacted response shape so the fix targets the actual failure instead of replacing the editor as a workaround.
Sources checked September 30, 2026. Examples and visuals are explanatory, not customer measurements.