How to Recover a WordPress Site With No Backup

The site is gone, or as good as gone. The hosting account was canceled or suspended and wiped, a server died, a hack destroyed the database, someone ran the wrong delete command, or MySQL refuses to start with InnoDB: Database page corruption on disk or a failed file read in its log. And there is no backup: the plugin stopped running months ago, the backups lived on the same server, or nobody ever set one up.

All is rarely lost. A WordPress site leaves copies of itself in more places than people realize: at the host, in CDN and search caches, in the Internet Archive, on staging servers and on the laptops of whoever built it. If the database files still exist on disk, they can often be rescued even when MySQL will not run. This guide takes you through every source, from the most complete to the least, so you recover as much as possible before deciding what has to be rebuilt.

What is happening

A WordPress site has two halves: the files (themes, plugins, uploads) and the database (all text content, settings, users and orders). Recovery means finding the best surviving copy of each half, which may come from different places.

Source	What it can give you	How complete
Host backups and snapshots	Files and database	Complete, if they exist
Raw database files on the server	The full database	Complete, if not corrupted beyond repair
Old staging copies, developer laptops, migration archives	Files and database	Complete but older
Wayback Machine	Rendered pages, images, CSS	Public pages only, no admin data
CDN cache	Recently visited pages and assets	Partial and short-lived
Feeds, newsletters, social posts	Post text and dates	Partial
The uploads folder	Images and documents	Media only

If the site was hacked rather than destroyed, follow the first-hour hacked guide (FG-05) first, so you do not rebuild on top of an open door.

Before you start

• Freeze the scene. Every write to the disk can overwrite deleted data. Do not reinstall WordPress over the site, run cleanup tools or keep restarting a crashing database. Copy first, experiment on copies.
• Access you need: your hosting control panel, SSH if available, your CDN dashboard, and the email addresses of anyone who has ever worked on the site.
• How to run commands. Commands starting with cp, tar, wp, find or systemctl run in an SSH terminal on the server; wp commands run from the site folder, the one containing wp-config.php, and some hosts call it wp-cli. Commands starting with curl or wget run on your own computer: macOS and Linux include curl, and Windows has curl.exe in PowerShell, or use WSL. Lines under a [mysqld] heading are settings in a database config file, not commands.

If the site folder still exists, copy it off the server right away. Over SSH:

tar -czf ~/rescue-files-YYYY-MM-DD.tar.gz -C /PATH/TO/SITE .

/PATH/TO/SITE is the site folder (run pwd inside it to see the path) and YYYY-MM-DD is today’s date. -C switches into that folder before archiving, so the archive holds the site’s contents, hidden files included. No output means success; then download the file with SFTP. No space left on device means the disk is full: write the archive to another disk or stream it to your computer with ssh USER@HOST "tar -czf - -C /PATH/TO/SITE ." > rescue.tar.gz, run on your computer.

Step 1: Ask the host about backups you did not know you had

This is the most likely full recovery. Many hosts keep automatic backups whether or not you set any up. Control panels such as Enhance and cPanel often have a Backups area per website or account with daily restore points, sometimes provided by a backup add-on, and many hosts also take server-level snapshots that only their staff can reach. Even after cancellation or suspension, data is often kept for a grace period before deletion.

• Check the control panel’s backup section for every website and account you can access, including old or closed accounts.
• Open a ticket and ask directly: “Do you hold any backups or snapshots of this account or server, from any date, including disaster recovery copies?” Ask for the dates available.
• If the account was canceled, ask whether the data is still on the server pending deletion and whether it can be held while you sort out the account.
• Ask your domain registrar or email provider too, if they bundled hosting.

An old backup is still a huge head start. You can restore it and then fill the gap with the later sources below. The restore guide (FG-57) covers the restore itself.

Step 2: Look for old copies on staging servers and laptops

Most WordPress sites have been copied at some point. Ask every designer, developer and agency that touched the site to search their machines and accounts for:

• Local development copies (Local, DevKinsta, MAMP, XAMPP, Docker folders) with a database inside.
• Migration and backup archives: .wpress, Duplicator .zip or .daf files, .sql and .sql.gz dumps, often in Downloads folders.
• Staging subdomains or test servers that are still running, such as staging.example.com or a temporary domain from a previous host.
• Cloud storage folders where a backup plugin once sent archives (Google Drive, Dropbox, S3, OneDrive), even if it stopped later.
• Email attachments: backup plugins sometimes emailed small database dumps.

