WordPress Updating Failed: Why Your Page Won't Save

The timetable took most of a Sunday evening. Six weeks of autumn classes, a price beside each one, and a booking widget pasted in from the scheduling service so parents could reserve places without ringing. She clicked Update. A bar appeared at the foot of the editor: Updating failed. The response is not a valid JSON response.

She clicked Update again. Same bar. Third time, same bar. So she closed the laptop, told herself she would sort it in the morning, and opened the page on her phone over breakfast. Last term's timetable looked back at her. Every change from the night before was gone.

That owner runs a cookery school in Leitrim. She is a composite, not one real person, built from a pattern that turns up whenever a new term or season opens; the details are invented, the sequence is not. Her evening is the thread through this piece, because that one sentence is how most owners first discover that the editor and the server have stopped talking.

It looks as though WordPress is broken. Almost always, it is not. In most cases you can work out which of four things went wrong without ringing anyone, and you can make sure you never lose an evening's work to it again.

Before Anything Else, Protect What You Typed

She lost her work at the moment she closed the laptop, not when the error appeared. Up to then, every word was still sitting in the editor.

So the first move, before any troubleshooting, is to get a copy of the page somewhere WordPress cannot lose it. Open the Options menu (the three dots at the top right of the editor), switch to the Code editor, select everything, and paste it into an email to yourself or a plain note. When the fault is fixed, paste it back into the Code editor and the page reappears exactly as you left it, widget and all.

Why not rely on autosave? Because autosave is a save. WordPress's own documentation on revisions explains that it keeps one autosave per user for each page, and that autosaves never overwrite published content. Sensible design. But if the server is refusing your saves, it is refusing your autosaves too, for exactly the same reason.

The browser backup, and its limits

What does survive, sometimes, is a copy the editor keeps inside your browser. Reload the same tab and WordPress will often show a notice reading "The backup of this post in your browser is different from the version below", with a button to restore it. Use it. Read the restored version before you go any further, because it replaces whatever the editor was showing.

Now the honest part. That backup lives in that browser, on that device, and usually only in that tab. Close the tab, pick up your phone, or clear your browsing data, and it is gone. It is a safety net with holes in it, which is precisely why the thirty-second copy into an email is worth doing every single time.

What the Message Is Actually Telling You

The WordPress REST API handbook describes the REST API as "the foundation of the WordPress Block Editor". In plain terms, every time you click Update, the editor packs your page up, sends it to your server in the background, and waits for a short, structured reply in a format called JSON confirming that the save worked.

"Not a valid JSON response" means a reply did come back, but it was not that reply. Something else answered. Usually it is one of these:

a security filter's "request blocked" page
a redirect to a slightly different version of your web address
a login page, because WordPress no longer believes you are logged in
a "page not found", because the address the editor uses has gone missing
an error message printed by a plugin

So what does that mean for you? Your content is almost certainly fine. The conversation carrying it is what broke, and fixing it is a matter of finding out who interrupted.

Same fault, different wording

If the page has never been published, the editor says Publishing failed instead, followed by the same explanation. Same cause. The stakes are slightly higher, because a page that has never been saved exists only in your browser, so copy it out first.

A third version reads Updating failed. You are probably offline. This is the opposite problem: the request never reached your server at all. Patchy wifi, a phone dropping to one bar of signal, a VPN switching itself off. Reconnect, click Update again, and it will normally go through, because your work is still sitting in the editor.

The editor sent your page. Something other than WordPress sent the reply.

The five messages at a glance

What the editor says	What it usually means	Your first move
Updating failed. The response is not a valid JSON response.	Something other than WordPress answered the save	Copy your work, then check the four causes below
Publishing failed. The response is not a valid JSON response.	The same fault on a page that has never been saved	Copy first, because the page exists only in your browser
Updating failed. You are probably offline.	The save never reached your server	Reconnect and click Update again
Someone else is currently editing	Another login holds the lock on this page	Find out who before you take over
The backup of this post in your browser is different from the version below	Your browser holds a newer unsaved copy	Restore it, then read it before saving

Four Reasons the Save Gets Interrupted

1. A security filter mistook your page for an attack

Go back to that booking widget. It was a block of code copied from the scheduling company and pasted into the page, and that is a textbook trigger.

