What matters first: The editor expected JSON from the WordPress REST API but received something else. The useful evidence is the failed request’s status, response body and final URL.
What this symptom actually tells you
This message is a wrapper around a failed REST exchange. It can be caused by routing, authentication, a firewall, PHP output, mixed site URLs or a server error, and each cause leaves a different response.
Capture evidence before changing anything
- Open browser developer tools and identify the failing /wp-json/ request.
- Record its HTTP status, response body, redirect chain and request method.
- Compare the Site Address and WordPress Address, including scheme and host.
- Check the PHP, web-server and security logs at the same timestamp.
Most common causes
- Rewrite failure: The REST route is not reaching index.php, often after a migration or server-rule change.
- Unexpected HTML output: A PHP warning, login page, maintenance response or WAF challenge is being returned instead of JSON.
- Authentication or nonce failure: Cookies, cached editor pages or a security layer can invalidate the request.
- URL mismatch: HTTP/HTTPS or www/non-www disagreement can redirect the API request away from its expected origin.
Safe diagnostic and repair sequence
- Request the failing REST URL directly and confirm whether it returns JSON or HTML.
- Fix the layer evidenced by the response: rewrite rules, URL configuration, PHP error or specific firewall rule.
- Purge page, object, browser and CDN caches so the editor receives a fresh nonce and route.
- Repeat the same save action while watching the network panel and server logs.
How to choose between the likely causes
Do not treat Rewrite failure and Unexpected HTML output as interchangeable. The REST route is not reaching index.php, often after a migration or server-rule change. By contrast, a PHP warning, login page, maintenance response or WAF challenge is being returned instead of JSON. Use two checks to separate them: Open browser developer tools and identify the failing /wp-json/ request; and record its HTTP status, response body, redirect chain and request method. Those observations usually show whether the next safe move is to request the failing REST URL directly and confirm whether it returns JSON or HTML or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not disable the REST API firewall or security plugin globally. Identify the exact blocked route or rule and keep unrelated protection active.
How to verify the repair
- The editor saves and updates the same post twice without an error.
- The REST request returns valid JSON with the expected success status.
- No PHP warning, redirect or WAF challenge appears in the response.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
This message is a wrapper around a failed REST exchange. It can be caused by routing, authentication, a firewall, PHP output, mixed site URLs or a server error, and each cause leaves a different response.
- 1
Open browser developer tools and identify the failing /wp-json/ request.
- 2
Record its HTTP status, response body, redirect chain and request method.
- 3
Compare the Site Address and WordPress Address, including scheme and host.
- 4
Check the PHP, web-server and security logs at the same timestamp.
What must be verified
- The editor saves and updates the same post twice without an error.
- The REST request returns valid JSON with the expected success status.
- No PHP warning, redirect or WAF challenge appears in the response.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Does this error mean my database is corrupted?+
No. This message comes from the block editor failing to parse the REST API response as JSON — it says nothing about the database. The response it received was HTML, a redirect, or an error page instead of JSON, so the fault sits in routing, authentication, PHP output, or a firewall, not in your data.
Why does the error appear only when saving certain posts, not all of them?+
If only specific posts trigger it, the cause is more likely a plugin hook, a large payload, or content that trips a WAF rule on that particular REST request, rather than a global rewrite or URL mismatch. Comparing a failing save with a working one on the same site narrows this down quickly.
Is it safe to just disable the REST API firewall to make the error go away?+
No. Disabling the REST API firewall or security plugin globally removes protection from every route, not just the one that is failing. Identify the exact blocked request and rule instead, and keep the rest of the protection active.
I fixed the Site Address and WordPress Address mismatch — why does the error still appear?+
A URL mismatch is only one of several possible causes; the others are rewrite failures, unexpected HTML output, and authentication or nonce failures. After correcting the URLs, purge page, object, browser, and CDN caches so the editor gets a fresh nonce and route, then retest while watching the network panel.