WordPress Revisions 101: Find, Restore, and Manage Old Versions Safely

You’ve probably landed here because WordPress changed on you and your stomach dropped a little. A paragraph is gone. A page looked better yesterday. Someone on the team clicked Update, and now you’re hoping WordPress revisions kept the version you actually wanted.

In a lot of ordinary editing accidents, they did.

TL;DR: Open the changed post or page, go to Revisions, compare the versions, and restore only when the whole older version is better. If you only need one paragraph, table, shortcode, or block back, copy that piece from the old revision instead of restoring the entire page. If the loss happened before you saved, check WordPress autosave first.

That’s the main judgment call. Revisions are excellent for post and page content. They’re not a full-site undo button. They won’t roll back a plugin update, rebuild a deleted media file, fix a theme setting, or clean up damaged database data.

Start small: check autosave, then revision history, then WordPress backups if the damage has moved beyond the editor. I wouldn’t disable revisions just because they create database rows. For most real sites, they’re too useful to throw away.

What WordPress revisions save

A WordPress revision is an older saved version of a post or page. When you save a draft, update a published post, or publish a page, WordPress can store that version under the original item so you can compare it later.

By default, revisions track the title and main editor content. They also keep author and excerpt data. In a WordPress 7.0 test site, a new draft post and draft page started with 0 revisions. After two saved updates, each showed 2 revisions. The saved records were attached to the original item, with the old title and content available for comparison. That matches the way revisions feel in the editor. They’re built for human content mistakes:

📝 Note: Revisions are strongest when the problem lives inside the editor. If the missing thing is an uploaded PDF, a plugin setting, or builder data stored somewhere else, revision history may only show part of the story.

Page builders deserve extra caution here. Some store layout data in custom fields or separate structures. You may still see a revision, but that doesn’t guarantee every visual setting will return exactly as it was. Restore to a staging copy if the page matters, or at least preview carefully before you treat the job as done.

How to find revision history in WordPress

Start with the item itself. WordPress revisions live with the post or page they belong to, so opening a nearby draft or a similar landing page won’t help much.

WordPress 6.9 and earlier may show the classic revisions screen instead. That view compares versions side by side and can compare any two revisions with two slider handles. The exact interface can also change if you’re using the classic editor, a builder, or a plugin that changes the edit screen. Don’t worry too much about matching a screenshot perfectly. You’re looking for the same thing either way: the saved version that explains what changed.

Restore a revision without losing newer work

The tempting move is to find the missing sentence and click restore. Sometimes that’s right. Sometimes it’s how you bring back an old price, an outdated headline, or a support instruction someone already fixed. Slow down for two minutes here. It’s annoying, but it’s cheaper than fixing the same page twice.

Restoring an older revision usually doesn’t erase all newer history. It makes that older content the current version, and you can often go back into revision history and choose a newer version again if you picked the wrong one. I still wouldn’t treat that as permission to click around casually. A live page with the wrong information is still live.

Copy from a revision when a full restore is too blunt

Most recovery work isn’t a full rollback. The current page is usually mostly right. You just need the missing block, shortcode, or paragraph back. Use revision history as a reference in that case.

Find the older version that contains the missing content. Copy only the part that still belongs on the page. Paste it into the current version, then read the surrounding section out loud enough to catch the joins. Old copy often needs one sentence adjusted so it fits the page as it exists now.

Be especially careful with prices, legal copy, product promises, and support steps. Old content can look familiar enough to feel safe and still be wrong. On team-edited sites, this is the recovery method I reach for most often. It protects the good work that happened after the revision you’re borrowing from.

Autosave helps with a different kind of loss

Autosave and revisions get confused because WordPress stores autosaves as a special type of revision. In practice, they answer different moments of panic.

Autosave protects the work you’re doing right now. If your browser crashes, your connection drops, or you close a tab too quickly, WordPress may offer a newer autosave when you reopen the post. That can rescue recent unsaved work.

Revisions preserve saved versions over time. They’re better when a published page changed yesterday, a draft was overwritten, or you’re comparing one saved edit against another. WordPress doesn’t keep creating endless autosave rows forever. WordPress.org documents a maximum of one autosave per user for a post. Newer autosaves replace older ones for that same user.

📝 Note: If the loss happened minutes ago, look for the autosave prompt before revision history. If the loss happened after someone clicked Update, revision history is usually the better place to start.

How many revisions WordPress keeps

By default, WordPress can keep every normal revision unless your site has a limit set. The setting most people run into is WP_POST_REVISIONS, usually added in the wp-config.php file.

