WordPress saves a new revision on nearly every edit and autosaves separately every sixty seconds by default, and when those two systems aren’t behaving as intended — autosave conflicting with a manual save in progress, revisions accumulating without limit, an edit that appeared to save but then reverted — the result can look like content is randomly vanishing, when really it’s a specific, traceable interaction between these two saving systems. The panic this can cause is understandable, since a piece of writing that took real time to produce appearing to vanish feels far more alarming than the underlying, usually recoverable technical reality actually warrants.
Look in the revision history first
Read-only. Open the affected post and check its revision history, usually visible in the editor’s sidebar, to see whether the content you believe is missing actually exists in an earlier saved version.
Finding it there confirms nothing is genuinely lost, just not currently showing as the active version, which is a meaningfully different and more reassuring starting point.
Checking whether more than one person has been editing the same content recently is also worth a moment’s thought, since simultaneous editing is one of the more common triggers behind this exact symptom.
Revision & autosave misbehaviour fix
Revisions piling up excessively, autosave conflicting with manual saves, or edits appearing to vanish. We isolate the cause and correct it.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Autosave and manual saves conflict, or edits appear to vanish or revert | This fix covers it |
| Revisions have simply accumulated to a large number, without content actually vanishing | This fix covers it; that’s a related, addressable pattern |
| The block editor itself fails to load, separate from a saving issue | Block editor not loading – diagnosis, a different fix |
| Content is genuinely gone with no trace in revision history at all | A different, more urgent content-recovery conversation |
| The database itself is oversized, and revisions are one suspected contributor | Worth a broader database audit if revisions are just one part of the concern |
What you are seeing
- An edit that appeared to save successfully but later reverted to an older version
- Autosave conflicts appearing while editing, such as a warning about a newer autosave
- An excessive number of revisions accumulating for a single piece of content
- The issue happening more when multiple people edit the same content
- Confusion over which saved version is actually the current, correct one
Common causes
- Two people editing the same content simultaneously, triggering a save conflict
- A slow or interrupted connection causing autosave and manual save to overlap incorrectly
- No limit set on the number of revisions WordPress retains per post
- A caching or security plugin interfering with the save request itself
- Browser-level autosave data conflicting with the server’s own saved version
What we do
- Reproduce the saving behaviour and identify the specific conflict pattern
- Recover any content sitting in an unintended revision rather than the active version
- Correct the underlying cause, such as a plugin conflict or an editing workflow issue
- Set a sensible revision limit to prevent unlimited future accumulation
- Confirm saves complete reliably and predictably afterward
- Advise on workflow adjustments if simultaneous editing is a recurring factor
What is included
- The specific saving conflict identified and corrected
- Recovery of any content found sitting in an unintended revision
- A sensible revision limit configured to prevent future unlimited accumulation
- The pre-fix backup, kept for 30 days
Not included
- Recovering content with no trace in any revision history at all
- A broader database size audit beyond this specific saving behaviour
- Building a formal editorial workflow for multiple simultaneous editors
- Ongoing monitoring of saving behaviour after the fix is delivered
Questions about this fix
Is my content actually lost, or just sitting in a different revision?
In the vast majority of cases it's sitting in a revision rather than genuinely gone, which is exactly the first thing we check before assuming anything is unrecoverable.
Why does this happen more when two people edit at once?
WordPress's saving system isn't designed for true simultaneous multi-user editing on the same post, so two people saving close together can each unknowingly overwrite the other's version.
Will limiting revisions delete history I might want later?
We set a sensible limit going forward rather than deleting your existing history outright, and can discuss what limit makes sense for how you actually use revisions.
Could a plugin really interfere with something as basic as saving?
Yes, particularly security or caching plugins that inspect or modify requests, which can occasionally interfere with the specific request WordPress uses to save content.
Will this fix prevent all future saving issues?
It resolves the specific cause found this time — an unrelated, different cause in future would need its own diagnosis, though a sensible revision limit reduces one common contributing factor going forward.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.