Recover a deleted WordPress post without restoring the entire site

Look for targeted recovery before restoring a backup

A post disappeared after deletion and you want it back without erasing recent site changes. The right approach is first to look for its existing record. If it is still in the Trash, WordPress can restore it directly. If permanently deleted, another copy of its content is needed; a backup should not automatically replace the live site.

This guide addresses a deleted post. If the post still exists but contains the wrong text version, revisions offer another approach. If its address works but it is only missing from the blog, first check categorization and list display. These situations do not require recreating a publication.

Prepare its title, old address, approximate date, and author name. If you have an old administration link, also keep its identifier. Work with an account authorized to view and edit the post. An account limited to its own publications may not see the same set as an editor.

The Trash is available on self-hosted WordPress and WordPress.com with permissions for the relevant content. Possibilities for restoring a backup into a separate installation, however, depend on the host and plan. In multisite, recovery involving the shared database is prepared with the network administrator; the correct subsite’s dashboard remains the starting point.

1. Note the content sought and approximately when it disappeared.
2. Select the correct site in the dashboard, especially on WordPress.com or multisite.
3. Keep the old address and available information in a note.
4. Start with post statuses, then the Trash; do not restore any backup over production yet.

Rule out a status change or wrong location

A publication may have changed title, become a draft, or been assigned to another author. A public search does not prove deletion. Open Posts → All Posts and examine visible statuses. If you are actually looking for a page, use Pages: both lists have their own Trash.

Remove date or category filters that might hide the result. Search for a distinctive title fragment, then another if the first finds nothing. For a custom content type, open its specific list. Do not immediately create a new post with the same title: you risk a duplicate if the original reappears.

This check is read-only. The expected result is either a found record whose status you can examine, or a sufficiently clear search scope to continue. If other authors’ posts are missing and your permissions are limited, have an editor repeat the search with their own account.

1. Open the list matching the content type sought.
2. Reset filters and examine All, Drafts, Pending, or Private according to available statuses.
3. Search several title words separately.
4. Open a found record before changing its status.
5. If none matches, move to the Trash for that same list.

Approach 1: restore one post from the Trash

This procedure is appropriate when the record is still in the Trash. It requires an account allowed to restore it. In Posts → All Posts, open the Trash filter above the list. Check the title, author, and other available clues before choosing Restore. Do not select an action for the entire Trash.

The expected result is the return of this record to active content, normally as a draft in current WordPress core versions. Restoration therefore must not be equated with republication. Site customization may change the resulting status; the following check remains necessary.

This method retains the existing record and identifier. If you restored the wrong post, move only that record back to the Trash after confirming its identity. Do not use Delete Permanently to undo the test.

1. Open Posts → All Posts → Trash.
2. Find the post by its title and expected author.
3. Hover over its row and click Restore.
4. Return to the post list, then open the restored record.
5. Check its status before any other action.
6. Save its editing address in your note to avoid confusing this record with a duplicate.

Check the recovered draft before putting it online

Open the restored post and compare its beginning, ending, and several distinctive passages with your recollection or documents. A record returning does not guarantee its text was complete when deleted. Also check categories, tags, and publication settings visible in the Post panel.

In current WordPress, core normally uses Draft status for a restored post. Filters may restore its previous status, including Published. Therefore look at what actually happened on your site. WordPress.com help likewise describes a return to drafts. Retain control over the decision to publish.

The expected result is a correct, reviewed record still in the chosen status. If you identify incomplete text, preserve the newly recovered version before examining its revisions. This differs from recovery after permanent deletion.

1. In the editor, display the Settings panel on the right, open its Post tab, and record the current status.
2. Check the title, body, and author.
3. Check categories, excerpt, featured image, and intended date.
4. Use preview to examine rendering.
5. Keep the post as a draft during checking, or explicitly correct its status if customization put it back online.

Understand the Trash’s limits

The Trash provides a recovery window, not a permanent backup. In WordPress, the default period is thirty days, but it can be configured differently. Manual permanent deletion may also happen sooner. Changing that duration today does not recreate a record already erased.

Automatic deletion depends on scheduled tasks running. A record may sometimes remain beyond the usual period; this offers no guarantee for the next one. Therefore inspect the actual available Trash instead of concluding solely from the calendar. Conversely, an empty Trash does not prove the content never existed.

Permanent deletion also removes associated content data, including revisions and comments according to core handling. Do not present a new post’s Revisions screen as a way to automatically recover those from an erased record. Installing a plugin after the event does not give it access to already-absent data.

1. Check the Trash before assuming the window expired.
2. Avoid Empty Trash and Delete Permanently during the search.
3. Note whether permanent deletion is known or only assumed.
4. If the record is missing, find an earlier copy: backup, export, or writing document.
5. Keep existing backups intact during examination.

Approach 2: use an old copy without replacing the current site

