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, the autosave interval, and the page-builder and WooCommerce gotchas most articles skip.

Revisions, autosaves, and backups at a glance#

These three things get conflated constantly. They are not the same:

Revisions and autosaves are inside WordPress. Backups live outside it. If revisions are gone (deleted, post trashed and emptied), the only path back is a backup.

How to restore a previous version in WordPress#

If you just overwrote content and need it back, this is the fast path:

1. Open the post in the editor.
2. In the right sidebar, click the Post tab (not Block).
3. Find the Revisions panel and click the count (e.g. “Revisions 12”).
4. Drag the slider at the top to find the version you want.
5. Click Restore This Revision.

The version you just had becomes another revision in the chain, so the restore itself is reversible. If the panel does not appear at all, jump to the Why the Revisions panel is missing section below.

If the post was deleted or the database is corrupt, revisions cannot help – you need a backup instead. The How Hostney handles snapshots, staging, and backups section near the end covers what that looks like on Hostney.

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.

Why the Revisions panel is missing#

If you cannot find the panel at all, one of three things is happening:

• Revisions are disabled in wp-config.php with define('WP_POST_REVISIONS', false); . Remove the line or set it to a positive integer.
• The post type does not support revisions. Custom post types must opt in explicitly via the supports argument of register_post_type() or a add_post_type_support('your_cpt', 'revisions') call. See Controlling revisions per post type below.
• A theme or plugin called remove_post_type_support('post', 'revisions') . Less common but it happens. Search your active theme’s functions.php and your active plugins for remove_post_type_support to find the culprit.

A quick way to confirm which one applies: if you have WP-CLI access, run wp post-type get post --field=supports – if revisions is missing from the list, support has been removed for that post type.

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.

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.

Controlling revisions per post type#

WP_POST_REVISIONS is a global cap. Sometimes you want different rules for different content types – keep full revision history on post , but skip revisions entirely on a high-churn custom post type like product_log or import_record .

Disable revisions for a specific post type#

Drop this in your theme’s functions.php or a small mu-plugin:

function disable_revisions_for_product_log() {
    remove_post_type_support('product_log', 'revisions');
}
add_action('init', 'disable_revisions_for_product_log');

WordPress stops saving revisions for that post type immediately. Existing revisions for that type remain in the database until you delete them separately.

Enable revisions for a custom post type that does not have them#

Custom post types do not get revisions by default. Add 'revisions' to the supports array in your register_post_type() call:

register_post_type('case_study', array(
    'public'   => true,
    'supports' => array('title', 'editor', 'thumbnail', 'revisions'),
));

If the post type is registered by a plugin you do not control, add support after the fact:

add_action('init', function() {
    add_post_type_support('case_study', 'revisions');
}, 99); // Priority 99 so it runs after the plugin's own register call.

Different revision cap per post type#

The wp_revisions_to_keep filter lets you return a different number per post type:

add_filter('wp_revisions_to_keep', function($num, $post) {
    if ($post->post_type === 'product_log') {
        return 0; // No revisions for this type.
    }
    if ($post->post_type === 'page') {
        return 50; // More history for pages.
    }
    return $num; // Default for everything else.
}, 10, 2);

Useful when one CPT generates thousands of saves per day (think a custom logging or auditing type) but you still want generous history on post and page .

Page builder and WooCommerce revisions#

This is the part most “clean up revisions” articles skip and it is often the biggest source of bloat.

Page builders save their own revisions#

Elementor, Divi, Beaver Builder, Oxygen, and WPBakery do not just rely on WordPress revisions. They save their own revision data inside wp_postmeta , usually as serialized PHP arrays. A single Elementor revision can be hundreds of kilobytes because it stores the entire page structure as JSON.

This means a site with 50 pages built in Elementor and 30 revisions per page can have wp_postmeta rows that dwarf the wp_posts table entirely. WordPress’s WP_POST_REVISIONS cap does apply to the parent revision rows in wp_posts , and most builders inherit that cap for their builder-specific data attached to them – but the bytes per revision are far larger than a plain post body, so the same cap costs more.

How to spot it:

• Run SELECT meta_key, COUNT(<em>) FROM wp_postmeta GROUP BY meta_key ORDER BY COUNT(</em>) DESC LIMIT 20; against your database. Keys like _elementor_data , _elementor_css , _et_pb_<em> (Divi), _fl_builder_</em> (Beaver Builder), or _oxygen_* indicate builder data.
• Open a long-edited page and look at the revision count. A page that has been iterated on for a year can easily have 200+ revisions.

The fix is the same as for regular revisions – cap them with WP_POST_REVISIONS and clean up the old ones (next section). The cleanup tools we cover below handle both kinds because they target post_type = 'revision' in wp_posts , which is the parent record; deleting it cascades the builder data attached to it.

WooCommerce and revisions#

WooCommerce treats orders and products as post types. Both get revisions:

• Products ( product post type) save revisions on every Update. Long product descriptions with attribute changes can accumulate thousands of revisions on busy stores.
• Orders ( shop_order , or HPOS-backed in WooCommerce 8.2+) historically lived in wp_posts and got revisions too. With High-Performance Order Storage enabled, orders move to dedicated tables and revisions move with them – the cleanup pattern changes, see WooCommerce’s HPOS documentation for specifics.