Web application firewalls read what you send to the server and block anything that looks like an attack. The OWASP Core Rule Set, the open-source rulebook behind many of those firewalls, uses WordPress as its own worked example of a false alarm. Its documentation explains that because WordPress lets you put HTML into a post, a perfectly genuine save can match a cross-site scripting rule at its stricter settings, and the request "may be blocked". The firewall cannot tell your booking widget from someone trying to inject code into your site. It sees script, it shuts the door, and the editor receives a block page instead of a JSON reply.

The test is simple. Take out the most recent embed, script or chunk of pasted code, and click Update. If the page saves, you have found your culprit.

What happens next matters more. The worst fix I see, and I see it far too often, is switching off the security plugin or firewall to get one page saved and never switching it back on. That trades one evening's inconvenience for a site with its guard down indefinitely. The right fix is for whoever runs the firewall to look up exactly which rule fired and exempt that rule for that action. That is a host's job, not yours.

2. Your site's two addresses disagree

Under Settings, then General, WordPress keeps two addresses: the WordPress Address and the Site Address. The WordPress documentation for that screen says the Site Address is identical to the WordPress Address unless WordPress has been installed in its own folder, which is unusual on a small business site.

They drift apart after a move. A site switched from http to https, a new domain connected, a www added or dropped. When one address starts with http and the other with https, the editor's background request gets bounced from one to the other, and a redirect is not a JSON reply.

Look at those two boxes. If they match each other and match the address in your browser bar, move on. Where they do not, resist the urge to correct them on a hunch. A wrong value in either field can lock you out of your own dashboard, and if the boxes are greyed out, the values are set in a configuration file only your host should touch. Take a screenshot and send it to your host instead.

3. A plugin is answering on WordPress's behalf

Plugins sit in the path of every request your site handles. One that prints a warning or error at the wrong moment corrupts the editor's reply. Some security and "hardening" plugins go further and offer a switch to restrict the REST API entirely. The WordPress REST API FAQ is blunt about that: "You should not disable the REST API; doing so will break WordPress Admin functionality that depends on the API being active."

The standard advice is to deactivate plugins one at a time until the save works. That advice is correct, and risky on a production site. Deactivate the booking plugin on a weekday morning to test a theory, and the booking form vanishes for every parent who visits while you test. Run the experiment on a copy instead: a staging environment gives you a private duplicate of your site where switching plugins off costs nothing. Find the conflict there, then deploy the one change to production.

If you look after updates yourself, this is also the moment to verify whether a plugin updated in the last day or two. The timing of an error against your last update is the most useful clue you have, and the habits in our guide to updating your WordPress site yourself without breaking anything make that clue easy to read.

4. Your login went stale, or someone else holds the page

Long editing sessions end in two quiet ways.

One is an expired login. If WordPress no longer trusts your session, the editor's background request gets a login page back. Usually WordPress catches this and shows a log-in box over the editor. Log in there, in that box, rather than in a new tab, and your work stays where it is.

The other is a lock. WordPress lets only one person edit a page at a time, and the developer reference for its lock check shows a default window of 150 seconds: if someone else's open editor has checked in within that time, WordPress tells you they are currently editing and offers to let you take over. Taking over pushes them out. Before you click it, find out who it is. A staff member halfway through a price change will lose their edits, and if everyone in the business shares a single login, WordPress cannot even tell you whose work you are about to overwrite. Separate logins for separate people fixes that, and it is good security practice anyway.

How to Rescue a Failed Save in Five Steps

Preserve. Switch to the Code editor, copy everything, and paste it into an email to yourself before you touch anything else.
Verify the connection. If the message says you are probably offline, reconnect and click Update again.
Isolate. Remove the most recent embed or pasted code and try saving; if that works, send the code to your host.
Reset. Go to Settings, then Permalinks, and click Save Changes without changing anything, then try the page again.
Escalate. Screenshot the error and the two addresses under Settings, then General, and send both to your host with the page name and the time it happened.

Step four sounds odd, but WordPress's guide to common errors recommends resetting permalinks through Settings, then Permalinks, when addresses on a site start returning "not found". The editor saves through the same address rules, and a resave with no changes rebuilds them without altering anything your visitors see.

