WordPress Revision History: Compare and Restore Revisions

What WordPress revision history does

A regular revision is a stored version of a post or page after an update. It can preserve changes to the title, content, excerpt, author, and other revisioned fields supported by the post type. The current post remains the current post until a revision is restored. Looking through history therefore does not alter the published page.

Revisions are useful when a paragraph disappears, a layout change goes sideways, or an editor needs to understand who changed what and when. They are also useful during review. A timestamp and author name give an editorial team more context than a vague memory that “the page looked better yesterday.”

Do not confuse a revision with an autosave. Autosaves are temporary recovery records. WordPress keeps at most one autosave per user for a given post, and a newer autosave replaces that user’s older autosave. Autosaves do not overwrite the published post. They are the reason a browser crash or lost connection does not necessarily erase the work in an open editor.

That distinction also explains why a revision count is not a minute-by-minute counter. Normal updates can create regular revisions, while autosaves follow their own per-user rule. A site with several editors can have one autosave for each editor, plus the regular revisions the site keeps.

Find revisions in WordPress 7.0

In the block editor, open the post or page that needs inspection. Open the Settings sidebar, choose the Post or Page tab, and click the number next to Revisions. If no number appears, that item may not have a revision available yet, or its post type may not support revisions.

WordPress 7.0 made the comparison more visual. The WordPress 7.0 Field Guide describes Visual Revisions as a slider-based comparison with a summary in the document inspector, color indicators, and change sizes that help you jump to a location. ^[2]

The exact labels can vary slightly when plugins extend the editor, but the job is the same: identify the correct post, open its history, and inspect a saved version before restoring anything. Take a moment to confirm the post title and the revision author when several editors work on the site.

Compare and restore the right version

Use the slider at the top of the visual revisions screen to move through the available versions. The screen highlights inserted, deleted, and changed content. A marker or summary can take you to a changed area instead of forcing you to scan the whole post from top to bottom.

Read the change in context. A highlighted block may be a deliberate edit, not an error. Check the title, headings, links, images, and reusable sections around the change. If a newer paragraph is missing from an older revision, restoring that older version could bring back the typo you meant to remove.

Restore after a quick safety check

• Confirm the post or page title and the revision date, time, and author.
• Check that the version contains the content you actually need, not just the first visible fix.
• Compare the surrounding headings, links, embeds, and images for newer work that should remain.
• Restore only after the comparison makes the intended result clear, then review the editor and published page before continuing.

Restoring a revision moves that saved version into the current editable post. It is not a magic merge of every good sentence across two versions. If the change is substantial, copy the useful text into a new draft or take a staging snapshot before restoring.

Classic revisions and autosave recovery

Sites on WordPress 6.9 or earlier use the classic revisions screen by default. It shows a side-by-side comparison of the HTML version, with Previous and Next controls and a timeline. In WordPress 7.0, the sidebar also offers Open classic revisions screen when that view is more useful for a particular comparison.

Classic Revisions also has a compare-any-two mode. That is handy when the important change is not the immediately previous version. Select the earlier and later points deliberately, then read the differences before restoring. The visual screen is easier to scan, while the classic screen can be useful when exact markup or a long sequence of edits needs closer inspection.

Treat autosave as a recovery prompt

If the editor reports that an autosaved version is newer than the version on screen, compare it before dismissing the message. That copy may contain the paragraph lost when the browser closed. It is still a recovery record, not proof that the published page changed. Save the intended content normally after reviewing it.

Multiple users make the distinction more important. Each user can have one autosave for the same post, so the editorial team should check the author and timestamp instead of assuming the newest-looking entry came from the last person who published.

Set a retention limit without guessing

WordPress keeps every regular revision by default unless the site changes that policy. The wp_save_post_revision() developer reference explains that WordPress creates a revision for the current post version, checks whether revisioned fields changed, and removes older regular revisions when the configured limit requires it. ^[3] This is why saving a post is not the same as storing every keystroke forever.

The setting is controlled by WP_POST_REVISIONS in wp-config.php. ^[4] Its important values are:

• true or -1: keep every regular revision.
• false or 0: keep no regular revisions, except one autosave per user for that post.
• A positive integer: keep that many regular revisions, plus one autosave per user for that post.

The number is a retention rule, not a promise that old rows disappear the moment the value changes. With a positive finite limit, WordPress removes older regular revisions on a later qualifying update. Setting false or 0 stops future regular revisions but does not delete the existing ones. A large editorial site may choose a finite history after measuring its workload and confirming that the team has another rollback plan. A small site with occasional edits may gain more from keeping a useful history than from chasing a theoretical database saving.

The wp_revisions_to_keep() reference shows that WordPress determines the count for each post and that filters can change it by post type. ^[5] That is a reason to verify the real site configuration before assuming every post follows the same policy.

When cleanup or disabling makes sense

Do not delete revisions merely because a dashboard count looks large. First identify a real problem: a measured database constraint, a maintenance policy, or a retention requirement that the current setting does not meet. Take a backup or staging snapshot, confirm the rollback copy can be retrieved, and document what the editors still need to restore.

WordPress’s wp_delete_post_revision() function deletes the row corresponding to a specified revision through WordPress’s own deletion path. ^[6] Do not replace that path with a blanket SQL delete in phpMyAdmin, which bypasses WordPress’s normal cleanup process. Deletion is a destructive maintenance action, not a harmless tidy-up. A cleanup plan should also account for the fact that another process, post type, or editor may depend on the history.

Disabling revisions is an even stronger choice. It can remove the ordinary recovery path that protects editors from accidental changes, and it does not turn a complex site into a simpler site by itself. Consider it only for a narrowly justified workflow with a tested backup and an explicit replacement for editorial recovery. Active content teams usually need revisions, even if they later choose a sensible limit.

There is no universal rule that revisions hurt performance or search rankings. Their effect depends on the site’s database, queries, hosting, publishing volume, and other work happening on the request path. Measure before changing a safety feature, and check the result after the change.

A practical revision-history checklist

• Open the correct post or page and confirm the revision count in the Settings sidebar.
• Use the WordPress 7.0 visual screen, or the classic screen for older sites and exact markup comparisons.
• Check the timestamp, author, title, content, links, images, and surrounding blocks before restoring.
• Remember that autosaves are per-user recovery records, not permanent revisions for every minute.
• Choose a WP_POST_REVISIONS policy only after considering the team’s rollback needs.
• Back up before deleting history, and do not use cleanup as a substitute for diagnosis.
• Do not disable revisions unless the workflow has a tested recovery alternative.

For most WordPress sites, the best revision strategy is modest and boring: keep enough history to recover from real editorial mistakes, verify the version before restoring it, and measure before changing retention. The visual revisions screen makes the first two jobs easier. The retention setting is there when a measured need exists, not because every revision is guilty by default.