To recover deleted WordPress posts, first check whether the post still exists in Trash, as a draft, or in saved revisions. If it was permanently deleted, an older content export, a suitable backup, or a public archive may provide material to rebuild it. A recovered draft is ready for review when its content has been checked against the source. If the article is to be republished, recovery also requires verifying that the right content appears at the intended public URL, not just that its title returns to the dashboard.
This guide separates those routes and explains the checks for one missing post. It does not assume that an archived page contains your WordPress database, original editing settings, or every historical field.
Identify what is missing before restoring anything
Write down the original post URL, its title, the approximate date it disappeared, and the last version you want to recover. Save any remaining text before making changes. A post missing from the blog listing is not necessarily deleted: search all post statuses in the dashboard and check whether it became a draft, private post, or scheduled item.
Open the original URL separately. A missing article, an access restriction, and a page showing the wrong content are different problems. If the post remains in WordPress but its public URL fails, investigate publication status and routing before creating a replacement. Avoid producing a second post with a similar slug just because the first URL is unavailable.
- Post in Trash: restore the existing item, then inspect its status and content.
- Post exists but text was overwritten: compare available revisions.
- Post permanently deleted: identify an earlier export or backup containing it.
- No usable native copy: assess an archived capture of the exact public URL.
Keep the original URL in your notes throughout. It becomes the acceptance target for the recovered article, rather than a detail to reconstruct from its title at the end.
Restore a post from WordPress Trash
In the dashboard, open Posts, select Trash, and locate the intended article. Check the title carefully if several entries are similar. Use its Restore action, then find the item again in the posts list. These actions are documented in the WordPress Posts admin guide.
Do not use Delete Permanently or Empty Trash while looking for recoverable content. Trash is temporary storage, not a dependable long-term backup. WordPress documents a default 30-day retention period; site configuration can change that behavior, so availability must be checked on the actual installation.
Restoration also does not necessarily republish the article. The WordPress untrash function assigns restored posts draft status by default, although filters can alter this. Open the recovered item and check the body, slug, date, visibility, and publication status before deciding to publish it.
Compare the restored text with any known copy. Confirm that the beginning and end of the article are present, not just the headline. If it needs review, leave it unpublished until that review is complete.
Use revisions when a post was overwritten
Revisions are relevant when the post still exists but an earlier version of its text is needed. Open the editor and look for its revisions control. Compare the available versions before restoring one, especially where later edits contain useful corrections that should not be discarded.
The official WordPress revisions documentation explains the comparison and restore controls. Their presentation varies by version: WordPress 7.0 uses a newer revisions screen, while earlier installations use the classic comparison. Follow the controls on your installation rather than expecting every screenshot or label to match.
A revision is not a complete historical copy of the site. Do not assume it restores plugin SEO fields, taxonomy assignments, or every custom field. Revision availability can also be limited by site configuration. Save the current text somewhere safe before replacing it, and compare the recovered version again after saving.
If no useful revision remains, move to other available sources. Repeatedly saving the same incomplete post will not create the missing historical version.
Evaluate existing exports and backups without overwriting the live site
Look for an export or backup made before the deletion. Record its date, the site it came from, and what it actually contains. A recent backup taken after the loss may preserve the same missing-post state.
A WordPress WXR export can contain posts and other content records. The Tools Export documentation describes its contents and selection filters. Check whether the relevant post was included rather than assuming every export contains every article.
WXR is not a full site backup. WordPress explicitly states this in its export generator. It should not be treated as proof that original files, site settings, or all plugin data can be restored. A broader site backup involves database and file coverage, as explained in the WordPress backup documentation.
Do not restore an old database over production solely to recover one post. That can replace unrelated changes made since the backup. Have the backup evaluated in an isolated environment before any production restoration is considered. Verify the relevant content there and agree on a bounded recovery method. This is a precaution, not a claim that we have demonstrated historical database extraction or a complete backup restore for this article.
Recover public text from a Wayback Machine snapshot
If native copies are unavailable, enter the original post URL into the Wayback Machine and inspect a capture from before the loss. Look for the article itself, not merely a homepage or category listing containing its title.
Check the opening paragraphs, section headings, and ending. Record the capture URL and timestamp beside the recovered text. If navigation opens another capture, verify its date too. The Internet Archive’s Wayback guidance warns that incomplete captures can lead to a different date or the live web.
Copy only content you own or have permission to use into an unpublished WordPress post. Review it as article content, not as an entire archived page: navigation, cookie notices, archive controls, and unrelated footer text do not belong in the body.
Our website restoration guide explains how to check broader archive coverage. For a single post, stop when you can distinguish verified article text from missing or uncertain sections. Do not silently fill gaps with invented historical wording.
Public text recovery does not establish the original author account, exact publication date, category assignments, SEO plugin fields, or image availability. Verify those separately from genuine records; otherwise flag them for review. Missing-media recovery is a separate task and is not demonstrated here.
Verify the Recovered Post and Its Original URL
Review the article while it is still a draft. Match its title, substantive sections, formatting, and ending against the selected source. Check links for obsolete destinations and remove archive-wrapper URLs where the intended destination is a verified live page. Do not change established URLs simply to make them resemble the new title.
Compare the full original address with the proposed permalink, including date folders, parent paths, capitalization where relevant, and the trailing-slash convention. A correct slug alone may not reproduce a dated URL. Check dates against evidence instead of guessing them to force a permalink match.
After an approved publication, open the original URL while logged out and complete these acceptance checks:
- The request reaches the intended article and returns a successful response, not a soft error page.
- The recovered body appears, including its final section, with no access restriction.
- The canonical identifies the intended final URL, and the post is not unintentionally excluded from indexing.
- Relevant internal links reach that same article without an unnecessary redirect chain.
- Any unavoidable URL change has a separately reviewed mapping to a relevant equivalent, not a blanket redirect to the homepage.
Google’s URL-change guidance supports checking mappings, redirects, canonicals, and internal links. Preserving those signals helps continuity; it does not guarantee recovered rankings or a particular indexing date.
What our controlled WordPress test showed
We tested a deliberately created sample post in an isolated WordPress Playground installation running WordPress 6.8.10, with no regular plugins enabled. Restoring the trashed sample retained its body but returned it as a draft. A saved revision also restored earlier sample text after the body was overwritten.
The computed dated permalink was not sufficient proof of recovery: its initial public request ended at a not-found page. After routing was refreshed inside that isolated test only, the URL returned the sample content successfully with a matching canonical. This is why the acceptance check must use the actual public response, not the dashboard link alone.
The pre-test WXR contained the sample body. We did not demonstrate a historical database restore, clone extraction, or a complete backup recovery. These observations are a controlled software test, not a customer case study, and they do not predict what survives on another installation.
When the missing post needs a wider rebuild
If WordPress itself is gone, recovering one article may require rebuilding the site structure first. Our Wayback-to-WordPress conversion guide explains that distinction. A visible archive is a reference source, not the original CMS backend.
For a content-led site, WordPress restoration can rebuild recoverable archived material within an agreed scope. The Simple WordPress approach retains an HTML-based presentation with limited customization; HTML/CSS knowledge is needed for changes to those pages and layouts. Visual editing and complex functionality require a different rebuild scope. Native Trash recovery should be checked before commissioning an archive rebuild for a single post.
Frequently asked questions
Can I recover a permanently deleted WordPress post?
Possibly, if an earlier export, suitable backup, or public capture contains it. Permanent deletion removes the Trash route. First verify that a usable source exists; there is no universal recovery button for content that no surviving source contains.
Does restoring from Trash make the post live again?
Not necessarily. WordPress defaults to draft status when untrashing a post, and site filters may change that. Check its actual status, review its content, and verify the live URL after any approved publication.
Can Wayback recover a post’s original WordPress settings?
An archived public page may show some historical details, but it is not the private WordPress database. Dates, authors, categories, SEO fields, and editing settings need their own evidence. Do not treat visible labels as proof that all original records survive.
Why is the recovered post still missing at its old URL?
The post may still be a draft, or its permalink structure, date-dependent path, or routing may differ. Compare the original address with the actual public response. Investigate the mismatch before changing global settings or creating another post with a duplicate slug.
