How WordPress post revisions work

How WordPress post revisions work becomes important the first time you overwrite a paragraph, delete half a page or discover that yesterday’s version was considerably better than today’s improvement.

WordPress revisions create a history of saved versions of posts, pages and other supported post types. Instead of replacing the previous content every time you save, WordPress can preserve historical snapshots that can later be compared and restored.

Revisions are useful for writers, developers, agencies and editorial teams because they provide a recovery layer inside the content workflow. They are not full-site backups, they are not the same thing as autosaves and they do not preserve every possible piece of WordPress data.

This guide explains what WordPress revisions store, when they are created, how they differ from autosaves, where they live in the database, how restoring one works, how revision limits are configured and when a large revision history becomes a database-management concern.

What is a WordPress revision?

A revision is a historical version of a WordPress post or other revision-enabled content object.

Imagine an article that changes over several editing sessions:

Version 1
Initial draft

Version 2
Introduction rewritten

Version 3
New section added

Version 4
Statistics updated

Current version
Final published article

WordPress can preserve the earlier states as revisions instead of discarding them completely.

The official WordPress Revisions documentation describes the revision system, comparison interface, restoration process and revision configuration options.

When does WordPress create a revision?

WordPress can create revisions when content is deliberately saved or updated.

Common examples include:

• saving a draft;
• updating a published post;
• saving changes to a Page;
• updating another post type that supports revisions.

Conceptually:

Current content
        ↓
User changes content
        ↓
Save or Update
        ↓
Previous state retained as revision
        ↓
New state becomes current

The exact revision behavior is implemented by WordPress core through its revision APIs, including wp_save_post_revision().

Revisions are themselves a WordPress post type

WordPress does not store revision history in a completely unrelated revision database.

Revisions are represented using WordPress’s post architecture.

A revision record uses:

post_type = revision
post_status = inherit

and is associated with the original content through its parent relationship.

Conceptually:

wp_posts

ID: 500
post_type: post
post_title: Example Article

ID: 501
post_type: revision
post_parent: 500

ID: 502
post_type: revision
post_parent: 500

ID: 503
post_type: revision
post_parent: 500

The official WordPress revision documentation explains that revisions are stored in the posts table as children of their associated post.

For a deeper look at the table itself, see Optimizing the WordPress posts table.

Revisions do not create a second copy of your entire website

A revision belongs to one content object.

Saving a revision of a Page does not duplicate:

• the entire database;
• all plugins;
• all media files;
• theme files;
• WordPress configuration;
• every other page.

This is why revisions should not be confused with backups.

A revision can help recover previous content.

A backup can recover much larger parts of the site after corruption, deletion or infrastructure failure.

TheOneWP Backup Manager addresses the broader backup layer rather than individual content history.

What data does WordPress normally store in revisions?

By default, WordPress tracks several core post fields in its revision system.

These include:

• title;
• content;
• excerpt;
• author-related revision data.

The revision implementation is handled by functions in the WordPress Post Revisions package.

This means a revision is primarily a history of the editable post content rather than a universal snapshot of every database field associated with that post.

Not every custom field is automatically revisioned

This is important on modern WordPress sites.

A page may contain:

Post content
Custom fields
SEO metadata
Page builder metadata
Plugin settings
Taxonomy terms

Do not assume that restoring a standard WordPress revision necessarily restores every piece of data in that list.

Plugins can integrate additional metadata into revision workflows, but support depends on how the plugin or custom code was implemented.

Revisions and autosaves are different

WordPress revisions and autosaves are related, but they solve different problems.

A normal revision records an intentional saved state.

An autosave is a temporary recovery mechanism created while you are working.

Think of the distinction as:

Revision
→ "I saved this version."

Autosave
→ "WordPress saved a recovery copy while I was editing."

How WordPress autosaves work

While you edit a post, WordPress periodically saves your progress automatically.

The purpose is to reduce the amount of work lost if:

• the browser crashes;
• the computer loses power;
• the connection fails;
• the editing session is interrupted.

Autosaves are stored as a special form of revision rather than overwriting the published post directly.

