Overwritten WordPress draft or post: recover an earlier version

Identify what was overwritten

Your post still exists, but a recent paragraph has disappeared, an older wording has replaced it, or the draft now contains an incomplete version. The goal is to recover the passage you want without losing changes that remain useful and without rolling the entire site back to an earlier date.

Start by describing the difference: a specific title, a recognizable sentence, an added image or an entire section. Note when you last saw the correct content and when you noticed its replacement. These reference points will help you choose a version by its contents, not just its date.

This guide concerns a document that is still present. It covers neither recovering a deleted post from the trash, resolving an author conflict nor repairing an invalid block. If the text is intact but its block no longer works, switching revisions may not solve the component’s problem.

Immediately preserve the current state

Do not reload a tab that still shows useful text. Before closing it, signing out or accepting a restoration, copy what remains into a local document. In the block editor, look for the Copy all content command in the main options menu. Actually check the beginning, the affected passage and the end of the copy.

If that command is unavailable, copy the accessible text, title and excerpt separately. Also keep links and media URLs. For a complex layout, add screenshots: they serve as reference points but do not replace the blocks or their settings.

Give the copies explicit names, such as “current state before recovery” and “recovered passage.” Keep them separate. Clicking Save merely to secure an uncertain state can change available autosaves or advance a limited history. The copy outside WordPress must therefore come before any tests.

If the desired text remains visible on a public page, preserve it too, without assuming that it matches the latest draft. Do not clear browser data during this search: it may contain a working copy that is still usable.

Confirm the right document and the required permissions

Record the site, title, content type and, if possible, the post ID from its editing URL. Two documents can have the same title. You need to recognize the one whose contents were replaced without accidentally creating a second public post.

Also note the WordPress version and editor used. A classic theme does not necessarily mean the old editor is in use: the screen actually open matters more than the theme’s name. Revision interfaces may differ according to the version and installed tools.

Your account must be allowed to view and edit this document. Writing permissions do not automatically provide access to hosting backups. On WordPress.com, the role and plan features matter; on multisite, the network manager may be needed. Request targeted access or assistance without sharing a password or broadening permissions just to try something.

Distinguish a revision, an autosave and a site backup

A revision is a saved version that WordPress retained in the document’s history. It lets you compare several states. It does not record every keystroke, and the visible list does not guarantee that all intermediate stages were kept.

An autosave protects a working state according to the editor’s mechanism. It may be stored on the server or, for certain recovery features, in the browser. When retained as an automatic revision on the server, WordPress keeps at most one such copy per user and per document; the next one replaces the previous one. It does not automatically replace already published content. However, for the author’s own draft without an active lock, the core mechanism can update that draft directly. It is therefore not necessarily a separate copy of its saved state.

A site backup is a restore point provided by the host or an existing backup system. It may include the database and files. Recovering a post requires the corresponding data; an archive containing only images and the theme is not enough.

Choose the path that could plausibly hold a copy: recent work still accessible, saved history or an earlier backup. No new tool can recreate a version that was never retained.

Approach 1: look for a working copy that is still available

Prerequisites: keep the affected tab open and prepare a local document. This path is suitable after an accidental closure, a lost connection or text that differs from what you expected. Before saving again, look for the specific sentence identified at the start.

1. Examine local copies and tabs that are still open. If one shows the correct passage, immediately copy it into the local document with its title and useful links. Check the first and last sentences copied; do not reload that tab before preserving its contents.
2. On WordPress.com, if the tab offers a different browser copy, inspect it before closing the tab. The documentation specifies that this copy is tied to the tab: closing and reopening the document does not bring it back. Leave the comparison without restoring if it does not contain the passage you need.
3. If a more recent autosave stored online is offered, open its comparison before choosing it. Look for the desired passage rather than relying on the time. A more recent date may already represent the wrong wording; preserve any useful fragment elsewhere.
4. After examining these suggestions and checking your external copies, keep just one editing tab for this document. Close additional instances whose different states could produce competing autosaves. Do not publish a draft created to check an excerpt.
5. The expected result is a recovered passage compared with the current state. If no copy contains it, move on to revisions without repeatedly opening and closing tabs. To abandon a test, leave the suggestion without accepting it; if the editor contents have already been replaced, use the initial external copy before saving.

Assess the limits of autosave

The absence of a recovery message does not prove that no version exists on the server. Conversely, a save indicator does not prove that the desired passage reached the server before the incident. An expired session or rejected save may leave text visible only in the browser.

Do not install a plugin or change the save frequency to recover this text retroactively. A more frequent setting does not reconstruct missing data. Do not use browser cleanup as a solution to lost content either.

