How to Recover a WordPress Site With No Backup: Complete Step-by-Step Guide

27 Aug 2026 24 min read wordpress

Most articles on this topic are written by people who have never done it. You can tell, because they all end at the same place: "try the Wayback Machine!" - as if the hard part were finding out that archive.org exists, rather than the fourteen hours of copy-paste that follows.

I've rebuilt sites off the archive for clients enough times to have opinions about it. This is the actual process, including the parts that go wrong: choosing the right snapshot window when the site was hacked before it died, the slug collision that silently appends -2 to four hundred URLs, and the notification plugin that emails your entire mailing list four hundred times because you forgot to disable it before the import.

Work through it in order. Steps 1–2 are free and often end the emergency on their own.

First, know what is actually recoverable

Recovery is not one thing. Different data lived in different places, and the archive only ever saw one of them. Before you spend a week on this, be clear about what you're getting back.

| Data | Recoverable without a backup? | Where from | |---|---|---| | Posts & pages (text, headings, links) | Yes, usually | Wayback Machine, Bing/Yandex cache, archive.today | | URLs / slugs | Yes | Archived URL paths - this is the important one | | Publish dates | Yes, usually | Archived markup (<time>, meta tags, visible bylines) | | Categories & tags | Yes, usually | Archived post markup and taxonomy links | | Navigation menus | Yes | Archived <nav> markup | | Comments | Partially | Archived comment markup - varies wildly by theme | | Images | Rarely intact | Sometimes archived; often only the URLs survive | | Theme & custom CSS | No (visually reconstructable) | Archived CSS files, as reference only | | Plugin settings, widgets, options | No | Nowhere. wp_options was never public. | | User accounts & passwords | No | Never public | | WooCommerce orders & customers | No | Stripe/PayPal records, order emails | | Form submissions, CRM data | No | Email inbox, connected services | | Drafts and private posts | No | Never crawled |

If your entire business was WooCommerce order history, the archive will not save you and no article can. If your business was 600 articles of writing with eight years of backlinks, the archive can give you back almost all of the value.

Hour zero: stop the bleeding

Three things, before any recovery work. These are the ones that are irreversible if you get them wrong.

Do not let anyone reinstall on the old account. Deleted files usually survive on disk until something overwrites them. A support agent helpfully provisioning a clean WordPress install on the same account is frequently the event that actually destroys the data - not the original incident. Say this explicitly in your ticket: "Please do not re-provision, reinstall, or reformat this account. I am attempting data recovery."

Do not cancel the hosting plan. Hosts commonly retain account-level snapshots for 7–30 days after suspension, and delete them permanently on account closure. Keep it paid. Twenty dollars is cheap against eight years of writing.

Do not repoint DNS yet, if the domain still resolves. You'll want to test the restoration on the real hostname later, and if the site is partially up, every hour it stays up is another hour a crawler might capture something you're missing.

Then start a recovery log - a plain text file with timestamps. What you tried, what the host said, which snapshot dates you used. Restorations run over days, and by Thursday you will not remember whether you already checked the Dropbox account.

Step 1: Filesystem and host forensics

"No backup" nearly always means "no backup I know about." This step takes an hour and regularly ends the whole emergency.

Escalate properly with the host

The customer-facing backup panel is not the whole picture. Hosts run infrastructure-level snapshots (ZFS/LVM snapshots, DR images, nightly server-wide dumps) that support staff will not mention unless asked in language that makes clear you know they exist.

Send this:

Ticket subject: Data recovery request - do not re-provision account Please confirm, specifically: 1. Do you retain any account-level, server-level, or off-site snapshots of this account that are not exposed in my control panel - including filesystem snapshots, disaster-recovery images, or nightly server dumps? 2. What is the retention window for each, and what is the oldest restore point available? 3. Can a restore be performed to a separate directory or staging account rather than over the live document root? 4. Please flag this account as do-not-reprovision until I confirm. If a restore point exists at any date, I would like it preserved from rotation while we discuss it.

