Unable to Post in WordPress? Fix the Invalid JSON Response Without Guesswork

By Greg Nowak. Last updated 2026-07-06.

When WordPress refuses to save or publish and shows Updating failed. The response is not a valid JSON response., the block editor is usually only reporting what went wrong downstream. It expected a clean JSON response from WordPress and received something else: a 403 page, a redirect, a login screen, a PHP warning, a firewall challenge, or a broken REST API response.

For business owners, operations leads, and agency teams, the practical goal is not to collect random fixes. It is to restore publishing without weakening security, hiding a server problem, or leaving the site on a temporary workaround. Work from the least disruptive checks toward deeper server and plugin diagnosis.

What the error actually points to

The modern WordPress editor saves and updates content through REST API requests. On a normal site, the REST API index should be reachable at /wp-json/. If pretty permalinks are not available, WordPress can route the same kind of request through ?rest_route=/. If either route returns HTML, an access-denied page, raw warnings, or a redirect to the wrong host, WordPress cannot treat the response as JSON.

That is why installing Classic Editor can appear to help. It changes the editing workflow, but it does not prove the underlying site is healthy. Treat it as a short diagnostic, not as the final fix.

Check	What you are looking for	Best next move
Site Health	REST API, loopback, PHP session, missing module, or debug warnings	Fix the reported platform issue before touching plugins broadly
REST API URL	Clean JSON at `/wp-json/` or `?rest_route=/`	If HTML or a 403 appears, inspect redirects, WAF rules, and server errors
Permalinks	Rewrite rules out of sync after a migration, SSL change, or host move	Save `Settings > Permalinks` once and retest
Network tab	The failed editor request and its raw response	Use the actual status code and response body to identify the blocking layer
Error logs	Memory exhaustion, fatal errors, PHP notices, or plugin output	Fix the specific error rather than masking it with broad deactivation

A safe triage order for invalid JSON response errors on a live WordPress site.

Start with checks that do not disturb the live site

Open Tools > Site Health first. Pay attention to REST API failures, loopback request failures, active PHP sessions, missing JSON-related modules, and debug logging warnings. These are often closer to the real issue than the editor screen itself.

Next, confirm Settings > General uses the correct domain and protocol for both the WordPress Address and Site Address. Mixed HTTP and HTTPS settings, old staging URLs, and proxy changes can all cause editor requests to land somewhere unexpected.

Then test the REST API directly:

curl -i https://example.com/wp-json/
curl -i 'https://example.com/?rest_route=/'

You want a successful response containing JSON. If you see a login page, a 301 chain to another domain, a hosting error, a bot-protection page, or PHP warnings before the JSON, the editor is not the root problem.

Be careful with plugin and firewall fixes

Disabling every plugin may be fast on a staging copy, but it is a risky first move on a revenue-generating site. If the issue appeared after a known update, start there. Test the most likely plugin, theme, snippet, page builder, security rule, or CDN change first, then retest publishing after each change.

If Wordfence or another security layer is involved, look for blocked background requests, strict firewall rules, and false positives around REST API endpoints. A short, controlled Learning Mode test or a specific allowlist entry for a verified safe request is usually better than leaving the firewall disabled. Also check host-level WAF rules and CDN bot protection. Any layer that returns HTML to an editor save request can trigger this exact message.

Only raise memory when logs support it

Memory can be the cause, especially with large pages, visual builders, heavy custom fields, or media-rich posts. But raising memory without evidence can hide a slow leak or plugin problem. Look for errors such as allowed memory size exhausted in the PHP log, WordPress debug log, or host dashboard.

If memory exhaustion is confirmed, add a WordPress memory limit in wp-config.php before the final stop-editing comment:

define( 'WP_MEMORY_LIMIT', '256M' );

Some hosts enforce memory at the PHP or account level, so this constant may not be enough. If the error continues, compare WordPress, PHP, and hosting limits rather than increasing numbers blindly.

Log the failure without exposing it to visitors

If the cause is still unclear, enable logging long enough to capture one failed save. Use staging when possible, and back up configuration before editing it.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reproduce the publishing error once, then inspect wp-content/debug.log and the failed request in the browser Network tab. Turn debugging back off when finished. Leaving logs and warnings exposed on a live site is poor operational hygiene and can leak details attackers do not need.

When to bring in help

The hard cases usually sit between layers: WordPress looks fine, the host sees no outage, the security plugin says it is protecting the site, and the agency only sees that publishing is blocked. A focused review can trace the request from editor to REST API to server response and separate the real cause from the symptoms.

If you want a practical second pair of eyes, Greg can help trace the failure path, fix the immediate publishing issue, and leave the site with a cleaner operational setup instead of another fragile workaround.