“Updating failed” is one of the most unhelpful error messages in WordPress. It tells you almost nothing about what actually went wrong — the cause could be anywhere from a misconfigured security plugin to a corporate firewall two networks away. I’ve chased this one down more times than I’d like, and I’ve settled into a specific order I check things in now instead of guessing.

Step zero: look at what actually failed

Before touching any plugin settings, open your browser’s DevTools — press F12, or right-click the page and choose “Inspect” — and click the Network tab. Then try to save the post again. Watch for a request to something under /wp-json/wp/v2/posts/<id>. That’s the block editor talking to WordPress’s REST API, a behind-the-scenes messaging system the editor uses to actually save your content. Its response is where the real error lives. The “Updating failed” message on screen is just a generic fallback the editor shows when that request doesn’t come back cleanly.

Click that request and check two things:

• Status code — a 403 usually means something is actively blocking or rejecting the request (permissions, a security plugin, a firewall). A 500 usually means a PHP error happened on the server while saving, often triggered by a plugin. A 0, or a red/failed entry with no status at all, often means the request never even reached the server — caused by DNS issues, mixed content, an ad blocker, or a proxy silently dropping it.
• Response body — even a 403 often includes a small JSON message with a code field, something like rest_cannot_edit or rest_forbidden. That tells you whether WordPress itself rejected the request, or whether something sitting in front of WordPress did.

Also glance at the Console tab for JavaScript errors unrelated to the network request. A broken script from a plugin or theme can sometimes stop the save button from working at all — no network request ever gets sent, but it looks identical to a failed save from the outside.

1. The REST API is blocked

This is the single most common cause I run into. The block editor depends entirely on the REST API to function. If anything blocks or rejects requests to /wp-json/, saving breaks immediately, and often the whole editor fails to load properly in the first place.

Common culprits:

• A security plugin (Wordfence, iThemes Security, and similar) with a rule that blocks or rate-limits REST API requests — especially a “block XML-RPC and REST API for non-logged-in users” style setting that’s accidentally misconfigured to catch logged-in editing too.
• A hand-added rule in your site’s .htaccess file blocking /wp-json/, sometimes added years ago to “harden” the site and forgotten about since.
• A dedicated “disable REST API” plugin or code snippet, often added for SEO or security reasons without realizing the block editor needs that same API to function.

Quickest test: visit https://yoursite.com/wp-json/ directly while logged out. You should see a page of JSON data — a kind of index of what the API offers. If you get a 403 error or a blank response instead, something is blocking the API outright, and that’s your answer. If you want to lock the REST API down deliberately rather than by accident, see my post on disabling the REST API without breaking the block editor — it covers how to restrict it safely instead of blocking it wholesale.

2. A plugin is filtering REST requests and rejecting yours by mistake

Some plugins hook into WordPress’s REST authentication system to add custom checks or restrict access. A bug, or an overly broad condition, in one of these can end up rejecting perfectly legitimate editor requests. This tends to show up right after a plugin update quietly changes its default REST behavior.

To isolate it, deactivate plugins one at a time — starting with security plugins, caching plugins, and anything with “API” or “firewall” in its name — and retest the save after each one. If you can’t safely deactivate plugins on your live site, do this on a copy first. My post on setting up a staging site on shared hosting walks through exactly that.

If you have a developer available, here’s a small snippet they can drop in to log the actual cause instead of guessing at it:

// Quick diagnostic snippet for mu-plugins -- logs REST errors instead of guessing.
// Remove this once you've found the cause.
add_filter( 'rest_authentication_errors', function( $result ) {
    if ( is_wp_error( $result ) ) {
        error_log( 'REST auth error: ' . $result->get_error_code() . ' - ' . $result->get_error_message() );
    }
    return $result;
}, 999 );

3. A firewall is blocking the save request itself

If you’re on shared hosting, or your site sits behind a service like Cloudflare or Sucuri, there’s often a security layer called a WAF (web application firewall) checking every request before it reaches WordPress. A WAF can flag the data the block editor sends as suspicious — this happens more than people expect when a post contains certain HTML patterns, script-like text inside a code block, or just a lot of content that trips a generic security rule.

Signs this is what’s happening: the failed request shows a 403, but the response body looks like a plain hosting-provider block page rather than WordPress’s usual JSON error format. It also often correlates with specific content — try saving a trivial test post with no special characters, and see if that one goes through fine.

Ask your host to check their firewall logs for the exact time of a failed save. They can usually tell you which specific rule fired, and often whitelist that rule for your site or for the /wp-json/ path specifically.

4. Browser extensions

Ad blockers, privacy extensions, and “clean URL” tools can sometimes intercept or strip requests that resemble tracking calls — and REST requests with query strings occasionally get caught in that net by mistake. Try saving in an incognito or private window with extensions disabled. If it saves fine there, you’ve found your culprit. No server-side fix needed — just note which extension it was so you can whitelist your own admin address in it going forward.

Order I actually check things in

1. DevTools Network tab — get the real status code and response body first, always.
2. Visit /wp-json/ logged out to rule out a blanket REST block.
3. Try incognito with extensions off.
4. Deactivate security and caching plugins one at a time, on staging if possible.
5. Ask the host to check firewall logs if it’s a 403 with no WordPress-style error body.

Skipping step one and jumping straight to “let’s deactivate plugins” wastes time. The actual status code and response body almost always point you straight at the right category before you touch anything.

Frequently Asked Questions About “Updating Failed” Errors

Do I need a developer to fix this myself?

Not necessarily, at least for the diagnosis. Checking the Network tab, visiting /wp-json/, and trying incognito mode are all things a non-technical site owner can do. Once you narrow it down to a specific plugin conflict or a firewall rule that needs adjusting, that’s usually a good point to bring in a developer or contact your host.

Is my content actually lost when I see “Updating failed”?

Almost never. WordPress autosaves your draft locally in the browser as you type, so the content you were working on is typically still sitting in the editor even after a failed save. Copy it somewhere safe before reloading the page, just to be cautious, but you haven’t lost your work outright.

Why does this happen right after I install a new security plugin?

Security plugins often ship with REST API restrictions turned on by default, aimed at stopping outside attackers from probing your site through /wp-json/. The trouble is that the block editor uses that same API for logged-in editing, so an overly broad rule can catch your own saves in the crossfire.

Will disabling my security plugin to test this leave my site vulnerable?

Briefly, yes, so only do it long enough to confirm the cause, ideally on a staging copy rather than the live site. Once you’ve identified which plugin or rule is responsible, you can usually adjust just that one setting rather than leaving the whole plugin off.

What if incognito mode and every plugin test come back clean?

At that point the cause is likely sitting outside WordPress entirely, in your hosting environment’s firewall. That’s the moment to hand your host the exact timestamp of a failed save and ask them to check their own logs, since that’s data only they can see.