WordPress Revisions: How to View, Restore, Limit and Delete Them

WordPress revisions are full saved copies of a post or page, stored in the wp_posts table every time you save a change. WordPress keeps all of them by default. View and restore them in the editor sidebar, cap them with WP_POST_REVISIONS in wp-config.php, and delete old ones with WP-CLI. They take database space but do not slow your public pages.

That summary is the short version. The rest of this guide covers where revisions live, why the Revisions link sometimes does not appear, what changed with the new revisions screen in WordPress 7.0, and the exact commands for limiting and deleting them. Rather than repeat the usual claim that revisions "bloat" a site, we built a test site on 29 October 2026, saved one post 1,000 times, and measured what happened to the database, the public page and the admin screens. Two results surprised us: the public page did not get slower at all, and the delete command most tutorials give does not delete anything.

What is a WordPress revision?

A WordPress revision is a saved copy of a post or page as it was at one moment, stored so you can see what changed and go back to it. Every time you click Save draft, Update or Publish and something has actually changed, WordPress writes a new revision. It is a full copy of the title, content and excerpt, not a list of the differences.

That last point matters more than any other fact in this guide. In our test (method below), ten small edits to a 9,850-byte post produced 99,780 bytes of revision text: almost exactly ten full copies. A revision is cheap for one post and expensive only when it is multiplied by hundreds of edits on thousands of posts.

Three kinds of saved version exist, and people mix them up:

The names in the last column are what we saw in our test database. The 60-second interval and the 30-day trash period are the defaults in WordPress core's default-constants.php (AUTOSAVE_INTERVAL is MINUTE_IN_SECONDS, EMPTY_TRASH_DAYS is 30).

Where are revisions stored?

Revisions are stored in the same database table as your posts, wp_posts, as rows with post_type = 'revision', post_status = 'inherit' and post_parent set to the ID of the post they belong to. The WordPress.org revisions documentation describes them as children of the post, "the same thing we do for attachments".

Which fields are copied? On our WordPress 7.1.4 test install, _wp_post_revision_fields() returned post_title, post_content, post_excerpt and footnotes. If none of those changed, WordPress does not save a new revision: we saved the post with identical content and the revision count stayed at 5. That check lives in wp_save_post_revision() in revision.php.

Are custom fields (post meta) saved in revisions?

Only when a developer opts in. WordPress 6.4 added a framework for revisioning post meta: a meta key registered with revisions_enabled set to true is copied into each revision and restored with it. The default is false. The 6.4 developer note says core uses it for footnotes. In our test, 1,000 revisions added zero rows to wp_postmeta, because the test post had no opted-in meta. So most page builder data, SEO plugin fields and custom fields are not part of a revision unless the plugin that owns them registered them that way.

A practical consequence: restoring a revision can bring back old text while leaving newer custom field values in place. If a page relies heavily on custom fields, test a restore on a staging copy first.

Which content types have revisions?

Revisions exist for any post type that declares support for them. We asked our test install directly with post_type_supports( $type, 'revisions' ). On WordPress 7.1.4 with no plugins, eight post types answered yes:

The WooCommerce rows come from the plugin's own source: the supports list for products in class-wc-post-types.php does not include revisions, and orders support only title, comments and custom fields. So a product description you overwrite cannot be recovered from revisions. That is a reason to keep backups, covered in our guide to backing up a WordPress website.

Style revisions arrived for site-wide styles in WordPress 6.3, which the release announcement describes as "a new audit trail" with "a one-click option to restore prior styles". Custom post types from plugins and themes have revisions only if their developer added 'revisions' to supports in register_post_type().

How to view and compare revisions

Open the post in the editor, open the Settings sidebar, select the Post or Page tab, and click the number next to Revisions. That is the path given in the WordPress.org documentation, last updated 28 September 2026.

What you see next depends on your version:

• WordPress 7.0 and later: a new revisions screen with a list of revisions, a slider along the top, and coloured markers. The documentation lists the colours: added blocks are solid green, removed blocks have red forward-slanting stripes, and modified blocks have yellow backward-slanting stripes. A Show changes icon toggles the highlighting.
• WordPress 6.9 and earlier: the classic screen, a side-by-side comparison of the HTML. In 7.0 you can still reach it with "Open classic revisions screen" in the sidebar.