Preserve, verify, isolate, reset, escalate. In that order.

When It Is Your Host's Job

Steps three and five end with your host for a reason. A security block, an address fixed in a configuration file, a server answering with an error: those live on the server, and you cannot see them from the dashboard.

Without the right support, it goes like this. You send the ticket on Sunday night. Monday brings a reply telling you to clear your cache. Tuesday brings a request for your password. By Wednesday the timetable is still last term's, and the parents who looked on Monday have booked the Saturday class in the next town.

A host worth paying for, at any price, should pass four tests when a save is blocked:

Security at the server level, run by people who can read it. When a rule fires, they look up which one and why, instead of telling you to switch protection off.
A safe place to experiment. A staging copy where plugin conflicts can be found without customers watching.
A way back. Backups taken automatically, including before changes, so a rollback takes minutes rather than a rebuild from memory.
A person who answers. Someone who knows WordPress, working in your timezone, reading your actual screenshot.

Web60 is built around exactly those tests. Sites run with server-level security hardening, fail2ban intrusion prevention and automatic malware scanning. One-click staging environments sit in the dashboard. Backups run nightly with one-click restore, and safety snapshots are taken automatically before updates and restores. Support comes from an Irish-based team of real people, not an outsourced queue, and all of it sits inside the €60 a year.

There is a fair limit to that. If your site has a team of editors working through a formal approval workflow, with a developer on staff who wants to write and tune their own firewall rules site by site, premium managed WordPress providers that hand over that level of control genuinely suit the job better. That is a different business from a cookery school with one person updating the timetable.

Why Building It Yourself Helps Here

The cookery school owner knew exactly what she had changed, because she had made the change herself. When the save failed, the answer to "what is different about this page?" was in her own memory: the widget pasted in an hour earlier. That is the case for running your own site, in miniature. W3Techs' figures this month put WordPress on a little under four in ten of all websites, and AI builders have removed the last real reason an owner needed a developer to get one started. If you have not tried that yet, see how an AI builder creates a WordPress site you can edit yourself.

Conclusion

"Updating failed" reads like a verdict on your page. It is really a report about a conversation: the editor asked the server to save, and something else answered. Once you see it that way, the sequence follows. Copy the page somewhere safe. Check the connection. Strip out the newest pasted code. Resave permalinks. Then hand the screenshot to someone who can see the server.

Five minutes of that would have put the cookery school's timetable in front of parents on Monday morning. Next time that bar appears at the foot of your editor, your work is still yours to keep, and you already know where to look first.

Frequently Asked Questions

What does the WordPress not a valid JSON response error mean?

It means the editor sent your page to the server to be saved and got back something other than the short confirmation it expected. Usually a security filter blocked the request, the site redirected it to a different version of your address, a plugin printed an error, or WordPress thought you were logged out. Your content is normally still in the editor, so copy it somewhere safe before you start troubleshooting.

Will I lose my changes if WordPress says updating failed?

Not if you keep the tab open. Your changes stay in the editor until you close or leave the page, so copy them out through the Code editor before you troubleshoot. WordPress may also offer a backup kept in your browser when you reload the same tab, but that copy usually disappears if you close the tab, switch device or clear your browsing data.

Why does WordPress say publishing failed on a new page?

Publishing failed is the same fault as updating failed, shown when the page has never been published. The causes and fixes are identical. The difference is that an unsaved new page exists only in your browser, so copying it out first matters even more.

Can a security plugin or firewall stop WordPress saving pages?

Yes. Firewalls inspect what you send to the server, and pasted embed codes, scripts or unusual HTML can look like an attack. The OWASP Core Rule Set documentation uses WordPress posts containing HTML as its own example of a false positive. Remove the most recent pasted code and try again. If the page saves, ask whoever runs the firewall to exempt that specific rule rather than switching security off.

Should I install the Classic Editor to get around the error?

It can sometimes let a page save, because the older editor sends your work to the server in a different way. But it hides the cause rather than fixing it, and a firewall that objects to your content will usually still object. Find out what interrupted the save first. If the fault turns out to be on the server, your host should fix it there.

WordPress Updating Failed: Why Your Page Won't Save and How to Fix It