If WordPress suddenly refuses to save or publish and shows Updating failed. The response is not a valid JSON response., the editor is usually not the real problem. In most cases, WordPress is sending a background request and your server is returning the wrong thing back: an error page, a login redirect, a firewall block, a PHP warning, or a broken REST response. That is why random fixes such as installing Classic Editor or disabling security plugins sometimes appear to help, but do not actually solve the root cause.
For business owners, operations leads, and agency teams, the goal is simple: restore publishing safely without creating a bigger security or stability problem on a live site. Start with the lowest-risk checks first, confirm the real failure point, and only then change code or server settings.
What this error usually means
The modern WordPress editor depends on the REST API and JSON responses to create and update content. If that request is interrupted, rewritten, blocked, or polluted by extra output, WordPress reports a JSON error even when the underlying cause is something else entirely.
Common causes include plugin conflicts, incorrect site URLs or HTTPS settings, broken rewrite rules, security or CDN rules that block background requests, exhausted PHP memory, or debug output leaking into the response.
Start with the fast checks
- Open
Tools > Site Health. If WordPress reports REST API problems, loopback failures, blocked HTTP requests, or an active PHP session, solve those first. - Confirm
Settings > Generaluses the correct domain and protocol for bothWordPress AddressandSite Address. Mixed HTTP/HTTPS setups still cause a lot of publishing problems, especially after migrations or proxy changes. - Visit
Settings > Permalinks. WordPress flushes rewrite rules when that screen loads, and saving is a safe next step if URLs or rewrite behavior changed recently. - Load
https://yourdomain.com/wp-json/in the browser. You should see JSON, not a login page, a 403 page, or raw PHP warnings. If pretty permalinks are disabled, test?rest_route=/instead.
If /wp-json/ is broken, the editor error is only a symptom.
Do not jump straight to disabling everything
The old advice to install Classic Editor, disable Wordfence, and rename config files can get a post published, but it is a blunt instrument on a live site. Use those steps as diagnostics, not permanent fixes.
- If Classic Editor works while the block editor fails, that is a clue that the issue sits in REST/API behavior, not a reason to leave the site in fallback mode forever.
- If a plugin, theme update, or custom snippet was added recently, isolate that change first. Deactivate one suspect at a time, preferably on staging, and retest publishing after each step.
- If Wordfence is active, look for messages such as
Background Request Blockedor overly strict firewall behavior. Allowlisting a known-safe request or briefly using Learning Mode for testing is usually safer than leaving the firewall fully disabled. - Also check CDN and hosting WAF layers. Cloudflare challenges, host firewalls, and bot-protection pages often return HTML instead of JSON, which triggers this exact error.
If .htaccess was edited recently, review rewrite or security rules before deleting anything. On production sites, careful inspection beats blind renaming.
When memory really is the issue
Increasing memory can help, but only when memory is actually the constraint. If logs mention exhausted memory, or the failure appears on very large pages, heavy builders, or media-heavy posts, raise the WordPress memory limit first:
define( 'WP_MEMORY_LIMIT', '256M' );Add that line to wp-config.php before the /* That's all, stop editing! Happy blogging. */ line. Be aware that some hosts ignore this value and enforce limits at the PHP or account level, so a host-side change may still be required.
This is also the stage to review host-level PHP settings rather than deleting config files blindly. If custom limits are in play, check for mismatched memory_limit, post_max_size, or upload-related settings that are choking the request.
Turn on logging without exposing errors to visitors
If the quick checks do not reveal the cause, enable logging long enough to capture the failing response. Do this on staging first if you can, and take a backup before editing configuration.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Place this in wp-config.php before the final stop-editing comment, reproduce the error once, then inspect wp-content/debug.log. For agency teams, the browser Network tab is just as useful: inspect the failed save request and read the raw response. If you see HTML, a 403 page, a PHP notice, or a firewall challenge, you have found the real cause.
Turn debugging back off when finished. Leaving verbose logging enabled on a live site is poor operational hygiene and can expose information you do not want public.
When to bring in help
If your team is stuck between hosting, a security plugin, and a page builder, this is exactly the kind of issue that burns hours because each layer looks innocent on its own. A focused review can usually isolate whether the problem is REST routing, server configuration, plugin output, or firewall/CDN behavior and fix it without turning off half the stack.
If you want a second pair of eyes, Greg can step in, trace the failure path, and leave you with a cleaner WordPress setup rather than another temporary workaround.
Need help with this kind of work?
Need help tracing the real cause? Get in touch with Greg.