Point 3 matters: a naive restore-over-the-top can overwrite whatever partial recovery you've already assembled.

Search the filesystem yourself

If you still have SSH or FTP, look before anyone cleans up:

# Backup artefacts anywhere in the home directory
find ~ -type f \( -name "*.sql" -o -name "*.sql.gz" -o -name "*.wpress" \
  -o -name "*.tar.gz" -o -name "*.zip" \) -size +1M -printf '%TY-%Tm-%Td  %10s  %p\n' 2>/dev/null | sort

# Any surviving wp-config.php tells you a WordPress install lived there
find / -name "wp-config.php" -not -path "*/node_modules/*" 2>/dev/null

Known plugin backup locations:

wp-content/updraft/              UpdraftPlus
wp-content/ai1wm-backups/        All-in-One WP Migration (.wpress)
wp-content/backups-dup-pro/      Duplicator Pro
wp-content/backup-*/             BackWPup
wp-snapshots/                    WP Migrate / others
~/backup*  ~/public_html_old/  ~/tmp/

If the account is on a host that exposes ZFS, check for .zfs/snapshot/ in the home directory - it's often readable even when the panel shows no backups. On a VPS you control, extundelete or testdisk on an unmounted volume is a genuine option if nothing has been written since deletion. On shared hosting it isn't.

Places people forget

Remote backup destinations. The backup plugin may have been pushing to Dropbox, Google Drive, OneDrive, S3 or Backblaze under an account nobody thinks of as "the backups." Search Drive and Dropbox for .wpress, .sql, duplicator.
Staging environments. Managed hosts put staging on separate infrastructure; it frequently outlives production.
Local dev copies. Local by Flywheel, DevKinsta, MAMP, XAMPP, Laragon on any machine the developer used.
Git. Some agencies version wp-content. No database, but theme, uploads and plugin set - which is more than nothing.
Email as a content archive. This one wins more often than people expect. If the site emailed new posts to subscribers - Jetpack Subscriptions, MailPoet, a Mailchimp RSS-to-email campaign, an old FeedBurner list - the campaign archives contain the full text of every post, with the publish date attached. A Mailchimp account with 300 sent campaigns is a usable content source.
RSS readers. Feedly, Inoreader and NewsBlur retain feed items for years. If anyone subscribed, your full-text feed may still be sitting in their account.
Your own browser. Check history and any Pocket/Instapaper/Readwise account for saved copies of your own articles.

Found a database dump? Stop reading. Everything below is for people who came up empty.

Step 2: Build the URL inventory before you build anything else

The single most valuable artefact in this recovery is a deduplicated list of the URLs that existed, ranked by how much they mattered. It defines the scope, sets the priority order, and tells you when you're finished.

Sources, merged

Google Search Console → Performance → Pages, 16-month range, export CSV. This gives you URLs ranked by clicks and impressions, which is your work order. If the property is still verified, do this first.

GA4 → Reports → Pages and screens, maximum date range, export.

Ahrefs / Semrush → Site Explorer → Top Pages, and Backlinks → Broken. Backlink data tells you which dead URLs still have inbound links pointing at them. Those URLs have measurable financial value; restore them first.

Bing Webmaster Tools - separate index, separate URL list, frequently has pages GSC dropped.

The Wayback CDX index - the authoritative source of what can actually be recovered.

Querying the CDX index properly

The Internet Archive exposes a queryable index of every capture it holds. Most guides show you one query; the parameters are where the value is.

https://web.archive.org/cdx/search/cdx
  ?url=example.com
  &matchType=domain          # domain = incl. subdomains; prefix = path prefix; exact
  &from=20180101&to=20230601 # timestamp window — see snapshot selection below
  &filter=statuscode:200
  &filter=mimetype:text/html
  &collapse=urlkey           # one row per unique URL
  &fl=original,timestamp,statuscode,digest
  &output=text
  &limit=20000