A staging copy that is months old still has the full theme, plugins, settings and most content. Restore it, then add newer posts from the Wayback Machine and other sources.

Step 3: Pull pages from the CDN and search engines

CDN cache

If the site sat behind a CDN, recently requested pages and images may still be in its cache for a short time. Do not purge the cache. Cloudflare only caches HTML if you set up a cache rule for it or used Automatic Platform Optimization; by default it caches static files such as images, CSS and JavaScript, which is still useful. Cloudflare’s Always Online feature serves pages from the Internet Archive when the origin is down, which ties into Step 4. Fetch pages while the cache is warm, from your computer:

wget --mirror --page-requisites --convert-links --adjust-extension --wait=1 https://example.com/

Replace example.com with your domain. --mirror follows links recursively, --page-requisites also downloads images, CSS and scripts each page needs, --convert-links rewrites links so the copy browses offline, --adjust-extension saves pages with .html endings, and --wait=1 pauses a second between requests. Good output is a growing folder named after your domain. If wget only saves an error page, the cache is empty for those URLs and the Wayback Machine is your next source.

Search engine caches

Google removed the cached page link from its results in early 2024, and the cache: search operator stopped working later that year, so Google is no longer a source of page copies. A site:example.com search is still useful as a list of the URLs that existed, with titles and snippets. Bing has at times offered a cached copy from the menu beside a result; check it, but treat it as a long shot.

Step 4: Recover pages from the Wayback Machine

The Internet Archive’s Wayback Machine at web.archive.org crawls a huge number of sites. Start by listing every URL it holds for your domain. On your computer:

curl -s "https://web.archive.org/cdx/search/cdx?url=example.com/*&fl=timestamp,original,statuscode&filter=statuscode:200&collapse=urlkey" > archived-urls.txt

