WordPress Revisions and Autosaves in the Block Editor

WordPress revisions preserve saved versions of a post or page. Autosaves preserve a temporary recovery version for each editing user.

Use revisions for earlier saved states. Use autosave recovery after interrupted editing. Use backups for site-wide data loss.

These layers overlap, but they are not interchangeable. Choosing the wrong one can restore incomplete content or miss external dependencies.

Revisions, autosaves, undo, and backups compared

Recovery layer	Best use	Main limit
Undo and redo	Recent session actions	Session history can disappear
Autosave	Interrupted unsaved work	Only one current autosave per user
Revision	Earlier saved versions	Does not cover every site dependency
Backup	Broad site or database recovery	Restoration can affect much more content

Do not restore a whole database for one deleted paragraph. Do not trust one autosave after a site-wide failure.

What WordPress stores as a revision

The official revisions guide says saved drafts and published updates create revision records. WordPress stores them beside their parent content.

By default, tracked fields include title, author, content, and excerpt. Plugins can affect revision behaviour around additional data.

Block markup lives inside post content. Therefore, revisions can preserve serialized blocks and their saved attributes.

External records may live elsewhere. Media files, plugin tables, options, synced patterns, and remote services need separate consideration.

What an autosave preserves

Autosave protects work between deliberate saves. WordPress stores it as a special revision rather than overwriting published content.

There is normally one autosave per user for each post. A newer autosave replaces that user’s older autosave.

Multiple editors can therefore have separate autosaves. This design avoids one person’s recovery version replacing another person’s version.

Autosave remains a recovery aid, not a version archive. Save meaningful checkpoints when the draft reaches a useful state.

How local autosave fits

The block editor can also make local autosave data available through browser storage. This may help during connection failures.

The core editor data reference distinguishes server and local autosave actions. Implementations can vary across environments.

Browser storage is not a durable backup. Clearing site data, changing browsers, or using another device can remove access.

When WordPress offers a browser backup, compare it before restoring. Do not assume the local version is newest or complete.

Find the Revisions link

1. Open the relevant post or page.
2. Open the Settings sidebar.
3. Select the Post or Page tab.
4. Find the Revisions count.
5. Select it to open comparison.

The link appears only when revisions exist and the current user can access them. Interface placement can vary through plugins.

If the link is absent, confirm saved versions actually exist. Then review post-type support, permissions, configuration, and plugin interference.

Use the current WordPress revisions screen

WordPress 7.0 introduced a revised comparison screen. It uses a top slider and colour markers for changed regions.

• Green identifies inserted content.
• Red identifies deleted content.
• Yellow identifies changed content.
• Markers jump to relevant locations.
• A control toggles change highlighting.

WordPress 6.9 and earlier use the classic revisions screen. WordPress 7.0 can still expose that classic view.

Do not rely on remembered screenshots when training. Confirm the site’s installed WordPress version and active interface.

Read revision differences carefully

Revision comparison often displays serialized or text-oriented differences. Complex block changes can look noisier than their visual result.

Identify the author and timestamp first. Then locate the relevant section. Compare meaning, structure, links, and block attributes.

A small visual edit can change several markup lines. A large factual edit can change one sentence. Judge consequence, not diff size.

Autosaves are marked during revision review. Confirm whether the candidate came from a deliberate save or temporary recovery state.

Compare any two versions when needed

The classic revisions screen supports comparing any two revisions. Two handles define the older and newer versions under comparison.

This helps isolate a change spanning several saves. It can also show when a problem first appeared.

Record the chosen timestamps before restoration. Complex investigations need an audit trail. Screenshots can support review but not recovery.

Restore a revision safely

1. Identify the exact affected content.
2. Save or copy the current version.
3. Open revision comparison.
4. Verify author, time, and changed sections.
5. Choose the intended revision.
6. Select Restore.
7. Review the restored editor content.
8. Preview the frontend.
9. Save only after verification.

Preserving the current version gives another recovery path. Restoration should never begin with “this one looks approximately old enough.”

Restore only the missing section when practical

A full restore replaces more content than one paragraph needs. Consider extracting the missing section from an earlier version instead.

Open the revision carefully and copy only trusted content. Keep block boundaries intact. Paste into a draft first.

Review duplicated anchors, links, media, and pattern references. Partial recovery can still carry stale page-specific values.

Use full restoration when many connected changes must return together. Choose scope from evidence, not convenience.

Recover after a browser crash

1. Reopen the same browser and site.
2. Open the affected post.
3. Read every recovery notice.
4. Compare the offered backup with current content.
5. Restore only the newer useful version.
6. Inspect block structure and settings.
7. Save a deliberate checkpoint.

Avoid clearing browser data before checking local recovery. Avoid editing heavily before comparing. New work can complicate the decision.

Recover after an internet interruption

Stop making broad edits when saves fail repeatedly. Preserve visible content in a trusted local document if necessary.

Confirm connectivity and site availability. Then reopen the editor. Compare server content, autosave notices, and any local backup.

Do not paste an entire fallback over recovered blocks automatically. Plain-text copies may omit links, media, structure, and attributes.

After recovery, save and preview. Report repeated REST or network failures. Recovery should not become the normal publishing workflow.

Handle multi-user autosaves carefully