From the terminal, producing a clean target list:

curl -s "https://web.archive.org/cdx/search/cdx?url=example.com&matchType=domain\
&from=20180101&to=20230601&filter=statuscode:200&filter=mimetype:text/html\
&collapse=urlkey&fl=original&output=text" \
| grep -viE '/(wp-admin|wp-login|xmlrpc|feed|page/[0-9]+|tag/|category/|author/|\?s=)' \
| grep -viE '\.(css|js|png|jpe?g|gif|svg|webp|woff2?|ico|xml|txt)$' \
| sed 's/[?#].*$//' \
| sort -u > recoverable-urls.txt

wc -l recoverable-urls.txt

That number is your real scope. Get it before you decide whether this is an afternoon or a fortnight.

To check a single URL's best snapshot near a date:

https://archive.org/wayback/available?url=example.com/my-post/&timestamp=20190701

Snapshot selection: the step everyone skips

This is the difference between a good restoration and a garbage one, and almost nobody writes about it.

The archive holds every version of your site, including the bad ones. Three failure modes:

The site was hacked before it died. Late captures contain injected spam, pharma links, or a defacement page. Pull from before the injection date, not from the most recent capture.
The domain lapsed and got parked. The most recent captures are a squatter's ad page or a spam blog. If you query without a to= bound, your "recovered content" will be someone else's casino spam.
The site was already half-broken. A failed migration that ran for two weeks before anyone noticed means the final captures are 500 errors and empty templates.

So: open the Wayback calendar view for your homepage, scrub through the years, and find the last date the site looked healthy. Then set to= to just before that. Also check whether the design changed - if you re-themed in 2021, captures either side of that date have entirely different markup, which affects how cleanly content extracts.

Pick a window where the site was healthy and the theme was consistent. Everything downstream gets easier.

If the archive shows nothing

A squatter's robots.txt on a re-registered domain, or an exclusion request, can black out playback for a domain you legitimately own. It looks like the archive has nothing. Email info@archive.org from an address on the domain, explain that you own it and are recovering your own content, and ask about the exclusion. This is a normal request and they do respond.

A note on Google's cache

Don't plan around it. Google retired the "Cached" links in search results in February 2024, and the cache: operator that kept working for a while afterwards was switched off in September 2024. Google's own suggested replacement was the Internet Archive, and Search now links to the Wayback Machine directly.

Still worth thirty seconds each: Bing's cache (dropdown next to a result), Yandex's saved copy, and archive.today (archive.ph / archive.is) - a completely separate archive with different coverage that sometimes has pages the Wayback Machine missed. If the site sat behind Cloudflare, check whether Always Online retained anything.

Step 3: Understand what you're actually extracting

Before choosing a method, understand why this is harder than it looks. Three problems make archive recovery non-trivial.

Problem 1: the archive wrapper

Fetch a snapshot normally and you get archive.org's toolbar injected into the markup, and every asset URL rewritten to web.archive.org/web/.../https://.... Import that and your content is permanently hardcoded to archive.org - a dependency that will rot.

The fix is the id_ modifier, which returns the identity payload - the original bytes as captured:

https://web.archive.org/web/20190712045500id_/https://example.com/my-old-post/

Related modifiers: if_ (iframe view), im_ (image), cs_ (CSS), js_ (JavaScript). If you're scripting anything against the archive, id_ is the one you want.

Problem 2: there is no such thing as "the content"

The archived page contains your article plus the header, nav, sidebar, related posts, share buttons, author box, newsletter form, ad slots, comment form and footer. Extracting the article means identifying the right container in markup you didn't write, on a theme you may not remember, that follows no standard.

A single CSS selector will not do it. Real extraction needs a fallback chain: known content class names first (entry-content, post-content, td-post-content, article-body…), then semantic <article>, then <main>, then a text-density heuristic that finds the DOM node carrying the highest ratio of real paragraph text to markup. Different themes fall through to different rungs.