The official WordPress documentation notes that there is normally a maximum of one autosave per user for a particular post. A newer autosave replaces that user’s previous autosave rather than creating an endless new row every autosave interval.

Autosaving every minute does not mean one permanent revision every minute

This is a common misconception.

Suppose the autosave interval is:

60 seconds

Editing for two hours does not necessarily mean WordPress permanently accumulates 120 separate autosave revisions for that user.

The autosave is repeatedly updated.

This matters when diagnosing database growth because autosave frequency and permanent revision count are not equivalent metrics.

The default autosave interval is 60 seconds

WordPress’s configuration documentation specifies a default autosave interval of 60 seconds.

It can be changed in wp-config.php:

define( 'AUTOSAVE_INTERVAL', 180 );

This example changes the interval to three minutes.

The official WordPress wp-config.php documentation covers the AUTOSAVE_INTERVAL setting.

TheOneWP Autosave Interval provides a settings-based way to control the interval without manually maintaining the constant.

Do not increase the autosave interval simply to reduce database writes

A longer interval can reduce how frequently autosave activity occurs, but it also increases the amount of unsaved work that could be lost between recovery points.

The correct interval depends on the site’s editing workflow.

For an editorial team writing long-form articles, aggressive reduction of autosaving may be a poor trade simply to eliminate a modest amount of database activity.

How do you view WordPress revisions?

When revisions exist for a supported post, WordPress exposes them from the editor interface.

In current WordPress versions, the post or page settings sidebar displays the available revision count.

Opening it launches the revisions interface where historical versions can be inspected.

Starting with WordPress 7.0, WordPress introduced a redesigned revisions screen with a timeline-style interface and highlighted changes. The classic revision comparison remains accessible as well.

The current interface is documented in the official WordPress Revisions guide.

The revision screen shows what changed

The comparison interface highlights differences between versions.

Depending on the interface being used, you can inspect:

• added content;
• removed content;
• changed content;
• the revision date;
• the revision author.

This makes revisions useful for more than emergency recovery.

They can also answer:

Who changed this paragraph?

When did this heading change?

What wording existed before the last update?

You can compare historical versions

The revision interface allows navigation between saved versions.

The classic interface also supports comparing two revisions rather than only comparing one revision against the current post.

This can be useful when a page has gone through several rounds of substantial editing.

How does restoring a revision work?

When you select an earlier revision and restore it, WordPress uses that historical state to replace the current revisioned content.

The old current state is not necessarily annihilated from history.

This makes restoration relatively safe compared with manually copying old text over the current content.

A typical workflow is:

Current version is wrong
        ↓
Open Revisions
        ↓
Find correct historical version
        ↓
Compare changes
        ↓
Restore
        ↓
Review current content
        ↓
Update if necessary

Always review the restored page afterward

Restoring content does not guarantee that every part of the page now matches the historical website state.

Remember that other systems may have changed independently:

• theme styling;
• custom fields;
• plugin settings;
• taxonomies;
• media files;
• external data.

Open the actual page after restoration and verify the result.

Revisions are valuable during client review

Revision history becomes especially useful when a page passes through several feedback rounds.

Imagine:

Version 1
Agency draft

Version 2
Client corrections

Version 3
Legal changes

Version 4
Final approval

If someone later asks to restore wording from Version 2, having revision history is considerably easier than searching several email attachments for whatever “homepage-final-final-v2” was supposed to mean.

For the broader process, see Setting up a client review workflow in WordPress.

Revisions are useful during draft sharing too

A reviewer may send feedback on an unpublished draft while an editor continues making changes.

Revision history can help identify which content state existed before or after those corrections.

For external review without creating a WordPress account, see Sharing a WordPress draft without creating an account.

Revisions do not replace version control for code

WordPress revisions protect content.

They are not a substitute for Git or another source-control system for:

• PHP;
• JavaScript;
• CSS;
• theme files;
• plugin code;
• configuration files.

A restored Page revision will not revert a broken theme deployment.

Content versioning and code versioning solve different problems.

Revisions do not replace backups either

