Every time you save a post in WordPress, it creates a revision — a complete copy of the post content stored in the database. Over months and years of active publishing, a site accumulates thousands of revisions that inflate the database size, slow database queries, and provide a recovery point that most sites already have through dedicated backup plugins. WordPress revisions are a powerful safety net, but they need to be understood and managed correctly to avoid becoming a performance and storage problem. We go deeper on the whole subject in our Complete Guide to WordPress How.
WordPress Revisions — How They Work
WordPress revisions are stored in the wp_posts table with the post_type value “revision.” Each revision is a full copy of the post’s title, content, and excerpt at the time of saving — not a diff or delta, but a complete duplicate. For a post with 2,000 words that has been saved 50 times, WordPress has 50 complete copies of that post in the database, consuming 50× the storage of a single saved version. The current published version is the post itself; all other versions are revisions available for restoration.
Access WordPress revisions for any post: in the block editor, open the document panel on the right → click “X Revisions” → the revisions browser opens, showing a slider timeline of all saved versions. Drag the slider left to go back in time — each position shows the diff between the selected revision and the current version, with additions highlighted in green and removals in red. Click “Restore This Revision” to roll back the post to the selected version. The restoration does not delete the current version — it creates a new revision of the current state before restoring the older version, so nothing is ever permanently lost in the revisions system. This revision browser is the most useful recovery tool for accidental edits, mistaken content deletions, and experimental changes that need to be undone.
Autosave creates a special type of WordPress revisions — a single autosave revision that is overwritten each time rather than accumulated. WordPress autosaves every 60 seconds by default. The autosave appears in the revisions browser as a distinct entry labeled “Autosave.” If the browser crashes or the editor closes without saving, the autosave recovers the most recent content up to 60 seconds before the crash — WordPress displays a “There is an autosave of this post that is more recent than the version below” notice and offers to load it. The autosave is separate from the manual save revision chain, so restoring an autosave does not overwrite any manually saved revisions. According to the WordPress developer documentation, autosaves are stored as a special revision with the meta key _wp_autosave_lock, overwritten on each autosave cycle rather than accumulated like manual save revisions.
Limiting WordPress Revisions to Control Database Size
The default WordPress configuration stores unlimited revisions — every save of every post accumulates in the database indefinitely. For a site with 500 posts and an average of 30 saves per post over the post’s lifetime, that is 15,000 revision rows in the wp_posts table, each containing the full post content. Limiting WordPress revisions to a manageable number is one of the most impactful database optimisations available.
Set the revision limit in wp-config.php: add define('WP_POST_REVISIONS', 5); above the “That’s all, stop editing!” comment. This limits every post to the 5 most recent revisions — when a 6th revision is created, the oldest is automatically deleted. Setting it to 3 retains the last 3 saves; setting it to 0 disables revisions entirely; setting it to false also disables them. The constant applies to all post types by default. For sites that need revision control for posts but not for custom post types that are programmatically updated (e.g., a product post type synced from an ERP system), use the wp_revisions_to_keep filter to apply different limits per post type: add_filter('wp_revisions_to_keep', function($num, $post) { return $post->post_type === 'product' ? 0 : 5; }, 10, 2);.
The revision limit applies to new revisions going forward — existing revisions already in the database are not deleted when the limit is set. Clean up existing WordPress revisions using WP-Optimize (free plugin): Database → Post revisions → Delete all revisions → Run. WP-Optimize shows the revision count and estimated database space before deletion, allowing an informed decision. On a database-heavy site with years of accumulated revisions, this cleanup can reduce wp_posts table size by 30–60% and improve database query performance for all queries that read from wp_posts. After cleanup, the database should be optimised to reclaim the freed space: WP-Optimize → Database → Optimise all → Run. Our guide on fixing WordPress admin dashboard slow performance covers the database optimisation context that makes revision cleanup one of the highest-impact performance improvements available.
Restoring From Revisions and Version Comparison
The practical day-to-day value of WordPress revisions is in recovering from mistakes — an editor accidentally deleting a section, a batch update that changed content incorrectly, or a client who wants to revert to a previous version of a page. WordPress’s revisions browser makes this recovery straightforward.
To restore a specific revision: edit the post → block editor → Document tab → Revisions → open the revisions browser → use the slider to navigate to the desired historical version → the diff view shows what changed between the selected revision and the current version → click “Restore This Revision.” Before restoring, check the revision date and the diff carefully — the diff shows only content changes, not metadata changes like category assignments or featured images. If the revision predates a metadata change that should be kept (e.g., the category was changed after the revision was created), restore the content revision and then manually re-apply the current metadata settings.
Compare any two WordPress revisions against each other by using the “Compare any two revisions” checkbox in the revisions browser — this reveals the diff between any historical version and any other, not just between a revision and the current version. This comparison is useful for auditing content changes (“what changed between December’s version and March’s version?”), for understanding the scope of accumulated edits before deciding whether to restore, and for editorial review of what an author changed between their draft and the published version. The diff view uses the same colour coding as the standard revision comparison — green for additions, red for deletions — with unchanged content shown in white. Reviews from the WordPress developer community confirm that limiting WordPress revisions to 3–5 per post while maintaining a dedicated backup plugin provides both the recovery safety of revision history and the performance benefits of a lean database, without relying on revisions as a primary backup mechanism. Our guide on fixing WordPress post not saving covers the autosave and revision recovery mechanisms that apply when a save failure results in content that needs to be recovered from the revision system.
Revisions for Custom Post Types and Third-Party Content
WordPress revisions are enabled by default for post types that declare 'supports' => ['revisions'] or use the default supports array. Custom post types registered without explicitly including “revisions” in their supports array do not generate revisions — each save overwrites the previous version without creating a recovery point.
Enable revisions for a custom post type that does not currently support them: add add_post_type_support('your_post_type', 'revisions'); to functions.php on the init hook after the post type is registered. For post types registered by plugins, use add_post_type_support as a hook-based addition without modifying the plugin’s code. After adding revision support, test by saving the post type and checking the revisions browser appears in the editor — if it shows with a count, revisions are now being created for that post type. The revision storage overhead applies equally to custom post types, so apply the WP_POST_REVISIONS limit or post-type-specific limit simultaneously when enabling revisions on content-heavy custom post types.
Page builders (Elementor, Divi, Beaver Builder) store their design data in post meta (wp_postmeta) rather than in post_content — and WordPress revisions capture post_content but not all post_meta. This means WordPress revisions for Elementor-built pages may show the correct structural content but restoring a revision does not restore the Elementor layout, colours, or design decisions stored in meta. Each page builder has its own revision system: Elementor’s “Revision History” (accessible via the Elementor editor’s history panel) tracks design changes independently of WordPress revisions. For page builder content, use the builder’s own revision history for design recovery and WordPress’s revision system only for content text that is visible in the post_content field.
Exporting, Importing, and Archiving Revisions
WordPress does not include a native revision export feature — WordPress revisions exist only in the database and are not included in standard WordPress export files (which export only published content). For sites where revision history is an important audit trail — legal, compliance, or editorial accountability requirements — maintaining revision history requires either keeping the revisions in the database indefinitely or implementing a custom archiving solution.
A custom archiving approach for compliance-critical WordPress revisions: before limiting revisions or running a cleanup, export the full database backup (hosting control panel → phpMyAdmin → Export → SQL format) which includes all revision rows. Store this archive in off-site storage. If a historical revision is ever needed from the archive, restore the database backup to a temporary local environment and extract the specific revision’s content. This approach provides unlimited historical access without the production database performance cost of retaining thousands of live revisions.
For legal audits where WordPress revisions timestamps and author attribution are critical — proving who changed what and when — WordPress’s revision system provides this data natively. Each revision stores the user ID of the author who made that save and the timestamp. Access this information via WP_CLI: wp post list --post_type=revision --fields=ID,post_author,post_date,post_parent --format=table — this lists all revisions with their author, date, and the parent post they belong to. Pipe to a CSV for audit reporting: add --format=csv > revisions-audit.csv. For legal content requiring an authenticated audit trail, supplement this with a logging plugin (WP Activity Log) that creates an immutable log of all editor actions including content changes, providing more reliable audit evidence than the revision system alone since revisions can be deleted while the activity log records cannot be modified through normal WordPress operations.
Disabling WordPress revisions selectively for specific roles — preventing Contributors and Authors from generating revisions while Editors and Administrators retain full revision history — is possible through the wp_revisions_to_keep filter combined with a current user capability check: add_filter('wp_revisions_to_keep', function($num, $post) { return current_user_can('edit_others_posts') ? 5 : 0; }, 10, 2);. This retains 5 revisions for Editors and Administrators (who have edit_others_posts capability) and disables revision creation for Authors and Contributors (who do not). This selective approach reduces revision accumulation from high-frequency contributor accounts on multi-author publications while preserving full revision history for editorial oversight roles. The capability check runs per-save, so a post that an Author saved (no revisions created) and then an Editor revised (revisions now created) correctly transitions from no-revision to with-revision storage based on who is currently editing.
The performance impact of WordPress revisions on large sites manifests primarily in two places: post save speed (creating a revision requires a database INSERT for every save) and query performance on pages that load post data from the wp_posts table. With tens of thousands of revisions accumulated over years, queries that do not specifically filter out post_type=’revision’ can return unexpected results or take longer than necessary. Confirm revisions are filtered from queries: any custom WP_Query that does not specify post_type automatically excludes revisions because WordPress adds a default exclusion for revision post types in the main query. However, raw SQL queries against wp_posts do not automatically exclude revisions — always add AND post_type != 'revision' to custom SQL queries that read from wp_posts to prevent revision rows from being counted or returned in results. Our guide on the complete WordPress caching guide covers the database object caching with Redis that reduces the query performance impact of large revision tables by caching query results in memory rather than re-executing them on every request.
Scheduling automatic WordPress revisions cleanup as a recurring maintenance task prevents revision accumulation from becoming a future performance issue. Use WP-Cron to schedule monthly cleanup: create a custom plugin or add to functions.php: if (!wp_next_scheduled('monthly_revision_cleanup')) { wp_schedule_event(time(), 'monthly', 'monthly_revision_cleanup'); } add_action('monthly_revision_cleanup', function() { global $wpdb; $wpdb->query("DELETE FROM $wpdb->posts WHERE post_type = 'revision' AND post_date < DATE_SUB(NOW(), INTERVAL 90 DAY)"); $wpdb->query("OPTIMIZE TABLE $wpdb->posts"); });. This monthly job deletes revisions older than 90 days and optimises the posts table, maintaining a clean database automatically without manual intervention. Combined with the WP_POST_REVISIONS limit that prevents future accumulation, this scheduled cleanup maintains database health indefinitely on an active site.