Replace example.com with your domain. This is the archive’s CDX index API. url=example.com/* asks for everything under the domain, fl picks the fields to return (capture time, original URL, HTTP status), filter=statuscode:200 skips captured errors and redirects, and collapse=urlkey returns each URL once instead of every capture. Good output is one line per URL, starting with a 14 digit timestamp. An empty file means the archive has no captures of that address; try again with www.example.com/*.

The id_ trick for raw content

Normal Wayback pages wrap your content in the archive’s toolbar and rewrite every link. Adding id_ right after the timestamp returns the page as it was originally captured, with no toolbar and original links:

curl -s "https://web.archive.org/web/TIMESTAMPid_/https://example.com/PAGE_PATH/" -o page.html

TIMESTAMP is the 14 digit capture time from the list (for example the value in the first column, in YYYYMMDDHHMMSS form), and PAGE_PATH is the page’s path. You can also use a shorter timestamp such as just the year, and the archive redirects to the closest capture; add -L so curl follows that redirect. Good output is the original HTML of your page, with your theme’s markup and your own image URLs. Images work the same way: use id_ with the image URL to get the original file.

From that HTML you can copy post text, headings and image references back into WordPress. Look for the main content wrapper (often entry-content or your page builder’s container) and paste the text into the block editor; it cleans most markup on paste. For many pages, script the downloads in a loop over archived-urls.txt and add a pause between requests so you do not overload the archive.

What the Wayback Machine cannot give you: drafts, private pages, users, orders, form entries, settings and anything behind a login. Those exist only in a database copy.

Step 5: Rebuild content from feeds and the uploads folder

Feeds and newsletters

Every WordPress site publishes an RSS feed at /feed/, and copies of it live elsewhere. Feed readers and newsletter services that turned your feed into email campaigns keep the text of every item they received, often in full. Check the email archive of any newsletter account, your own inbox for notification emails, and archived feeds in the Wayback Machine (https://web.archive.org/web/TIMESTAMPid_/https://example.com/feed/). A feed in the WordPress XML format can sometimes be adapted for import, but for most sites the practical route is pasting post text in, oldest first, setting each post’s original date and slug so old URLs keep working.

Re-attach the uploads folder

If you saved wp-content/uploads but lost the database, the files are there but WordPress does not know about them. Place the folder in a fresh install, then register the originals in the media library, skipping the resized copies WordPress generates. Over SSH in the site folder:

find wp-content/uploads -type f -regextype posix-extended -iregex '.*\.(jpe?g|png|gif|webp|pdf)$' ! -regex '.*-[0-9]+x[0-9]+\.[a-zA-Z]+$' ! -name '*-scaled.*' -print0 | xargs -0 wp media import --skip-copy
wp media regenerate --yes

No placeholders. find lists images and PDFs (-iregex ignores case), and the ! -regex test drops files ending in sizes like -300x200.jpg, which are generated thumbnails. The ! -name '*-scaled.*' test drops large-image copies WordPress creates. -print0 with xargs -0 handles file names with spaces. wp media import --skip-copy creates a media library entry for each file where it already sits, instead of copying it into a new month folder, so existing image URLs in recovered content keep working. wp media regenerate --yes rebuilds the thumbnail sizes for your theme. Good output is one Imported file line per original. A file you need that was dropped by the size filter can be imported on its own with the same command.

The themes and plugins folders are also worth keeping, because premium plugins and custom theme code may not be downloadable anywhere else.

Step 6: Rescue a database that MySQL will not start

If the server still exists but MySQL or MariaDB crashes on start, the data is usually still in the data directory, normally /var/lib/mysql. This step needs root access on your own server; on shared hosting, send the host this section.

First, copy the data directory

systemctl stop mariadb
cp -a /var/lib/mysql /root/mysql-rescue-copy

Use mysql instead of mariadb as the service name on MySQL servers. cp -a keeps ownership, permissions and timestamps. Never skip this. Some of the options below can make corruption worse, and this copy is your undo button. Check the error log for the real failure first; it is usually /var/log/mysql/error.log, or journalctl -u mariadb.

Then use innodb_force_recovery, carefully

InnoDB has an emergency setting that starts the server while skipping parts of its crash recovery. It is meant for one thing only: getting the server up long enough to dump your data out. Add it under [mysqld] in the config file (often in /etc/mysql/):

[mysqld]
innodb_force_recovery = 1

Then start the service. Begin at 1 and raise it one level at a time only if the server still will not start:

Level	What it skips	Risk
1	Keeps running even if it finds a corrupt page	Low; try first
2	Stops background threads such as purge	Low
3	Does not roll back unfinished transactions	Moderate; some half-written changes remain
4	Skips the insert buffer merge and statistics	High; can permanently damage data files
5	Ignores undo logs, treats unfinished transactions as committed	High
6	Skips redo log recovery	Highest; last resort

On current MySQL versions, level 4 and above also put InnoDB into read-only mode, and MariaDB behaves similarly though details vary by version, so check its documentation for yours. As soon as the server starts at any level, dump everything and do not write to it:

mysqldump -u root -p --all-databases --skip-lock-tables > /root/rescue-all.sql

-p prompts for the root password, --all-databases exports every database, and --skip-lock-tables avoids lock requests a damaged server may refuse. If one table crashes the dump, export databases or tables one at a time (mysqldump -u root -p DB_NAME TABLE_NAME) and leave the broken one for last. Good output is a file ending in -- Dump completed on. Afterward remove the setting, move the damaged data directory aside, initialize a fresh one, and import the dump. Never run a production site with innodb_force_recovery left on.

My host disappeared or deleted my account

Sometimes the problem is not a broken server but a missing company. The hosting control panel will not load, support tickets bounce, the host’s own website is gone, or you receive a notice that your account was closed for non-payment or a terms of service breach and the data has been deleted. Work through these in order, quickly, because any data the host still holds may be on a short deletion timer.

1. Secure the domain before anything else

The domain is what lets you put the site back somewhere else. Look it up with the ICANN registration data lookup at lookup.icann.org and note the registrar and the nameservers.

• Registrar is a different company from the host: log in there, confirm you are the registrant, turn on two-factor authentication and auto-renew. You can point the domain wherever you rebuild.
• Host registered the domain for you: the registrar shown in the lookup is the accredited company behind the host. Contact that registrar, explain that your reseller has disappeared, and ask how to prove you are the registrant and get the transfer code. Have invoices, old emails and ID ready.
• The registrar itself has failed: accredited registrars must deposit registration data in escrow, and when one is de-accredited ICANN arranges for its domains to move to another registrar under its De-Accredited Registrar Transition Procedure. Watch for a notice from the new registrar.

The domain lifecycle and transfer cheat sheet explains locks, transfer codes and expiry, and domain hijacked or transferred away covers disputes.

2. Get DNS and email back under your control

If the nameservers belong to the vanished host, the domain stops resolving as soon as their DNS servers go offline, and email stops with it. Set up DNS with a provider you control (your registrar’s DNS or a DNS service), recreate the records, then change the nameservers at the registrar. Rebuild the MX, SPF, DKIM and DMARC records for wherever your email will live. Old record values may still be visible in public DNS caches or in old emails’ headers; write down whatever you can find before it expires. See email stopped after changing nameservers and website and email at different providers.

3. Rescue mailboxes from your own devices

If email was hosted with the same company, the only surviving copy of old mail may be on your phone, laptop or desktop mail app. Do not remove the account from those devices and do not let them sync against a new, empty mailbox yet. Export first: most desktop mail apps can export a mailbox or archive it to a local folder. Then set up the new mailbox and import. The guide to moving email covers importing.

4. Chase the data in writing

• Use every contact route you have: ticket, email, the address on invoices, social media accounts and the payment processor’s merchant contact details.
• Ask for three things in writing: a copy of your files and database, a hold on deletion while you arrange collection, and the date the data will be deleted.
• Read the terms of service for a data retention period after termination. If the account was closed for non-payment, paying the balance quickly is often the fastest way to get a restore.
• If the host was a reseller of a bigger company’s servers, that upstream provider may still hold the account. Their name sometimes appears in the server hostname in old email headers or in control panel login addresses.
• A card chargeback can recover money but will not recover data, and it may make the host less willing to help. Ask for the data first.

5. Rebuild from what survives

If the data does not come back, use Steps 2 to 5 above: developer copies, CDN caches, the Wayback Machine, feeds and the uploads folder. If the site sat behind a CDN such as Cloudflare, do not purge its cache or delete the zone while you rebuild. When you set up the new hosting, register the domain in your own name at a registrar separate from the host, and keep backups with a third company, so one company failing can never take everything at once. The renewals register helps you record who holds what.

Advanced: rescue database files without the original server

Sometimes all you have is a copy of /var/lib/mysql from a dead server or a disk image. You can start a disposable database server on any machine with Docker, pointed at a copy of those files. On a machine with Docker:

docker run --rm -d --name dbrescue -v /PATH/TO/COPY:/var/lib/mysql mariadb:DB_VERSION --skip-grant-tables --innodb-force-recovery=1

/PATH/TO/COPY is a copy of the data directory, never the only original. DB_VERSION must match the dead server’s version as closely as possible (use mysql:DB_VERSION for MySQL); the error log or a file named mysql_upgrade_info in the data directory often records it. --rm deletes the container when it stops, -d runs it in the background, and -v mounts your copy as its data directory. --skip-grant-tables lets you log in without the old passwords, and --innodb-force-recovery=1 applies level 1 from the table above (raise it the same careful way). Check progress with docker logs dbrescue; a line saying it is ready for connections is good. Then dump from inside it with docker exec dbrescue mysqldump --all-databases > rescue-all.sql (use mariadb-dump on newer MariaDB images).

The data directory must be complete: for InnoDB that means the database’s own folder plus the shared files beside it (ibdata1 and the redo logs, such as ib_logfile0 or the #innodb_redo folder). Individual .ibd files alone cannot simply be dropped in; they need a matching table definition and the ALTER TABLE ... IMPORT TABLESPACE process, which is a specialist job. Old MyISAM tables (.frm, .MYD, .MYI files) are far easier and can usually be copied into a database folder directly. If the disk itself is failing, stop and use a data recovery service before anything else touches it.

When to contact your host

Contact your host first, not last. Open a ticket that gives the domain, the account or website name, what happened and when in UTC, and exactly what you are asking for: any backups or snapshots from any date, a hold on deletion if the account was canceled, a copy of the database data directory, or the MySQL error log lines if the database will not start. Ask what dates they can restore and whether a restore can go to a separate location rather than over what is left. Once you are back online, set up off-server backups before anything else; the Emergency Room lists the guides for whatever surfaces next.