Compare any two revisions

On the classic screen, tick "Compare any two revisions". The slider gets two handles: drag one to the older version and one to the newer, and the screen shows only what changed between those two. This is the fastest way to answer "who changed the opening hours and when", because each revision records the author and the time.

Revisions in the classic editor

Sites still using the Classic Editor plugin show revisions in the Publish box ("Revisions: 12 Browse") and in a Revisions panel below the editor, which may need enabling under Screen Options. The comparison screen is the same.

Why are my WordPress revisions not showing up?

Your WordPress revisions are not showing up for one of five reasons: the post has fewer than two revisions, revisions are switched off, the content type does not support them, a plugin is hiding or deleting them, or you are looking at a different post than the one you edited. Work through them in this order.

1. Fewer than two revisions. The block editor hides the Revisions item until there are at least two. In Gutenberg's source (post-last-revision/check.jsx) the check reads if ( ! lastRevisionId || revisionsCount < 2 ) return null. A post published once and never updated has nothing to show. Make a small change, save, and look again.
2. Revisions are turned off. Look in wp-config.php for define( 'WP_POST_REVISIONS', false ); or 0. A host, a previous developer or a performance plugin may have added it. Our speed guide explains why this rarely helps.
3. The content type has no revision support. WooCommerce products and many plugin-made types (events, listings, portfolios) do not support revisions unless their developer enabled it.
4. A filter or plugin set the limit to zero. Database cleanup and optimisation plugins often include "delete revisions" or "limit revisions" settings, and a developer may have added a wp_revisions_to_keep filter in a theme or mu-plugin. Search the code for it (command below).
5. Page builder content. If the page was built with a page builder that stores its layout in post meta, the block editor's revisions may show little or nothing, because the layout is not in post_content. Use the builder's own history feature.

# is the constant set?
grep -n "WP_POST_REVISIONS" wp-config.php

# is a filter limiting revisions?
grep -rn "wp_revisions_to_keep\|_revisions_to_keep" wp-content/themes wp-content/plugins wp-content/mu-plugins

# what limit does WordPress actually use for post 123?
wp eval 'echo wp_revisions_to_keep( get_post( 123 ) ), PHP_EOL;'

The last command prints -1 for unlimited, 0 for off, or the number being kept.

How to restore a revision

To restore a revision, open the revisions screen, move the slider to the version you want, and click Restore. The post's content is replaced straight away; on a published post, the change is live.

Restoring does not delete anything. In our test, restoring the oldest of 5 revisions left 6: WordPress saved the restored state as a new revision, so you can undo the restore the same way. A few things to check before you click:

• Restore copies only tracked fields. Title, content, excerpt and footnotes, plus any meta a developer opted in. Featured image, categories, SEO fields and most page builder data stay as they are now.
• On a busy page, restore on staging first. A restore on a live landing page can bring back old prices or old form embeds. See how to create a WordPress staging site.
• Autosaves appear in the list with an Autosave label. If the classic editor warns "There is an autosave of this post that is more recent than the version below", restoring the autosave recovers work lost to a crash or closed tab.

From the command line, a developer can restore a known revision ID:

# list revisions of post 123, newest first
wp post list --post_type=revision --post_parent=123 --fields=ID,post_date,post_author --orderby=ID --order=DESC

# restore revision 456 to its parent
wp eval 'wp_restore_post_revision( 456 );'

What we measured: 1,000 revisions on one post

Revisions cost database space in direct proportion to how many you keep and how long your posts are, but in our test they did not slow the public page at all. The admin revisions screen and the REST API got slower; the front end did not.

Most articles on this topic say revisions "bloat your database" and stop there. We wanted numbers. On 29 October 2026 we built a throwaway WordPress 7.1.4 site in Docker (PHP 8.3.36, Apache, MariaDB 11.4.13, default theme, no caching or optimisation plugins), created one post of 1,422 words (9,850 bytes of block markup), and saved it 1,000 times. Each save appended one short sentence to the first paragraph, using wp_update_post(), which is the same code path as the Update button. We measured at 0, 10, 50, 100, 500 and 1,000 revisions.

How to read it:

• Every revision is a full copy. Revision text grew a little faster than the count because the post itself grew with each edit (from 9,850 bytes to about 29,000). A 2,000-word post with 100 revisions carries roughly 100 copies of itself.
• The public page did not get slower. Median load time stayed between 0.118 and 0.157 seconds from 0 to 1,000 revisions, with no trend. The query that loads a single post stayed between 2.7 and 5.9 milliseconds. WordPress fetches the published post by ID and never reads revision rows to build the page.
• Editors pay the cost. The revisions screen took 0.339 seconds and sent 855 KB of HTML at 1,000 revisions, against 0.149 seconds and 143 KB at 10. Listing every revision through the REST API (/wp/v2/posts/4/revisions with no paging) took 5.1 seconds at 1,000.
• Custom field rows did not grow. wp_postmeta stayed at 4 rows throughout, because no meta was opted in to revisions.

Limits of this test. It is one post on an idle local server, so absolute times are lower than on shared hosting, and real sites have many posts. The size figures come from MariaDB's information_schema after ANALYZE TABLE, which are estimates rounded to 16 KB pages; the "revision text" column is an exact SUM(LENGTH()). The scripts and raw output are kept with our research notes and we can share them on request.

How to limit post revisions

To limit revisions, add one line to wp-config.php, above the line that says "That's all, stop editing!":

define( 'WP_POST_REVISIONS', 10 );

The wp-config documentation lists the values. Core's wp_revisions_to_keep() turns them into a number:

Two behaviours surprise people, and we confirmed both in the test:

1. A limit does not clean up old posts. We gave a post 20 revisions, then set the limit to 5. It still had 20. Only when that post was saved again did WordPress trim it, to 5 on the next save. Posts nobody edits keep every old revision until you delete them.
2. Turning revisions off does not stop autosaves. With the limit at 0, WordPress still created an autosave row. That is useful: autosaves are what rescue you after a browser crash.

Different limits for different content

Developers can set limits per post type with filters instead of one global number. wp_revisions_to_keep applies to everything; the dynamic wp_{post_type}_revisions_to_keep filter, added in WordPress 5.8, targets one type and overrides both. Put this in a small must-use plugin rather than the theme, so it survives a theme change:

<?php
// wp-content/mu-plugins/revision-limits.php
// Keep 25 revisions of pages (legal and pricing pages change rarely and matter),
// 10 of posts, and leave other types on the global setting.
add_filter( 'wp_page_revisions_to_keep', function () { return 25; } );
add_filter( 'wp_post_revisions_to_keep', function () { return 10; } );

What limit should you choose?

For most business sites, 10 to 25 per post is a sensible range. It covers the realistic need, which is undoing the last few rounds of edits, while stopping the slow pile-up on pages that are edited daily. Sites where content has legal or compliance weight, such as policies, medical information or pricing terms, should keep more, or keep everything and rely on database size being a minor cost. Our test showed that 100 revisions of a long post took about 2.5 MB; for a site with a few hundred pages, that is small next to the uploads folder.

Changing AUTOSAVE_INTERVAL (for example define( 'AUTOSAVE_INTERVAL', 180 );) changes how often the single autosave is overwritten. It does not affect how many revisions you keep, so raising it to "save space" achieves nothing.

How to delete revisions safely

The safe way to delete revisions is WP-CLI with the --force flag, after a database backup. WordPress has a function for deleting revisions but, as the WordPress.org documentation puts it, "there is no UI".

Here is something our test caught. The command you will find in many tutorials is:

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

On our install it deleted nothing. WP-CLI printed "Posts of type 'revision' do not support being sent to trash. Please use the --force flag to skip trash and delete them permanently." for every one of the 1,001 rows. The working version:

# 1. back up the database first
wp db export before-revisions.sql

# 2. see how many there are
wp post list --post_type=revision --format=count

# 3. delete them all, permanently
wp post delete $(wp post list --post_type=revision --format=ids) --force

# or only for one post (ID 123)
wp post delete $(wp post list --post_type=revision --post_parent=123 --format=ids) --force

That removed all 1,001 rows in 15 seconds on our test install. On a site with tens of thousands of revisions, the list of IDs can exceed the shell's argument limit; delete in batches instead:

wp post list --post_type=revision --format=ids --posts_per_page=500 \
  | xargs -r wp post delete --force

Run it repeatedly until the count reaches zero. wp post delete goes through WordPress's own deletion function, so any opted-in revision meta and other attached data are cleaned up as well.

The space does not come back on its own

After deleting 1,001 revisions, wp_posts data dropped from 29.79 MB to 0.05 MB, but MariaDB reported 26.2 MB as free space still held inside the table. It was released only after OPTIMIZE TABLE, which on InnoDB rebuilds the table:

wp db query "OPTIMIZE TABLE wp_posts;"

The rebuild locks or copies the table, so run it in a quiet hour, after a backup. If your table prefix is not wp_, use yours (wp db prefix shows it).

Deleting with SQL

Many guides offer a single SQL query. It works but leaves orphaned rows behind, so prefer WP-CLI. If you have only phpMyAdmin, back up first and run:

DELETE FROM wp_posts WHERE post_type = 'revision';

-- tidy up meta and term rows that pointed at deleted revisions
DELETE pm FROM wp_postmeta pm
  LEFT JOIN wp_posts p ON p.ID = pm.post_id
  WHERE p.ID IS NULL;

DELETE tr FROM wp_term_relationships tr
  LEFT JOIN wp_posts p ON p.ID = tr.object_id
  WHERE p.ID IS NULL;

The second and third queries remove every orphaned row, not only those from revisions. That is normally what you want, but read them once more before you run them, and never run any of this without a fresh export.

Cleanup plugins

Database cleanup plugins do the same job from the dashboard, which is reasonable for a site owner without SSH. Two cautions: many also delete autosaves, drafts, transients and spam in one click, so read each option; and a scheduled "delete all revisions every week" setting quietly removes your safety net. Limiting with WP_POST_REVISIONS is the better long-term control.

What revisions do NOT mean for your site

Revisions are one of the most blamed and least guilty parts of WordPress. Here is what they are not.

Does WordPress have a changelog?

For your content, the closest thing WordPress has to a changelog is revisions: each one records who saved the post and when, and the revisions screen shows exactly what changed. For the software itself, each release has public release notes on WordPress.org and a HelpHub page, and every code change is listed on WordPress Trac.

What WordPress core does not include is a site-wide activity log: there is no built-in record of who changed a setting, installed a plugin or logged in. Revisions cover posts, pages, templates, styles, navigation and synced patterns, and nothing else. If you need an audit trail (several editors, a regulated industry, or a site that has been hacked before), add an activity log plugin and keep its records off the server. Our security audit guide explains what an audit should check.

How do I delete a post in WordPress?

To delete a post, hover over it in Posts, All Posts, and click Trash, or open it and choose Move to trash in the editor sidebar. Trashed posts stay in Posts, Trash for 30 days by default and can be restored from there. After 30 days, or when you click Delete Permanently or Empty Trash, the post is gone.

How this relates to revisions: when a post is permanently deleted, WordPress deletes its revisions too. The core function wp_delete_post() loops through the post's revisions and removes each one. So a permanently deleted post cannot be recovered from revisions; only a backup can bring it back. A site owner can change the trash period in wp-config.php:

// keep trashed posts for 60 days instead of 30
define( 'EMPTY_TRASH_DAYS', 60 );

Setting it to 0 disables the trash completely, so Delete becomes permanent at once. We do not recommend that on any site with more than one editor.

A sensible revisions policy for a business site

A sensible policy keeps enough history to undo mistakes, stops the database growing without limit, and does not mistake revisions for backups. This is the setup we use as a starting point on sites we maintain:

1. Set a limit: WP_POST_REVISIONS of 15 to 25, or per-type filters if a few pages need more history.
2. Clear the backlog once, after a backup, with the WP-CLI command above, then OPTIMIZE TABLE in a quiet hour.
3. Leave autosaves alone. They cost one row per user per post and save real work.
4. Keep daily off-site backups of the database and files, and test a restore. Our guide to restoring a WordPress backup walks through one.
5. Add an activity log if several people edit the site, so you know who changed what outside of post content.
6. Check the limit after migrations. Moving host often replaces wp-config.php, and a host's default file may switch revisions off.