This approach suits a missing record when a backup containing the post still exists. It requires access to the backup and an isolated restored copy. The present site must remain the current destination with its recent orders, accounts, and publications. Restoring an old database directly over it could undo everything changed since the backup.

Choose a date after the last useful writing and before deletion. A file-only backup generally does not contain post text, which resides in the database. Media also requires corresponding files. Keep the original archive; use a copy for restoration.

The restoration procedure depends on the system that created the backup. First prepare an isolated destination with its own files and database. A different domain is insufficient if the copy retains a connection to the active database. Have access protected and emails, payments, webhooks, and external tasks blocked before its first startup. If the tool only offers replacing the current site, stop: that is not the required destination.

1. Select the dated backup that may contain the post and preserve the original archive.
2. Have the isolated environment, files, database, and protections prepared before restoration.
3. In the backup tool, explicitly verify the separate destination, then restore there.
4. Open only the copy’s administration and find the post.
5. Check that its content is usable before transferring it to a new draft.

Copy the post body into a new draft

Manual copying is suitable for a post whose content you can verify, mainly composed of blocks available on the current site. It creates a new record; it does not restore the old identifier, full history, or comments. If those complex associations must be retained, have targeted structured recovery prepared on a copy before any write to the current site.

In the old copy, open the post in the editor. The Options menu, represented by three dots at the top right, includes a tool for copying all content. The title and settings require a separate record. Then open Posts → Add New Post on the current site in a clearly identified tab.

The expected result is a new draft containing recovered blocks. Check the pasted content before saving. To undo this attempt, move only this new draft to the Trash; keep the source backup and your local copy.

1. In the isolated copy, record the title and copy all content through the Options menu command.
2. On the current site, create a new post and enter the title.
3. Paste the blocks into the empty content area.
4. Check the beginning, ending, and structure in List View.
5. Click Save Draft and record its new identifier or editing address.
6. Reopen this draft to confirm the content was saved.

Handle dependent blocks and images separately

Successful pasting may preserve references to the old installation. A synced pattern may point to a separately stored object; a third-party block may depend on a missing plugin. Do not automatically convert all content to HTML to remove a warning. Compare affected blocks on the copy and choose compatible reconstruction for those the current site no longer has.

Images need particular checking. An image visible in preview may still be served by the isolated copy’s domain. It would disappear from the new post after that copy closes. Therefore compare addresses and first look for media already present on the current site before uploading it again.

The expected result is a self-contained post whose required resources belong to the current site or an actually intended service. Do not delete old media to force use of new ones; other content may share them.

1. Open each erroneous block and identify its dependency on the copy.
2. In the draft’s Image blocks, check the file and destination.
3. Reuse current media if already present.
4. Otherwise, retrieve the authorized original file from the backup and import it into Media.
5. Replace the image in the block and check its alt text, caption, and link.
6. Also check downloadable files and embeds.

Restore settings without copying every account

The post body alone does not reconstruct its publication. In the new draft’s editor, display Settings and its Post tab, and compare them with the old copy’s record. Enter categories and tags existing on the current site. Check the excerpt and select the featured image from its media library: that image is not necessarily among the pasted blocks.

Assign the post to the correct existing account if your permissions allow it. Importing every user from an old database to recover a byline would be disproportionate. If the original account no longer exists, choose correct attribution with the editorial owner; do not create an identity or testimonial to conceal the absence.

The expected result is an identified, consistent draft. A new record retains its own change history; manual copying does not transfer the old post’s history. Plugin-specific settings, such as some editorial fields, still require separate examination.

1. Record useful settings on the old copy without changing them.
2. In the new draft, assign appropriate existing terms.
3. Check author, excerpt, and featured image.
4. Choose the intended date and verify the time zone before publishing.
5. Keep Draft status during this work and save.
6. Compare important elements with your record again.

Recover the address without changing site-wide permalinks

A recreated post receives a new identifier and may get a different slug if the desired address is already used. The slug is the readable part of the post-specific link. Compare the old address in your notes with the one shown for the new draft. Do not change Settings → Permalinks to fix one publication: that could change many content links.

If the address is based on title and date, restoring the appropriate elements may recover the expected link, but verify this after publication. An identifier-based address is not recreated by simply copying text. A collision with an existing record must be examined before changing a slug.

The expected result is a unique, stable destination. If the old address cannot be retained, plan a targeted redirect with the tool actually used on the site. A redirect must not send every missing post to this single publication.

1. Record the complete old address and the one planned for the new draft.
2. Check the slug in post settings.
3. Verify that no other content already uses the desired address.
4. Keep the general permalink structure unchanged.
5. After authorized publication, test the old and new addresses, then important internal links.

Connect the old address with Redirection if it must change

This option comes after recovery and the decision to republish. It is suitable if the new post works at another address and the old link no longer serves useful content. If the old address already works, add no rule. First use the existing redirect manager at the host or in your SEO plugin: two competing rules would complicate checking.

