Table of contents
You hit Update, and instead of "Post updated" you get: "Updating failed. The response is not a valid JSON response." Your changes may not have saved, and the message tells you nothing about why. Here's what's actually happening — and the fixes, in the order they most often work.
The block editor saves posts through the WordPress REST API and expects JSON back. This error means the server sent back something else — an error page, a redirect, or a firewall block screen. Most cases are fixed in under two minutes by going to Settings → Permalinks and clicking Save Changes (no edits needed). If that doesn't do it: check that both URLs in Settings → General use https://, then look for a security plugin or firewall (Wordfence, Cloudflare, ModSecurity) blocking /wp-json/.
Why this error happens
Every time you save, update, or publish in the block editor, WordPress sends your content to the server through the REST API — the endpoints under yoursite.com/wp-json/. The server is supposed to reply with structured JSON data confirming the save.
The error means the reply was not JSON. Something intercepted the request or the response:
- Broken permalinks / .htaccess rules — the request to
/wp-json/gets a 404 page instead of the API (the single most common cause) - A security plugin, WAF, or hosting firewall blocking REST API requests as "suspicious"
- Wrong Site Address (HTTP vs HTTPS) — the request gets redirected, and the editor receives the redirect page instead of JSON
- A plugin or theme PHP error injecting warnings or an error page into the response
The fixes below are ordered from most common and easiest to least common. Work down the list — most people never get past fix 2.
Copy your post content somewhere safe (select all → copy into a text file) before troubleshooting. The error usually means the save failed, so anything unsaved lives only in your browser tab.
First: diagnose with Site Health and a REST API test
Two quick checks tell you whether the REST API is reachable at all — and often name the culprit outright.
Go to Tools → Site Health in your dashboard. Look for a critical issue or recommendation that says "The REST API encountered an error" or "The REST API encountered an unexpected result." Expand it: WordPress often shows the exact response it received — a 403 Forbidden points at a firewall or security plugin, a 404 Not Found points at permalinks/.htaccess, and a cURL error points at your server or DNS. Our Site Health walkthrough covers the tool in more depth, and there's a companion guide to the Health Check plugin for deeper troubleshooting.
In a new browser tab (while logged in), visit yoursite.com/wp-json/. A healthy site returns a wall of raw JSON starting with {"name":"Your Site Name".... If you instead see a 404 page, a "blocked" screen from a security plugin or Cloudflare, or a plain HTML error, you've confirmed the API is being intercepted — and what you see tells you which fix below to jump to.
Fix 1: Flush your permalinks (fixes most cases)
WordPress routes REST API requests through the same rewrite rules as your pretty URLs. If those rules are stale or your .htaccess file is broken — common after a migration, a plugin change, or a hosting move — requests to /wp-json/ land on a 404 page, which is HTML, not JSON. Re-saving permalinks rebuilds the rules and regenerates .htaccess.
Go to Settings → Permalinks in your WordPress dashboard.
Scroll down and click Save Changes. You don't need to alter the structure; the act of saving flushes the rewrite rules and rewrites .htaccess.
Go back to your post and click Update. For a large share of sites, the error is already gone.
If saving permalinks doesn't help and you're on Apache/LiteSpeed, connect via FTP or your host's file manager, rename .htaccess to .htaccess-old, then save permalinks again to generate a clean file. Also check the file's permissions are 644 so WordPress can write to it.
Fix 2: Correct your Site Address (HTTP vs HTTPS)
This is the classic cause right after installing an SSL certificate. If Settings → General still lists your WordPress Address or Site Address as http://, the editor sends its save request to the http URL, your server responds with a redirect to https, and the editor receives a redirect page — not JSON. Mismatched URLs (with/without www, old domain after a migration) fail the same way.
Go to Settings → General. WordPress Address (URL) and Site Address (URL) should both start with https:// (assuming you have SSL) and match your real domain exactly — same www or non-www throughout.
Correct either field if needed and click Save Changes. You'll be logged out and asked to log back in — that's normal.
Clear any caching plugin and your browser cache, then try updating a post again. If some page assets still load over http, run a search-and-replace to fix mixed content — many SSL plugins do this for you.
Fix 3: Unblock the REST API in your security plugin or firewall
Security plugins (Wordfence, iThemes/Solid Security, All In One WP Security), Cloudflare's WAF and Bot Fight Mode, and server firewalls like ModSecurity all sometimes flag legitimate /wp-json/ requests as attacks. When they block one, the editor gets a 403 Forbidden block page — which is exactly the "not valid JSON" response the error complains about.
Open your security plugin and look for options like "Disable REST API," "Block REST API for non-logged-in users," or REST-related rules in its firewall log. Temporarily relax or whitelist the REST API, then test a save. If that fixes it, re-enable protection but add an exception for logged-in users on /wp-json/wp/v2/.
In the Cloudflare dashboard, open Security → Events and look for blocked requests to /wp-json/ around the time your save failed. If you find them, create a WAF exception (skip rule) for /wp-json/* for logged-in traffic, and make sure SSL/TLS mode is set to Full (Strict) — the "Flexible" mode causes redirect loops that also break JSON responses.
If nothing in your own tools is blocking the API, your host's ModSecurity or WAF may be. Send them the exact time of a failed save and ask them to check the firewall log for blocked POST requests to /wp-json/ — they can whitelist the rule that's misfiring.
Fix 4: Find the conflicting plugin or theme
A plugin with a PHP error can spray warning text into every server response. The editor receives Warning: ... text glued onto the front of the JSON — which makes the whole response invalid. Deactivating plugins one by one isolates the offender.
Go to Plugins → Installed Plugins, select all, and choose Deactivate from the bulk actions menu. Then try updating a post. (On a busy live site, do this in a staging copy, or use the Health Check plugin's Troubleshooting Mode, which disables plugins only for you.)
If the error is gone, reactivate plugins one by one, testing a save after each. The save that fails again names your culprit. Update that plugin first — the bug may already be fixed — otherwise replace it or report it to the developer.
If no plugin is to blame, switch temporarily to a default theme (Twenty Twenty-Four or newer) under Appearance → Themes and test again. If that fixes it, your theme needs an update or a developer's attention.
When a fatal plugin error breaks the whole admin, WordPress emails you a special login link. That's Recovery Mode — it lets you log in with the failing plugin paused so you can deactivate it safely.
Fix 5: Dig deeper with debug logging and your host
If you've made it this far, the cause is server-side and site-specific. Two more tools will surface it.
Add these lines to wp-config.php, just above the /* That's all, stop editing! */ line:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reproduce the failed save, then read wp-content/debug.log. A PHP fatal error or warning logged at that moment usually names the exact file and plugin responsible. Turn WP_DEBUG back to false when you're done.
Give your host the timestamp of a failed save and ask them to check the PHP error log and any WAF/ModSecurity logs for that request. Also confirm you're on a supported PHP version — WordPress 6.x runs best on PHP 8.1 or newer, and very old PHP versions cause exactly this kind of API failure.
Temporary workaround: the classic editor (not a fix)
If you need to publish right now and the fixes above have to wait, install the official Classic Editor plugin. It saves posts through the traditional wp-admin form submission instead of the REST API, so it usually works even while /wp-json/ is blocked. You can also keep using the block editor and drop a Classic block into it for old-style editing.
A blocked REST API breaks more than the editor: plugins, the mobile app, scheduled actions, and Site Health checks all rely on it. Use the classic editor to get your post out, then come back and finish the diagnosis.
Still stuck?
This error has a short list of causes, but pinning down which one on a live site — reading firewall logs, testing /wp-json/, isolating a plugin — is much faster with a second pair of eyes. It's exactly the kind of problem we fix live, on your own site, in one-on-one tutoring sessions.
Leave a comment