Problem 3: slugs and the `-2` disaster

This is the one that quietly ruins restorations.

WordPress guarantees unique slugs via wp_unique_post_slug(). If you insert a post whose post_name already exists - including on a post sitting in the trash, because trashed posts still reserve their slug - WordPress silently appends a suffix. Your /how-to-brew-cold-brew/ becomes /how-to-brew-cold-brew-2/.

That's not a cosmetic issue. That's every backlink, every citation and every indexed URL failing to resolve, on a site whose entire remaining value is its backlinks. And because it happens silently at scale, you find out weeks later in Search Console.

Same class of problem with dates: set post_date via wp_insert_post() without also setting post_date_gmt and you get timezone-shifted or zeroed dates, which breaks date-based permalinks and archives.

Step 4: Choose your recovery method

Three realistic approaches. Be honest about which one fits your situation.

| | Manual copy-paste | wget / HTTrack scrape | WP Wayback Pro | |---|---|---|---| | Output | WordPress posts | Static HTML files | WordPress posts | | Original slugs preserved | Only if you're meticulous | N/A (static) | Yes, derived from archived URL | | Real publish dates | Manually, if you check each | No | Yes, parsed from markup | | All categories (not just first) | Rarely, in practice | No | Yes | | Tags kept separate from categories | Rarely | No | Yes | | Navigation menus rebuilt | By hand | No | Yes, incl. submenu hierarchy | | Comments | No | No | Best effort, flagged in DB | | Archive toolbar / URL contamination | Manual cleanup | Common | Fetched via id_, cleaned | | Duplicate/trashed-slug handling | You'll get -2 suffixes | N/A | Detected and handled | | Realistic time, ~400 posts | 40–80 hours | Hours, then a rewrite project | An afternoon |

The scrape route deserves a specific warning: wget --mirror against web.archive.org gives you a folder of static HTML with archive markup baked in and no path into WordPress. You've converted "recover my site" into "write an importer," which is the actual hard problem you were trying to avoid.

Step 5: Restoring with WP Wayback Pro

I built WP Wayback Pro because I kept doing this by hand for clients and the manual version is both expensive and worse. It handles every problem described in Step 3.

You enter your dead domain and hit Scan. It queries the CDX index, filters the noise (assets, /wp-admin/, wp-login, XML-RPC, feeds, sitemaps, robots.txt, favicons, /page/2/ pagination, author and taxonomy archives, cart/checkout, search queries), classifies what's left as posts or pages, and hands you a reviewable list.

On slugs. The slug is derived from the archived URL and the post is imported at that slug. /how-to-brew-cold-brew/ returns as /how-to-brew-cold-brew/. Dated permalinks like /2019/07/my-post/ yield my-post, with a guard so a numeric segment never becomes the slug. Crucially, trashed posts are treated as existing - the plugin restores the post from the trash first rather than letting WordPress hand you a -2 suffix and a broken URL.

On the parser. It runs the strategy chain from Step 3 - known content containers, then <article>, then <main>, then text density - and every preview tells you which strategy fired, so when something extracts badly you know why instead of guessing. Titles get the same treatment (entry-title → first <h1> → <title>), with the "| My Site Name" suffix stripped. Share buttons, related posts, author boxes, post nav, breadcrumbs, newsletter boxes, ads, sidebars, widgets and comment forms are stripped as it goes. Snapshots are fetched with id_, and archived asset URLs are rewritten back to their originals so nothing is hardcoded to archive.org.

On taxonomies. All categories, not just the first, and tags restored separately rather than collapsed into one taxonomy. If a post lived in Recipes, Breakfast and Gluten Free, it comes back in all three.

On menus. It reads the archived navigation and rebuilds it in WordPress including submenu hierarchy, matching items to your freshly imported posts by slug so they become real post links rather than dead hardcoded URLs. Genuine external links stay custom. Run it last, after content, so everything binds.