A revision usually helps when:

Someone changed the content incorrectly.

A backup is needed for situations such as:

The database is corrupted.
The site was deleted.
The server failed.
A plugin migration damaged many records.
The entire environment needs restoration.

Keep both systems when the website matters.

Which post types support revisions?

Revision behavior depends on whether the post type supports the revisions feature.

WordPress checks this when determining how many revisions should be retained.

A custom post type can enable revision support during registration:

'supports' => [
    'title',
    'editor',
    'thumbnail',
    'revisions',
]

The official add_post_type_support() documentation describes the features post types can support.

If you are designing custom content structures, see WordPress post types vs. custom post types.

A custom post type may deliberately disable revisions

Not every WordPress object needs historical content versions.

For example, an internal post type used primarily as a lightweight system record may not benefit from revision history.

Conversely, a Documentation post type edited by several people probably should retain revisions.

The decision should follow the content workflow rather than a universal rule.

How many revisions does WordPress keep by default?

By default, WordPress can keep an unlimited number of revisions for revision-enabled posts.

Internally, WordPress represents an unlimited limit as:

-1

The official wp_revisions_to_keep() documentation explains how the effective revision count is determined.

WP_POST_REVISIONS controls the global limit

The WP_POST_REVISIONS constant can be configured in wp-config.php.

For example:

define( 'WP_POST_REVISIONS', 10 );

limits the number of normal revisions WordPress retains for each supported post.

Other possible configurations include:

define( 'WP_POST_REVISIONS', true );

to use the default unlimited behavior, or:

define( 'WP_POST_REVISIONS', false );

to disable normal revision history.

The official WordPress configuration documentation covers these options.

Zero does not mean unlimited revisions

This particular configuration mistake deserves attention.

A value of:

0

means revisions should not be retained.

It does not mean:

No limit.

Unlimited revision retention is represented by WordPress through its unlimited/default behavior, not by zero.

Autosaves still behave separately when normal revisions are disabled

Disabling normal revision history does not mean WordPress loses every autosave recovery mechanism.

WordPress documents autosaves as a special revision behavior, and its revision configuration distinguishes normal retained revisions from the autosave used for editor recovery.

This is another reason not to treat “revision” and “autosave” as interchangeable words.

TheOneWP Post Revisions controls the revision limit

TheOneWP Post Revisions provides a configurable interface for controlling how many revisions WordPress keeps.

This can be useful when you want a policy such as:

Keep the last:
10 revisions

rather than:

Keep every version since the website was launched.

The goal is not necessarily to eliminate revision history, but to choose a retention level appropriate to the site’s editing workflow.

WordPress can also filter revision limits programmatically

Developers can use the:

wp_revisions_to_keep

filter to control the number of revisions for a given post.

WordPress also provides a post-type-specific filter:

wp_{$post_type}_revisions_to_keep

This means a developer could apply different policies to different content types.

The official wp_revisions_to_keep hook documentation and post-type-specific revision filter documentation describe these mechanisms.

Different post types can reasonably need different limits

Consider:

Blog Posts
→ 20 revisions

Legal Pages
→ 100 revisions

Temporary Landing Pages
→ 5 revisions

Internal System Records
→ no revision support

A single global policy may be adequate for a normal site, but large applications can benefit from more deliberate retention.

What happens when you lower the revision limit?

This requires an important distinction.

If you change the limit from:

100
→
10

WordPress does not necessarily scan the entire database immediately and delete every historical excess revision at configuration time.

WordPress enforces the configured retention as new revisions are saved and removes older revisions as part of that process.

The core wp_save_post_revision() implementation obtains the configured revision limit and removes the oldest revisions when the count exceeds that limit.

Changing the limit and cleaning old revisions are separate tasks

This gives us two different operations:

Revision policy
→ How many should WordPress retain going forward?

Revision cleanup
→ What should happen to excess historical rows already present?

Do not assume changing one setting instantly performs the other operation across every post in the database.

Old revisions can contribute to database bloat

Because revisions use the WordPress posts system, a site with large revision histories can accumulate significant database data.