When the autosave contains the correct passage, compare it with the current state and recover only what is missing. If it is older, incomplete or already replaced, keep its useful contents and continue. The expected result is verifiable text; the mere presence of an autosave is not successful recovery.

Approach 2: open saved revisions

Prerequisites: the exact document is identified and its current state is preserved outside WordPress. Your account must be able to view its history. This search starts in read-only mode; the Restore button is not a preview button.

1. Under Posts or Pages, open the document, then the editor’s sidebar settings. In the Post or Page tab, click the number next to Revisions. Check that you are viewing the post’s history, not the history of a site template.
2. Identify the available interface. Since WordPress 7.0, revisions can open in the block editor’s new visual screen. WordPress 6.9 or earlier uses the classic HTML comparison. WordPress 7.0 also lets you open that classic screen from the revisions panel.
3. Using the list or slider, first select a version from before the suspected overwrite. Do not click Restore. Read its date and author as clues, then actually look for the missing sentence or section; a version by the right author may still be incomplete.
4. Compare the recovered passages with newer corrections that must be retained, following the sections below. The expected result is an identified useful version and a choice between partial extraction and full restoration. You can leave the history without restoring if the comparison does not justify a change.
5. If the section is missing, confirm permissions, the document and available panels, then have an administrator check revision retention. Stop this path when no useful state exists: changing theme or editor does not manufacture the missing history.

Compare the contents before choosing

Find the sentence you need and read what surrounds it. Also compare paragraphs added since that date. Restoring a version that is correct for one passage can remove a useful correction made elsewhere in the post.

In a comparison screen, color markings help locate additions and removals. Check which state is on each side and which dates are selected. If the interface allows comparison of any two revisions, use that option to isolate the relevant change, not to automatically choose the oldest.

With an HTML comparison, avoid interpreting every different line as lost text: settings or markup may also change. If you cannot distinguish the content from its structure, ask for targeted help instead of copying an incomplete fragment.

Prepare a simple decision: recover only a section, restore the whole document or continue toward an external backup. The comparison should explain this choice and the elements that must remain intact.

Recover only the passage you need

Prerequisites: a revision contains the desired passage and the current version has improvements worth retaining. On WordPress.com, the documented visual history allows blocks to be copied; do not assume that older interfaces offer the same commands.

1. In the chosen revision, select only the useful block or blocks, then use Copy in their menu. Next, leave the history without restoring the complete revision. If you have only an HTML comparison, do not cut out a random block fragment: have the passage extracted or copy the plain text with its links.
2. Paste the result into a separate draft and check the section heading, last sentence, lists and associated media. Save this checking draft and reopen it without publishing it. The content must remain complete and editable.
3. After validation, transfer only the necessary part into the original post. Check that it does not duplicate an existing section and that recent improvements remain intact. Confirm the document’s identity before saving with the intended status.
4. If the transfer is wrong, remove this targeted addition using the previous state retained in the local file. Keep that file until the saved content is validated and, for a public post, its display is checked. It avoids restoring the whole post again merely to correct a partial extraction.

Restore the entire document with the right precautions

A full restoration is justified if almost the entire document needs to return to an earlier state and newer changes have been preserved. If someone else is responsible for publication, coordinate this decision with them before changing a public post.

The Restore button is not a preview. The core restoration mechanism updates the document without automatically returning it to draft: an already published post may therefore display the old wording immediately. WordPress.com also documents this behavior. Do not rely on a second Publish button to prevent a visible change. Check the selected document and version before confirming.

A core revision covers, in particular, the title, content and excerpt. Do not regard it as a snapshot of every document setting: categories, featured image or plugin data must be checked separately.

After restoration, immediately check the result and any recent elements to reintroduce. If you chose the wrong version, use the preserved current state or another revision still available, after comparing them. Do not describe rollback as guaranteed: a limited history may change, and your external copy remains essential.

Understand an absent or overly short history

The number of retained revisions may be limited by WordPress configuration, the content type or a site rule. Earlier cleanup may also have removed versions. Ask the person responsible to check the policy actually applied, not just the default value described in a tutorial.

Increasing that limit now does not recreate revisions already deleted. Avoid repeated saves during the search: when retention is limited, the oldest states may be eliminated as updates accumulate. Preserve useful versions as soon as you find them.

The post’s history is not necessarily the history of a page builder or a field managed by a plugin. If the missing text comes from one of those tools, note its name and have its documented mechanisms checked. Do not assume that restoring the post body puts all its data back.

Without a usable revision, move on to hosting if an earlier backup exists. Do not try to manually create revisions in the database or run a query found on a forum.

Approach 3: request targeted recovery from a backup