On comments. Best effort, and it says so plainly - comment markup differs enormously between themes, so some will be missed and dates can be approximate. What works comes back with authors and original dates, de-duplicated by content so re-runs don't stack copies, and flagged in the database so you can review or bulk-remove.

On not destroying your database. Dry-run mode for both content and menus. Preview and inline-edit title, slug, date, category and post type before import - fix the misclassified page before it exists, not after. Four duplicate policies: skip existing slugs (default), replace only drafts and trashed, replace everything, or import a second copy, with a confirmation prompt before overwriting published posts. Batches of up to ten with a deliberate throttle so your server doesn't choke and archive.org doesn't rate-limit you. Progress stored in the database rather than the browser tab, so closing the tab mid-import doesn't lose the job. If a snapshot returns thin or non-200, it retries the standard URL and keeps whichever response actually contains the page.

What it doesn't do: image files aren't downloaded. Image URLs are rewritten to their original locations rather than archive.org, so if the originals are gone you replace them yourself. That's the deliberate trade - pulling thousands of archived images into a media library is slow, fragile and storage-hungry; restoring your words, structure and URLs is the hard problem worth solving properly. Images are the easy problem you can solve at your own pace.

Requires WordPress 5.8+, PHP 7.4+ with the DOM extension, outbound HTTPS to archive.org. $59 one-time, one domain and all its subdomains forever, lifetime updates, portable licence - deactivate on one site, activate on the next. Which matters, because people buying this plugin are by definition people whose site has already moved somewhere unexpected once.

→ Get WP Wayback Pro - $59

Step 6: The pre-import checklist

Do these before you import a single post. Two of them are unrecoverable if you skip them.

1. Set your permalink structure to match the old site. Settings → Permalinks. If your URLs were /2019/07/post-name/ and you import into /post-name/, every faithfully recovered slug still lands at the wrong address. Get this right first.

2. Disable every notification and syndication plugin. This is the one that causes real damage. Bulk-inserting 400 posts will fire publish_post 400 times. If Jetpack Subscriptions, MailPoet, a Mailchimp RSS campaign, an IFTTT/Zapier trigger, or any auto-poster to X/Facebook/LinkedIn is active, you will spam your entire list and every social account. Deactivate them all:

wp plugin deactivate jetpack mailpoet nelio-content revive-old-post \
  wp-to-buffer social-auto-poster --skip-plugins=none

Also turn off Settings → Discussion → Attempt to notify any blogs linked to before importing.

3. Take a snapshot of the current (empty) site. Yes, really. You're about to write hundreds of rows into the database. Give yourself a rollback point.

4. Set the site timezone to match the original, before dates get parsed.

5. Bump PHP limits if you're on constrained hosting: max_execution_time, memory_limit to 256M. Or just reduce the batch size.

Step 7: Post-import QA

Never trust a bulk import you haven't audited. These checks take ten minutes and catch the failures that otherwise surface in Search Console six weeks later.

Did everything arrive?

wp post list --post_type=post --post_status=publish --format=count
wp post list --post_type=page --post_status=publish --format=count

Compare against recoverable-urls.txt.

Any slug suffixes?

wp db query "SELECT ID, post_name FROM wp_posts \
  WHERE post_status='publish' AND post_name REGEXP '-[0-9]+$' LIMIT 50;"

Note the caveat: this also matches legitimate slugs ending in a number (top-10-tools-2019). Eyeball the list rather than bulk-editing it.

Did dates collapse? The signature of a botched restoration is hundreds of posts sharing one timestamp:

wp db query "SELECT DATE(post_date) d, COUNT(*) c FROM wp_posts \
  WHERE post_type='post' AND post_status='publish' \
  GROUP BY d ORDER BY c DESC LIMIT 10;"

If the top row is today's date with a count of 380, your dates didn't parse. Stop and fix before going further.