Consider:

10,000 posts
×
50 historical revisions
=
potentially hundreds of thousands of revision records

The actual footprint depends on the site and stored content, but the scale can become meaningful.

For the broader issue, see WordPress database bloat, explained.

A large revision count is not automatically a performance problem

It would be convenient if database optimization worked like:

More rows = slow
Fewer rows = fast

It does not.

A database with hundreds of thousands of revision rows can still perform well when normal queries, indexes and server resources are appropriate.

Revision cleanup may reduce:

• database size;
• backup size;
• migration size;
• administrative clutter.

It may not magically fix an unrelated slow frontend query.

Do not delete useful history merely to make the database smaller

For a publication with several editors, the ability to restore previous content may be worth far more than a modest reduction in database storage.

Likewise, a legal or compliance workflow may deliberately require extensive content history.

Database cleanliness should serve the application, not become an aesthetic competition over who can produce the smallest SQL dump.

Use Database Optimizer for historical revision cleanup

If a site already contains large numbers of old revisions that are no longer useful, TheOneWP Database Optimizer can target supported cleanup categories such as post revisions separately from other database data.

The important distinction is that the cleanup is explicit.

A sensible workflow is:

1. create a backup;
2. inspect what will be removed;
3. clean the revision history;
4. set an appropriate future retention policy.

Back up before deleting large revision histories

Revision cleanup is destructive.

If those revisions contain content you later need, deleting them removes the easiest in-editor recovery path.

Create a backup first.

Backup Manager can provide a recovery point before database cleanup.

Revision cleanup can help before a migration

A migration copies database rows whether those rows are valuable or not.

Suppose:

Database:
1.8 GB

Revision history:
700 MB

If most of that history is unnecessary, removing it before migration can reduce the amount of data that must be exported, transferred and imported.

The decision should still be deliberate and backed up.

Revisions can matter after accidental editing

A typical recovery scenario looks like:

Editor opens page
        ↓
Deletes an important section
        ↓
Clicks Update
        ↓
Problem discovered later
        ↓
Open Revisions
        ↓
Restore previous version

Without revision history, recovery might require:

• finding the content in a backup;
• copying from a cached version;
• searching old documents;
• rewriting the missing content.

The few database rows suddenly look less offensive.

Revisions can help identify editorial changes

Revision history can also answer questions such as:

When was this paragraph removed?

Which version contained the old price?

Who changed the headline?

What did the page say before the campaign update?

This makes revisions part of editorial accountability, not merely disaster recovery.

Revisions are not a full audit log

However, do not confuse revision history with a complete audit trail.

A revision records content versions.

It does not necessarily record every administrative event such as:

• plugin activation;
• role changes;
• login activity;
• theme settings;
• database queries;
• every custom metadata change.

If formal audit logging is required, use a system designed for that purpose.

Revisions and post locking solve different problems

On multi-user WordPress sites, two editors can potentially work around the same content.

WordPress has separate mechanisms for editing coordination and post locking.

Revision history tells you how the content changed over time.

It is not itself a concurrency-control mechanism.

Revision history is particularly useful on editorial sites

Publications may have workflows such as:

Writer
→ Editor
→ Copy editor
→ Legal review
→ Publisher

Each stage can change the text.

Being able to inspect earlier saved versions makes this chain much easier to manage.

Do not disable revisions on a collaborative site without a strong reason

Disabling them can reduce database growth, but it also removes one of WordPress’s simplest recovery mechanisms.

The trade-off should be understood before changing:

WP_POST_REVISIONS

to:

false

on an actively edited site.

A revision limit is usually safer than disabling revisions entirely

For many websites, a compromise such as:

Keep 10
Keep 20
Keep 50

provides enough recovery history without keeping unlimited versions indefinitely.

The appropriate number depends on how frequently the content changes and how far back editors realistically need to recover.

Static sites may need fewer revisions

A small company website whose About page changes once per year probably does not need hundreds of historical revisions.

A conservative limit can keep useful recent history without retaining every edit since the company’s first WordPress installation.

Frequently edited content may need more