Prerequisites: have authorized hosting access or authenticated access to its support, a copy of the current state and a likely time period. This path looks for an existing archive; installing a backup tool now does not recreate the lost post.

1. Prepare the request with the site, post ID, period sought and a recognizable sentence. Specify that you want to extract an old version of one document without replacing production, and ask whether the provider offers isolated inspection or targeted extraction.
2. In the available panel, examine archive dates, their time zone and their contents. Choose a point after the desired passage was saved and before it was overwritten. Yesterday’s backup cannot contain text written only this morning.
3. Have the presence of the database containing the post confirmed. Files supply media and components, among other things; an archive of files alone is not enough. Do not confuse restoration of a database or entire table with restoration of one document: other posts, comments, accounts and orders would be affected.
4. Before any restoration, have a separate destination, its database and disabled automation confirmed, as described in the next section. Also check what already exists at that destination and protect that work. Never click a global restoration solely to inspect the contents of the selected point.
5. The expected result is an excerpt obtained from an isolated copy, to compare before transferring it back selectively. If no backup covers the period or isolation cannot be guaranteed, stop and ask support to clarify the limitation. Abandoning this path leaves production unchanged; do not push the entire old copy onto the site to recover a few paragraphs.

Examine the old backup outside production

A staging environment is a separate environment in which an old copy can be examined without changing the public site. Have the separate database, protected access and disabling of outgoing messages, notifications, payments and external automation confirmed before starting that copy. A different address alone is not proof of isolation.

If you already use Kinsta, its documentation provides for restoring a backup to an existing staging environment: in MyKinsta, open the site, then Backups, and choose the staging destination with Restore to. Carefully check that destination and also protect any work already present on staging. This path is not universal.

On WordPress.com, backups and their download depend on account features. If available, Jetpack then Backup lets you choose a date; the download command is in the menu associated with the restore point. Ask support how to examine this archive in isolation. Selective restoration does not automatically mean restoration of a single post.

Once a competent person has opened the copy, find the document and extract the useful passage. Do not push the entire staging environment to the live site to recover a few paragraphs.

Reintegrate and check the result

Recover the text into your local document, then into a checking draft. Look for test-copy addresses in links and media. Reuse the appropriate production media; do not leave images dependent on a staging environment that will eventually disappear.

Then transfer the validated content into the original document. Preserve its URL and editorial identity rather than publishing the checking draft as a duplicate. Before saving, compare the title, recovered passage, retained recent sections and settings that were not part of the restoration.

Save with the intended status, then reopen the document to check that the text is actually retained. For public content, also check the page readers see, its links and its mobile presentation. If the preview differs from the saved content, do not immediately repeat restoration: first identify what you are viewing.

Keep the starting copies and recovered excerpts until validation is complete. Note where the passage came from, the date of the restore point used and the correction applied. You will then be able to explain what was recovered and what was not.

Know when to stop and better protect future work

If no copy contains the passage, say so clearly. A plugin installed after the loss, a theme change or an increase in revision count cannot guarantee its return. You may still need to reconstruct the text from authorized personal notes, distinguishing that rewrite from recovery.

Ask support to confirm the backup periods actually available and whether targeted extraction is possible. Do not publish a database archive or confidential draft in a public help space. Send only what is necessary, without cookies, credentials or private data unrelated to the issue.

For future work, keep an external copy at important writing milestones and check that an appropriate backup exists before a risky change. Have revision and backup retention clarified. The useful check is not merely seeing a Save button: it is being able to reopen the right document, find its text and know which copy to use if something goes wrong.

Find revisions with WP-CLI in read-only mode

If the interface does not allow comfortable comparison, the maintainer can list revisions using WP-CLI if it is already installed. Confirm the correct site and post ID: 123 below is an example. A revision’s ID differs from its parent post’s ID.

Run and read the first line before adapting the second. A limit of one hundred results is not a complete inventory if the history is longer. The post_name field helps identify an autosave without replacing a reading of its contents.

The second command displays potentially private content in the terminal; use a non-shared session and keep the excerpt in a private folder. These reads restore nothing. Copy only the useful passage into your comparison draft, then check block boundaries. An empty result does not create any revision or authorize a global database restoration.

wp --path='/chemin/wordpress' --url='https://site.example.test' post list --post_type=revision --post_status=inherit --post_parent=123 --posts_per_page=100 --orderby=ID --order=DESC --fields=ID,post_date,post_author,post_name --format=table
# Après sélection d’un identifiant de révision réellement retourné :
wp --path='/chemin/wordpress' --url='https://site.example.test' post get ID_REVISION_CONFIRME --field=post_content