Best practice for WooCommerce sites: cap revisions at 3-5 with WP_POST_REVISIONS . Product descriptions rarely need 30 versions of history. If your store uses Action Scheduler heavily (most do), the order tables and the action scheduler tables are usually the biggest database tables before revisions even enter the picture – run the size query in the database optimization guide to see what is actually eating space.

Cleaning up old revisions#

Capping future revisions does not remove the ones that already exist. Three ways to clean up – pick by what access you have.

Back up first, regardless of method. Revisions cannot be recovered after deletion without a backup.

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 Hostney backups section below covers how to take one in two clicks before running this.

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. If you want a deeper walkthrough of where autosave fits in the broader save/preview/schedule flow, see how to save a draft in WordPress.

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.

How Hostney handles snapshots, staging, and backups#

Revisions are the right tool for “I overwrote a paragraph and want it back.” When the problem is bigger than that – a plugin update broke the site, a search-and-replace touched the wrong tables, a custom code change broke checkout – revisions are not enough. Hostney sites get three layers above WordPress’s own:

• WordPress Snapshots (per install). On the Snapshots tab of any WordPress install, you can take a manual snapshot of the entire site – every file plus the database – in one click. Snapshots are also created automatically before major actions like core updates, so a botched WordPress 6.x upgrade is always one Restore click away from the pre-update state. Restores are word-gated (“type RESTORE”) to prevent accidents.
• Staging environments (per install). The Staging tab spins up a private clone of your WordPress site at an unguessable .staging.hostney.app URL with its own database. You can test plugin updates, PHP version bumps, theme changes, or content edits on the clone, then use Push to production to promote exactly what you want – files, specific database tables, or both. A pre-push snapshot of production is taken automatically by default, so if the push goes wrong you can roll production back without losing anything.
• Account backups (whole hosting account). The Backups page runs on a regular schedule across your entire hosting account – every file under your home directory and every MySQL database, not just one WordPress install. Manual snapshots can be created before risky changes. You can restore everything, just files, just databases, or browse the snapshot’s file tree and recover individual files via File recovery. Archives can be downloaded as packaged files (24-hour link, up to 3 concurrent downloads).

These do not replace WordPress revisions – revisions are still the fastest path for “undo my last edit to a single post.” But for everything bigger, they mean you do not have to engineer a personal disaster-recovery plan to get a clean rollback path.

What we do not do at the platform level: automatically clean up WordPress revisions for you. That is a per-site decision (some teams want 50 revisions of editorial history, others want zero), so the WP_POST_REVISIONS cap and the cleanup tools above are still where you make that call. We just guarantee that whatever cleanup decision you make, a recent snapshot exists to roll back to if you delete more than you meant to.

Frequently asked questions#

Do revisions affect SEO?#

No. Revisions are stored with post_type = 'revision' and are excluded from the public site – they do not appear in archives, sitemaps, or search results, and they do not get indexed by search engines. Their only cost is database size.

Do revisions slow down my site?#

Indirectly. The wp_posts table grows, which makes backups, exports, and full-table operations slower. Normal front-end page loads filter by post_status = 'publish' and use indexes, so they are not directly slowed. The visible symptom of revision bloat is almost always slow wp-admin or slow plugin operations that scan the table, not slow front-end pages.

How many revisions should I keep?#

For most sites, 10-20. For high-volume editing (news, WooCommerce products), 3-5. For editorial teams with audit requirements, 50-100. There is no universal right answer – it is a tradeoff between recovery history and database size.

Do revisions get backed up?#

If your backup tool dumps the entire wp_posts table (most do, including mysqldump and every WordPress backup plugin), yes. That is part of why uncapped revisions inflate backup file sizes and backup time.

Do revisions count toward storage limits?#

Yes – they consume MySQL storage. On hosts with strict database size limits, an old WordPress site with thousands of accumulated revisions can hit the cap unexpectedly. Cleaning up revisions usually frees significant space.

Do revisions trigger the save_post action?#

Yes, but the post object passed to the hook has post_type = 'revision' . Most plugins check if (wp_is_post_revision($post_id)) return; at the top of their save_post callbacks to skip revision saves. If you write your own save_post handler, do the same – otherwise your hook fires once per manual save and once per revision, doubling the work.

Summary#

Revisions are one of WordPress’s most useful features and one of its biggest sources of avoidable bloat. The shape of a healthy revisions setup is:

1. Cap them with define('WP_POST_REVISIONS', 10); (or 3-5 for high-churn content types).
2. Use the wp_revisions_to_keep filter when one post type needs different rules.
3. Clean up the existing pile once with WP-CLI, WP-Optimize, or SQL – and take a snapshot first.
4. If you use a page builder or WooCommerce, expect the bloat to be 5-10x larger than a plain content site. Audit wp_postmeta keys to confirm.
5. Treat revisions as edit-level undo, not as your backup strategy. Backups and snapshots are for everything bigger.

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.