Documentation, legal pages, high-value landing pages and collaborative editorial content may justify a longer revision history.

Again, retention should reflect operational value rather than one universal number copied from a performance tutorial.

Custom post types can produce unexpectedly large revision histories

Plugins and custom applications may register post types that support revisions.

If those objects are saved frequently, they can generate a large number of revision records.

This becomes particularly relevant when a custom post type stores large block structures or page-builder content.

For the content-model side, see WordPress post types vs. custom post types.

Page builders can make individual revisions relatively large

A normal text article may store a relatively modest content payload.

A complex page-builder document can contain substantial structured data.

If every save creates another historical copy of a large content structure, the revision footprint can grow much faster than simple revision counts suggest.

Measure actual database size rather than assuming that:

20 revisions

has the same storage cost for every kind of content.

Revisions appear in REST-based WordPress workflows too

WordPress exposes post revisions through the REST API for supported content.

The official Post Revisions REST API documentation describes endpoints for retrieving and working with revision information.

This matters for:

• the modern editor;
• headless workflows;
• custom JavaScript interfaces;
• external content-management integrations.

Do not expose revision data carelessly through custom APIs

Historical content can contain information that is no longer visible in the current published version.

For example, an old revision may contain:

• removed pricing;
• internal notes accidentally inserted into content;
• unapproved text;
• old contact information.

Custom REST integrations should respect WordPress permissions when exposing revision history.

For the broader security layer, see WordPress REST API security basics.

Can revisions affect backups?

Yes.

Database backups contain the revision rows that exist at backup time.

If a site retains a very large revision history, database dump files can become larger.

This can increase:

• backup creation time;
• compression time;
• remote upload time;
• storage use;
• restore time.

That does not mean revisions should automatically be removed before every backup. It simply means their storage cost is part of the wider retention strategy.

Can revisions affect migrations?

Yes, mostly because they increase the amount of data being copied.

If a migration moves:

500 MB active database data
+
1.5 GB historical revisions

both are still part of the export unless the history is cleaned first.

For database preparation before a site move, see Preparing a WordPress database for migration.

Do revisions affect frontend SEO?

Normal WordPress revisions are not intended to behave like separate public articles competing with the published post.

They are internal historical objects.

You should not create public navigation or sitemap entries for revision records.

The searchable public URL should remain the actual post, Page or custom post type entry.

Do revisions change the post permalink?

No.

Creating a revision does not change the public permalink of the original post.

The revision remains associated with the parent content object.

Changing a permalink or post type is a separate operation and can require redirect handling.

What happens when you delete the original post?

Revision records are tied to their parent content.

WordPress deletion APIs understand revision relationships and provide dedicated revision deletion behavior.

The official wp_delete_post_revision() documentation covers programmatic revision removal.

Do not treat revisions as unrelated posts and delete arbitrary rows from wp_posts without understanding those relationships.

Do not delete revisions with random SQL snippets

You will find examples such as:

DELETE FROM wp_posts
WHERE post_type = 'revision';

Such queries can indeed remove revision rows.

That does not make blindly executing them on an unfamiliar production site good maintenance.

Before destructive SQL:

• create a backup;
• confirm the table prefix;
• understand plugin revision integrations;
• understand metadata relationships;
• test the operation where practical.

Use WordPress-aware cleanup where possible

WordPress and plugin APIs can account for related data and hooks that direct SQL may bypass.

Database Optimizer is better suited to routine revision cleanup than pasting an anonymous SQL query into production because someone on a forum marked it “SOLVED” in 2014.

How should you choose a revision limit?

Start from the editing workflow.

Small brochure website

Possible strategy:
5–10 revisions

Enough to recover recent mistakes without retaining years of minor edits.

Actively edited company website

Possible strategy:
10–25 revisions

A larger window gives editors more recovery options.

Editorial publication

Possible strategy:
25–100+ revisions

Extensive history may be genuinely useful.

Compliance-sensitive content

Do not choose the retention policy from a generic performance article.

Determine the organization’s actual record-keeping requirements first.

A practical WordPress revision workflow