Setting value	What WordPress does
true or -1	Keeps all normal revisions
false or 0	Stops normal revisions, except autosaves
A number like 5 or 10	Keeps that many revisions, plus autosaves

For most business sites, blogs, and content teams, I wouldn’t disable revisions. I’d keep them on and limit WordPress revisions if the database is getting heavy. Five revisions can be enough for pages that barely change. Ten gives busier posts and team-edited pages more room.

Make a backup before touching wp-config.php. If you need a checklist, backup your WordPress site first. That file is small, but a missing quote or misplaced line can take the site down.

📝 Note: Put the revision limit before WordPress loads its settings. In most wp-config.php files, custom constants belong near the end but still above the final “stop editing” comment. If that sounds uncomfortable, send the exact line to support or your developer instead of guessing in production.

Delete old revisions only when there’s a real reason

WordPress stores revisions in the database. More specifically, normal revisions live in the posts table as child records of the original post or page, with a revision post type and inherited status. On a tiny brochure site, that usually isn’t worth worrying about. On a busy publishing site with years of edits, the rows can add up enough that it becomes reasonable to delete old WordPress revisions.

The word reasonable is doing work there. A vague warning that revisions slow down WordPress isn’t enough by itself. Database size matters, but deleting recovery history has a cost too.

Why revisions may not show

If you don’t see the Revisions option, start with the boring causes. They’re common, and they’re much safer to check than the database. A brand-new draft may not have any revisions yet. In testing, a new draft post and page showed 0 revisions until follow-up changes were saved. Make a small real edit, save it, and check again.

If WordPress revisions are not showing after that, check whether WP_POST_REVISIONS is set to false or 0; if it is, enable revisions in WordPress before testing again. Autosaves still exist.

Your user role can also matter. Administrators and editors generally have broader access. Authors and contributors may only see revisions tied to their own content or drafts.

Look at the content type and editor next. Some custom post types don’t support revisions. Some builders hide the interface or store important layout data somewhere revisions don’t fully cover. The missing content may also live in a synced pattern or WooCommerce product screen rather than the post body you opened.

📝 Note: If revisions disappeared after a host migration or plugin change, don’t assume the content is gone. Check with your host, review recent plugin changes, and look at a staging copy before touching database tables.

Pick the right recovery path

When content is missing, start with the least risky place and only move outward when you have to.

That order keeps you from doing heavy recovery work when the answer is sitting in the editor. It also keeps you from pretending revisions can fix a problem they can’t see.

Don’t disable WordPress revisions by default

This is the part I wish more revision guides would say plainly: for most sites, disabling revisions is the wrong tradeoff.

Yes, revisions create database rows. But they also save ordinary editors from ordinary mistakes, and that matters. A database can be cleaned. A client page overwritten three hours before a campaign goes live is harder to explain. The better default is:

There are cases where disabling makes sense. Maybe content is generated through a custom system. Maybe a high-volume automated workflow stores version history somewhere else. Fine. But if real people are writing, editing, and publishing in WordPress, I want revisions available unless there’s a specific reason not to.

And if you do turn them off, tell everyone who edits the site. The worst time to learn revisions are disabled is after someone needs them.

Conclusion

WordPress revisions are one of those quiet features you don’t think about until the moment you need them. Keep them on. Learn where they live. Use them carefully when content changes go wrong.

Restore a full revision when the whole older version is better. Copy from a revision when you only need one piece. Use autosave for recent unsaved work. Bring in backups when the problem moves beyond post and page content.

That’s the setup I trust: revisions for everyday editorial mistakes, sensible limits for database hygiene, and full-site backups before risky changes. For agency workflows, test restores are a useful way to prove a backup works before anyone needs it.

FAQs

Are WordPress revisions backups?

No. Revisions help recover post and page content. Backups protect the wider site, including files, uploads, plugin changes, theme changes, and the database.

Can I restore only part of a WordPress revision?

Yes, but WordPress core doesn’t have a special partial-restore button. Open the revision, copy the content you need, and paste it into the current version manually.

Why can’t I see revisions in WordPress?

There may be no saved changes yet, revisions may be disabled, your role may not have access, or a plugin, builder, or custom content type may be changing how revisions work.

Do WordPress revisions slow down a site?

Not automatically. Revisions add database rows, and very large revision histories can contribute to database size. For most sites, limiting revisions is a better first move than disabling them; if the admin area is slow, diagnose slow WordPress admin screens separately.

Should I disable WordPress revisions?

Usually, no. Keep revisions enabled unless you have a controlled workflow, another version history system, and a clear recovery plan for editors.