Without an existing tool, Redirection, by John Godley, is a free plugin suited to matching two addresses. Verified version 5.10.1 requires at least WordPress 6.7 and PHP 7.4; these minimums are not a recommendation to retain old PHP. You must be able to install plugins or ask the network administrator to intervene. On WordPress.com, check whether your plan allows this.

The rule must target the post’s exact path. Replace the examples /ancien-article/ and /article-recupere/. If the link includes a date or parameter such as ?p=123, preserve that information in the source and use exact parameter matching. Do not create a general rule redirecting every 404. Redirection must receive the request in WordPress; a response served directly by another server does not necessarily pass through the plugin.

Start with a temporary 302 redirect to validate the destination, then switch to 301 once the move is permanent. To undo it, disable only this row. A browser or cache may retain an old response: check again in a fresh session and invalidate only the affected address if your cache tool allows it. Deactivating the entire plugin could also interrupt other rules.

1. In Plugins → Add New Plugin, search for Redirection and confirm John Godley as author. Install and activate after backing up useful settings.
2. Open Tools → Redirection and finish the wizard if shown. For this one rule, automatic permalink monitoring and visit logging are unnecessary; keep those options disabled. In Options, No Logs disables redirect and 404 logs.
3. In the Redirects tab, open Add New Redirection. Enter the old path in Source URL and the published post’s address in Target URL. They must not be identical.
4. Keep Regex disabled, check matching options, and choose no global condition such as a 404 page. Through the gear icon, select Redirect to URL and code 302. Add the rule.
5. Open the old link while logged out: it should go directly to the correct post without a loop. Also check another post, which must not redirect.
6. Once the result is validated and permanent, change only this rule to 301. If incorrect, hover over its row and choose Disable, then correct source or target before another test.

If no complete copy is available

Permanent deletion without a backup or export has no magic undo button. Look for writing documents, a version sent to a colleague, or a public copy whose date you can verify. A screenshot preserves appearance but not necessarily complete text, links, or interactive elements.

An old WordPress export may contain text and associated data; it is not automatically a self-contained archive of every media file. Keep it intact. Creating a new export today does not restore an already-deleted post. Filters in Tools → Export do not guarantee selecting one post by its identifier either.

For partial recovery, create a draft and record what is missing in your tracking. Do not reconstruct comments and artificially attribute them to former readers. Missing data must remain identifiable during preparation, even if you can rewrite an editorial passage using legitimate available material.

1. Gather dated copies and organize them without changing originals.
2. Compare their beginnings, endings, and essential passages.
3. Choose a reliable basis and retain its provenance in your internal note.
4. Reconstruct a draft, then mark elements still needing verification.
5. Do not publish content as a complete recovery while important parts remain unknown.

Validate the recovered post and retain a rollback

Final checks cover both content and effects. Preview should display useful blocks, images, and downloads. The post must retain the chosen status, be correctly attributed, and appear in the right lists. Putting it online again may also trigger the site’s usual automations; check that context before clicking Publish.

After restoring from the Trash, record the retained identifier and any corrections. After reconstruction, record the old content sought and new record created. This distinction helps you locate the work precisely if a more complete version is discovered later.

Rollback must remain targeted. If the new draft is incorrect, move only it to the Trash. If a recovered publication needs temporary removal, explicitly choose its status and verify public access. Do not restore an entire old database to undo this one operation.

1. Check complete text, links, media, and featured image.
2. Confirm status, author, date, and associations.
3. Check preview on desktop and phone.
4. Once republication is decided, test the address in a logged-out session.
5. Check a recent publication remaining on the site to confirm it was not replaced.
6. Keep the backup and recovery note until the result is validated.

Find a record with WP-CLI without republishing it

With WP-CLI already available on the authorized copy, a known identifier permits a precise read even if the title changed. Replace paths, URL, and 123 with your references. The second command searches only the post Trash; replace the fictional term with a distinctive title or content fragment.

These commands restore and publish nothing. The search term does not guarantee an exact match: check each result’s ID, type, and date before returning to the native interface. For a page, use its page type in the search. A search with post_status=any must not be presented as an exhaustive Trash search; the status is therefore explicitly targeted here.

If the identifier is absent, that alone does not prove permanent deletion: first confirm the queried subsite and database. If the record is found, use its restoration procedure, then check the status actually obtained. Installing a recovery tool after deletion does not reconstruct already-absent data; an isolated backup remains the alternative when the Trash no longer contains the record.

wp --path="/chemin/copie" --url="https://copie.example.test" post get 123 --fields=ID,post_title,post_status,post_type,post_date --format=json
wp --path="/chemin/copie" --url="https://copie.example.test" post list --post_type=post --post_status=trash --s="fragment distinctif" --fields=ID,post_title,post_status,post_date --format=table