A sensible revision strategy can look like this:

1. Confirm which post types support revisions.
2. Estimate how frequently important content changes.
3. Inspect existing revision counts.
4. Keep enough history for realistic recovery needs.
5. Set a sensible revision limit where necessary.
6. Keep autosaving frequent enough to protect active editing.
7. Create backups independently from revision history.
8. Clean excessive historical revisions only after review.
9. Recheck database size after cleanup.
10. Revisit the policy if the site’s editorial workflow changes.

WordPress revision troubleshooting checklist

If revisions do not appear or behave as expected, check:

• whether the post type supports revisions;
• whether at least one revision has actually been created;
• the value of WP_POST_REVISIONS;
• whether a plugin filters wp_revisions_to_keep;
• whether a post-type-specific filter changes the limit;
• whether custom metadata is revision-enabled;
• whether a database cleanup plugin recently removed old revisions;
• whether the editor is showing the expected revision interface.

Common WordPress revision mistakes

Confusing revisions with autosaves

They are related but have different purposes and retention behavior.

Assuming autosave creates a permanent new row every minute forever

WordPress normally keeps one autosave per user per post and replaces it with newer autosaves.

Assuming revisions back up the entire site

They protect selected post content, not plugins, themes, uploads and the complete database.

Assuming every custom field is restored

Revision support for additional metadata depends on implementation.

Setting WP_POST_REVISIONS to 0 expecting unlimited history

Zero disables normal revision retention.

Lowering the revision limit and expecting immediate global cleanup

Historical cleanup and future retention are separate concerns.

Disabling revisions purely because the database is large

First determine whether revisions are actually the cause and whether their history remains useful.

Deleting revisions before creating a backup

Once removed, the convenient in-editor recovery history is gone.

Using raw SQL without checking plugin behavior

Custom integrations can extend the revision system beyond basic core fields.

Keeping unlimited revisions forever without reviewing whether they are useful

Default behavior is not automatically the ideal retention policy for every site.

WordPress post revisions checklist

• Understand that revisions are historical content snapshots.
• Keep revisions separate conceptually from autosaves.
• Confirm the post type supports revisions.
• Use the Revisions screen to compare versions.
• Review a restored version after restoration.
• Do not assume every custom field participates automatically.
• Keep backups independently from revisions.
• Use source control separately for code.
• Choose a revision limit based on editorial needs.
• Remember that zero disables normal revisions.
• Keep autosave frequency appropriate for active editors.
• Monitor revision growth on highly edited sites.
• Consider page-builder payload size as well as revision count.
• Back up before historical cleanup.
• Use WordPress-aware cleanup tools where practical.
• Measure database size before and after large cleanup operations.
• Retain longer history when business or compliance requirements justify it.

Related WordPress revisions and database guides

For the broader content-history, editorial and database workflow, continue with:

• WordPress database bloat, explained
• Optimizing the WordPress posts table
• Preparing a WordPress database for migration
• Setting up a client review workflow in WordPress
• Sharing a WordPress draft without creating an account
• WordPress post types vs. custom post types
• WordPress REST API security basics
• Post Revisions
• Autosave Interval
• Database Optimizer
• Backup Manager

Final thoughts

WordPress post revisions are a built-in content history system designed to make editing recoverable.

Every deliberate save can preserve an earlier version of revision-enabled content, while autosaves provide a separate recovery mechanism during active editing. The historical records live within WordPress’s post architecture and can be compared or restored through the editor.

That convenience has a storage cost, especially on sites with thousands of heavily edited posts or large page-builder documents. But the solution is rarely to disable revision history indiscriminately.

TheOneWP Post Revisions can set a practical retention limit, Autosave Interval controls the separate editor recovery interval and Database Optimizer can address historical revision data when cleanup is actually warranted.

The useful question is not whether revisions consume database space. Naturally they do; preserving history has apparently failed to discover a storage medium made of wishes. The useful question is how much history the site genuinely needs.

Keep enough to recover mistakes and support the editorial workflow. Limit or clean the rest when the storage cost no longer provides corresponding value.