Each user can have an autosave for one post. Editing locks and takeover messages still require deliberate coordination.

Do not assume the latest timestamp belongs to the approved editor. Check authorship. Compare content before restoring another person’s work.

Assign one active owner during high-risk edits. Use review workflows instead of simultaneous unsupervised changes to one complex page.

When conflicts recur, improve governance. Autosave can preserve versions. It cannot decide which person’s changes should win.

Understand what revisions miss

• Deleted or replaced plugin code.
• Changed theme styles and templates.
• Missing media files.
• External service data.
• Some plugin settings and custom tables.
• Site-wide configuration changes.
• Database corruption outside the post.
• Expired remote resources.

A revision can restore serialized block markup while its provider remains missing. The block may still appear unsupported or invalid.

Revisions do not replace backups

Revisions live inside the same WordPress database. A database loss can remove the post and its recovery records together.

Backups should cover databases, uploaded files, configuration, themes, and plugins. Test restoration. An untested archive is only optimism.

Keep backups outside the hosting account when practical. Apply retention matching business risk. Protect backup access and personal data.

Use revisions for narrow editorial recovery. Use backups when the required state extends beyond one content record.

Configure revision retention deliberately

WordPress can keep every revision, disable regular revisions, or cap retained revisions. Configuration can use WP_POST_REVISIONS.

• true or -1 keeps every revision.
• false or 0 disables regular revisions.
• A positive integer caps stored revisions.
• An autosave can remain outside that regular cap.

Developers can also filter revision counts by post. Hosting platforms or plugins may impose their own retention policies.

Confirm actual behaviour before promising recovery depth. Documentation should state the site’s policy, not WordPress defaults alone.

Do not disable revisions for imaginary performance gains

Revision rows increase database size. That does not automatically cause meaningful frontend slowness. Measure the actual database and query behaviour.

Disabling recovery can cost more than storage. Editorial teams need evidence before changing retention. Consider a sensible cap first.

Clean-up tools can delete history permanently. Back up before bulk deletion. Verify which post types and dates the tool targets.

Use revisions during editorial approval

Revisions can show what changed after approval. Record the approved timestamp. Compare later versions when accountability matters.

Revision history is not a complete approval system. It may lack comments, required sign-off, and decision context.

Pair it with named statuses or external review records. Link decisions to version timestamps. Keep sensitive discussions outside public content.

Use the REST API for audited recovery tools

The post revisions REST reference exposes revision and autosave endpoints. Authenticated tools can list and retrieve version records.

Automation must preserve permissions, authorship, and scope. Never expose private revisions through an unauthorised custom endpoint.

Test custom recovery tooling on staging. Include pagination, post types, metadata, and error handling. Log every restoration action.

The standard editor remains safer for occasional recovery. Build custom tools only when repeated operational need justifies maintenance.

Verify revision support for every content type

Posts and pages normally support revisions. Custom post types can register different capabilities and feature support. Test each editorial type.

Create a draft, save several meaningful changes, then find its Revisions link. Confirm supported roles can open comparison.

Do not infer support from another content type. A product, event, or case study can use different registration and permissions.

Record unavailable recovery in the operating guide. Editors need an alternative before the first accidental deletion.

Check plugin-managed fields separately

Plugins can store important values outside default revision fields. Examples include form configuration, SEO data, product settings, and relationships.

Change one plugin field on staging and save. Compare revisions, restore an earlier version, then inspect the field again.

If the value does not restore, document that boundary. Use provider-supported backups or history for that data.

Visible block recovery may still leave external configuration changed. Test the complete business outcome, not only canvas markup.

Treat published restoration as a release

Restoring a published page can change visitor-facing content after the next update. Follow normal approval for legal, pricing, or regulated pages.

Preview the restored state before updating. Check links, dates, prices, disclosures, forms, schema, and shared content.

Record who approved restoration and why. An older version can contain facts that were deliberately retired.

Use maintenance or staging when restoration needs extensive repair. Recovery speed should not bypass publication safety.

Audit hosting and cleanup policies

Hosts and optimisation plugins can limit or delete revisions. Database tools can also remove records during scheduled cleanup.

Review active retention settings and schedules. Run a controlled save, wait through cleanup, then confirm expected versions remain.

Document the shortest guaranteed recovery window. Avoid promising unlimited history when another system keeps only recent records.

Changes to retention need ownership and rollback. Database size alone does not prove the current policy is harmful.

Create a recovery runbook

1. Identify the missing or incorrect state.
2. Preserve the current version.
3. Choose undo, autosave, revision, or backup.
4. Confirm author and timestamp.
5. Compare content and dependencies.
6. Restore the narrowest useful scope.
7. Check block validity.
8. Preview frontend output.
9. Document the recovery.
10. Fix the underlying workflow problem.

Practise this runbook on staging. Recovery during panic magnifies ambiguity. Familiar evidence makes the production decision quieter.

Repeat the exercise after major WordPress, theme, or provider changes. Record timing and missing permissions. Update screenshots and contacts. A recovery guide must match the interface people will actually face. Keep the evidence current. Stay ready.

Frequently asked questions

The verdict

Recovery works best when specialist blocks preserve valid serialized content. Test free plugins first. Then compare the $299 lifetime suite when several Pro blocks fit maintained sites.