Any empty or near-empty posts? These are parser misses:

wp db query "SELECT ID, post_name, CHAR_LENGTH(post_content) len FROM wp_posts \
  WHERE post_type='post' AND post_status='publish' \
  HAVING len < 400 ORDER BY len ASC LIMIT 30;"

Any archive.org contamination left?

wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%web.archive.org%';"

Should be zero. If it isn't, wp search-replace it - with --dry-run first.

Spot-check the live front end. Load ten of your highest-traffic URLs from the Search Console export and confirm they return 200 at the expected address.

Step 8: Rebuild what the archive couldn't give you

Images. Work down your traffic-ranked list, not alphabetically. For each broken image: check whether the original file survives anywhere; try the image URL directly on web.archive.org (image assets are frequently archived even when you assume they aren't); or decide the post reads fine without it. A lot of 2016 stock photography does not need to come back.

Internal links. If slugs restored faithfully, most internal links resolve on their own - that's a direct dividend of getting Step 3 right. Run a broken-link crawl anyway.

Theme. You aren't getting the old theme back, and you probably shouldn't want to. Pick something current and fast. Archived CSS files are readable via the cs_ modifier if you want to reference the old palette and type scale.

Redirects for the unrecoverable. For URLs with real backlinks that were never captured, 301 to the closest surviving equivalent. Do not blanket-redirect everything to the homepage - that's treated as a soft 404 and helps nothing. Pages genuinely gone with no equivalent should 404, or 410 if you want to signal permanence and get them dropped from the index faster.

If you deliberately moved off dated permalinks:

RedirectMatch 301 ^/[0-9]{4}/[0-9]{2}/(.+)$ /$1

Infrastructure. Contact forms, analytics, Search Console verification, robots.txt, an SEO plugin with a freshly generated sitemap, SSL, legal pages.

Step 9: Recovering the rankings

Content restored at original URLs is the recovery. This is how Google finds out.

Verify 200s on your top 20 URLs manually. Everything else is pointless until this is true.
Check Search Console → Security & Manual Actions. If the site died from a hack, there may be a manual action or Safe Browsing flag still attached to the domain. Clean, then request review.
Check Search Console → Removals. If anyone submitted a removal request during the incident, pages stay suppressed for roughly six months unless you cancel it. This one blindsides people.
Submit the sitemap in both Search Console and Bing Webmaster Tools.
URL Inspection → Request Indexing on your top pages, one at a time. Slow, but it's the strongest signal available.
Monitor the Pages report weekly and clear 404s as they appear.
Chase your best backlinks. For any high-value link now pointing at a URL you couldn't restore, email the linking site with the correct address.
Publish something new. A site that only ever republishes old content looks abandoned. One new post signals the opposite.

Set expectations honestly: a site offline for weeks does not bounce back in days. Restoring URLs and dates gives you the best available path back; it does not skip the crawl and reassessment cycle.

Troubleshooting: what goes wrong

| Symptom | Cause | Fix | |---|---|---| | Archive shows spam/casino content | Domain was parked after it lapsed | Set a to= bound before the lapse date | | Posts come back nearly empty | Parser fell through to a weak container | Check which strategy fired; try a snapshot from a different theme era | | Content includes header/sidebar junk | Non-standard theme markup | Try snapshots from a different design period | | All posts dated today | Dates not parsed, or post_date_gmt unset | Re-run with date parsing; fix in bulk via SQL | | URLs have -2 suffixes | Slug collision with existing/trashed posts | Empty the trash before importing; use trash-aware handling | | Import stalls at the same item | Snapshot returns non-200 or thin | Retry logic; skip and handle manually | | 429 errors from archive.org | Requesting too fast | Reduce batch size, increase throttle, wait it out | | Subscribers got 400 emails | Notification plugins left active | Nothing to do but apologise - which is why Step 6 exists | | Archive says the domain is excluded | robots.txt / exclusion on a re-registered domain | Email info@archive.org with proof of ownership |

Step 10: Make this the last time

You will never be more motivated to fix backups than you are today. Spend the motivation now.

3-2-1. Three copies, two media, one off-site. A backup on the same server as the site is not a backup - it dies with the account.
Off-site under your own control. UpdraftPlus, BlogVault, Jetpack VaultPress or your host's product, pushing to storage you own: S3, Backblaze B2, your own Drive.
Daily for active sites, 30-day retention minimum. Weekly is fine for a static brochure site.
Run a restore drill. Quarterly, restore to a staging site and confirm the homepage loads. An untested backup is a hypothesis. Most "we had backups" disasters are actually "we had corrupt backups nobody ever opened."
Don't rely on the host alone. Host backups die with the hosting account, and a compromised account can take its snapshots with it.
Uptime monitoring, so you learn from an alert rather than a customer.
Agencies: hold your own off-site copy of every client site, independent of their hosting, and put backup access in the handover checklist. The client who says "the previous developer had it" is the client you become.

FAQ

Can you really recover a WordPress site with no backup? The public content, yes - usually. Posts, pages, URLs, dates, categories, tags, menus, and often comments are recoverable from the Internet Archive because a crawler saw them. Anything that was never public is not: user accounts, orders, form submissions, plugin settings, drafts.

Will my SEO survive the recovery? It depends almost entirely on whether posts land at their original slugs. Same URL, same content, same date means existing backlinks and indexed URLs resolve again and rankings have a real path back. Restore the same words to new URLs and you're starting over with old writing.

How complete is the Wayback Machine's coverage of my site? Run the CDX query in Step 2 before spending anything. Coverage tracks how popular and crawlable the site was - low-traffic sites, pages disallowed in robots.txt, and posts published shortly before the site died are commonly missing.

What if my site was hacked before it went down? Then the most recent captures contain the injection. Use the Wayback calendar to find the last healthy date and bound your query with to= just before it. Also check Search Console for a manual action still attached to the domain.

Can I recover WooCommerce orders and customers? Not from an archive - that data was never public. Reconstruct transaction history from Stripe/PayPal records and order confirmation emails, and customer lists from your email platform.

Is it legal to rebuild my site from the Wayback Machine? Recovering content you hold the copyright to is not a legal problem. Restoring someone else's content onto a domain you acquired is a different question - that's republishing third-party copyrighted work, and you need rights to it.

How long does a full recovery take? Manually, 40–80 hours for a few hundred posts, and you'll still lose slugs, dates and taxonomies along the way. With WP Wayback Pro, scan-to-menus on a few hundred posts is an afternoon, with image cleanup trailing at your own pace.

What if I only need a handful of posts back? Then do it by hand - use the id_ modifier to fetch clean markup, and set each slug and date manually. The tooling argument only starts making sense somewhere north of twenty or thirty posts.

The short version

Don't reinstall on the old account. Don't cancel the hosting. Start a recovery log.
Hunt for an existing copy: escalate with the host in the right language, search the filesystem, then cloud storage, staging, local dev, email campaigns and RSS readers.
Build a ranked URL inventory from Search Console, analytics, backlink tools and the CDX index.
Choose your snapshot window deliberately - before the hack, before the lapse, within one theme era.
Set permalinks and disable every notification plugin before importing.
Restore at original slugs with original dates. This is the whole ballgame.
Audit the import with SQL before trusting it.
Rebuild menus, images and redirects; resubmit sitemaps; check Removals and Security in GSC.
Set up tested, off-site backups this week.

Your content already exists. The only real question is whether you spend two weeks retyping it - and still lose the slugs, dates, taxonomies, menus and comments - or get it back properly this afternoon.

The Wayback Machine kept your site. WP Wayback Pro gives it back. One domain and all its subdomains, forever, $59.

Need this done on your site?

I clean up hacked WordPress sites and harden them so it does not happen again.

Get a quote →