WordPress revisions: how to use and control them

Short answer: WordPress automatically saves a snapshot of every post or page each time you click Update. Open any post in the editor, click the Revisions link in the right sidebar (under the Post panel), and you can compare versions side by side or restore an older one. If you want to limit how many revisions pile up, add define('WP_POST_REVISIONS', 10); to wp-config.php .

That covers the immediate “how do I get back what I just overwrote” question. The rest of this guide covers how revisions actually work, why unlimited revisions bloat the database over time, how to clean up old ones, and the autosave interval that runs alongside revisions.

What a WordPress revision actually is#

Every time you save a post or page, WordPress writes a copy of the content to the wp_posts table as a new row with post_type = 'revision' . The revision stores the full post title, content, excerpt, and a pointer back to the original post. Nothing special – it is just another row in the same table your published posts live in.

Two things create revisions:

• Manual saves. Each click of Save Draft, Update, or Publish creates a revision of the state that was just saved.
• Autosaves. WordPress autosaves every 60 seconds while you are editing. Autosaves are stored as a single “autosave” row per user per post – they overwrite each other rather than accumulating.

The distinction matters: manual revisions stack up forever (unless you limit them), autosaves do not.

How to access the revisions screen#

In the block editor:

1. Open any post or page in edit mode.
2. In the right sidebar, click the Post tab (not Block).
3. Scroll to the Revisions panel. It shows the revision count – for example, “Revisions 12.”
4. Click the revision count to open the full revisions screen.

In the classic editor, the Revisions panel is at the bottom of the post edit screen.

On the revisions screen, you see:

• A slider at the top – drag it to move through every saved revision.
• Two columns of text – the older version on the left, the newer version on the right, with added content highlighted in green and removed content in red.
• A Compare any two revisions toggle – enable it to get two sliders so you can compare non-adjacent revisions (useful for “what did I change two weeks ago”).
• A Restore This Revision button – restores the selected version as the current state of the post. The current version becomes another revision, so you can always undo the restore.

The restore is not destructive. You do not lose the version you restored from – it just becomes the next revision in the chain.

Who can see and use revisions#

Users with the Editor or Administrator role can access revisions for any post. Authors can access revisions for their own posts. Contributors can see revisions of their own unpublished drafts. Subscribers do not have edit access, so revisions are not relevant for them. WordPress user roles and user management covers the full role breakdown if you need to adjust who can roll back content.

Why unlimited revisions are a problem#

Every revision is a full copy of the post content. If a post is 5,000 words and you have 100 revisions, that is 100 copies of 5,000 words sitting in wp_posts . Multiply that across every post on the site, over years, and the table gets enormous.

What this actually costs:

• Database size. A site with a few dozen long-form posts can accumulate hundreds of megabytes of revision data. This inflates backup size, slows down database operations that scan the whole wp_posts table, and makes exports and imports noticeably slower.
• Query performance. Most WordPress queries filter by post_status and post_type , so indexes keep things fast – but some plugin queries are not written carefully, and revisions in the same table as posts means they scan more rows than necessary.
• Migration and backup time. Every revision is dumped alongside real content. On a bloated site, a MySQL dump can take minutes longer than it should. WordPress database optimization covers the full picture of how revisions fit into overall database cleanup.

For a small blog with 20 posts, none of this matters. For a site with 500+ posts and active editing over several years, it matters a lot.

Limiting revisions with WP_POST_REVISIONS#

Add this line to wp-config.php , above the "That's all, stop editing!" comment line:

define('WP_POST_REVISIONS', 10);

WordPress now keeps only the 10 most recent revisions per post. When revision 11 is saved, revision 1 is automatically deleted. This is the cleanest way to cap revision growth without disabling the feature.

Common values:

• 10 to 20 – good balance for most sites. Keeps enough history for real undo scenarios without letting the database bloat.
• 3 to 5 – appropriate for high-volume editing (news sites, WooCommerce product descriptions) where the last few saves are enough.
• false – disables revisions entirely. Rarely recommended; see below.

Disabling revisions entirely

define('WP_POST_REVISIONS', false);

This stops WordPress from saving any new revisions. Existing revisions stay in the database until you delete them separately.

This is almost always the wrong choice. Revisions are cheap individually (a single row) and extremely useful when someone overwrites content they did not mean to. The common reason to disable is “my database is huge” – but the right fix for that is to cap revisions going forward and clean up the existing ones, not to turn the feature off. wp-config.php explained covers every related constant if you are doing a full wp-config audit.

Cleaning up old revisions#

Capping future revisions does not remove the ones that already exist. Two ways to clean up:

WP-Optimize plugin

Install and activate WP-Optimize from the plugin repository. Go to WP-Optimize > Database, check Clean all post revisions, and click Run optimization. The plugin counts what will be removed before running so you can confirm.

Good for users without shell access. Leave it installed if you want scheduled cleanups (the free version supports weekly auto-cleanup).

WP-CLI

If you have SSH access:

wp post delete $(wp post list --post_type=revision --format=ids)

This lists every revision and deletes them in one command. On a bloated site, this can delete thousands of rows in a few seconds. After running it, run wp db optimize to reclaim the table space:

wp db optimize

For a recurring cleanup, schedule the delete command as a cron job – how to run a WP-CLI command with cron walks through the scheduling pattern. Weekly is a reasonable cadence for a large site.

Direct SQL

If WP-CLI is not available:

DELETE FROM wp_posts WHERE post_type = 'revision';

Back up first. This is a one-way operation – once deleted, revisions cannot be recovered without a database backup.

The autosave interval#

Separate from revisions, WordPress autosaves the post you are editing every 60 seconds. Autosaves are stored as a single “autosave” row per user per post – they do not accumulate.

To change the interval, add this to wp-config.php :

define('AUTOSAVE_INTERVAL', 120); // 2 minutes

The value is in seconds. Longer intervals mean less server load on large sites with many simultaneous editors; shorter intervals mean less content loss if the browser crashes mid-edit. The default of 60 seconds is sensible for most sites.

Autosaves live in the same wp_posts table as revisions but use post_type = 'revision' with a specific naming pattern (the post is titled with the parent post ID). They are automatically cleaned up when the post is next saved manually, so they do not contribute to long-term database bloat the way regular revisions do.

A sensible revisions configuration#

For most WordPress sites, this combination strikes the right balance:

define('WP_POST_REVISIONS', 10);
define('AUTOSAVE_INTERVAL', 60);

Add it to wp-config.php above the “stop editing” line. Ten revisions per post is enough history to recover from real mistakes without letting the database grow indefinitely. The 60-second autosave is the WordPress default and catches most “browser crashed” scenarios.

If you inherit a site with thousands of accumulated revisions, clean them up once with WP-CLI or WP-Optimize and then set the limit to prevent the same buildup happening again. A five-minute operation up front saves hours of debugging slow database operations later.

If you are doing a broader WordPress audit, how to check your WordPress version and what is wp-content and what goes in it are the companion pieces – between them, they cover which release you are on, where your files live, and how the database behind them is structured. Revisions are one of the smaller pieces of that picture, but one of the easiest to let get out of hand.