WordPress Site Hacked and Files Deleted? Here’s How to Recover Without a Backup (Real Recovery Walkthrough)

If you’ve discovered that a hacker has deleted everything on your WordPress site — themes, plugins, the entire uploads folder, your post images — and you don’t have a working backup, your site is not necessarily gone. As long as your WordPress database survived (and in most attacks like this, it does), the site is recoverable. The database still contains your posts, pages, settings, and references to which themes and plugins were active. The recovery process is to install fresh WordPress on a clean environment, import the surviving database, rebuild the theme/plugin setup using the references stored in wp_options, and recover missing images from external sources like the Wayback Machine. It’s labor-intensive, you’ll likely lose 50–60% of your media, but the site itself can be saved.

The email is always urgent. “I logged into my WordPress site and everything is gone. The themes are deleted. The plugins are deleted. The uploads folder is empty. There’s no backup. Is the site recoverable?”

If you’ve just discovered something like this, take one breath. The answer is almost always yes — but only if you understand what’s actually been destroyed and what hasn’t.

This post walks through how to recover a WordPress site after a hacker has deleted your files, including the real recovery I performed for a client whose Bluehost VPS had been wiped down to nothing but a database. By the end, you’ll know exactly what’s salvageable, what isn’t, and how to approach the rebuild so you don’t lose anything that didn’t have to be lost.

What’s Probably Still There (Even If You Can’t See It)

The first thing to understand is that WordPress stores your site’s data in two completely separate places:

1. Files live on your server’s filesystem — the WordPress core, your theme folder, plugin folders, and the wp-content/uploads/ directory where your media is stored
2. The database is a separate service running alongside the files (usually MySQL or MariaDB). It holds your posts, pages, comments, users, settings, and metadata about every uploaded file

When an attacker “deletes everything,” they almost always mean the files. Wiping the database requires separate access and is a different attack altogether. In most destructive WordPress hacks I see, the database survives intact — the attacker either didn’t have database credentials, didn’t think to wipe it, or wanted to leave content visible to mock the owner.

This is your lifeline.

How to check if your database survived

Before you panic about what’s gone, confirm what’s still there. Log into your hosting control panel (Bluehost, SiteGround, cPanel, Plesk, or whatever you use) and find phpMyAdmin or your provider’s database manager. Open your WordPress database and look for these tables:

• wp_posts — should contain rows with your post and page content
• wp_options — should contain hundreds of rows including siteurl, blogname, active_plugins, and template
• wp_users — should contain your user accounts
• wp_postmeta — should contain metadata including image attachment paths

If those tables exist and have data in them, your site is fully recoverable from a content perspective. The rebuild work is real, but the content is safe.

If the database is also empty or missing, the recovery becomes much harder and depends entirely on external archives. That scenario is rare in destructive hacks but does happen — usually when an attacker has full server access through a compromised hosting account.

What the Database Actually Tells You

A surviving WordPress database is more useful than most site owners realize. Even with every file deleted, you can extract enough information to rebuild the site’s exact configuration. Here’s what’s in there:

1. All your post and page content

Every blog post, every page, every comment, every revision — all stored in wp_posts. Text, HTML markup, embedded shortcodes, the whole thing. None of that is in files. It’s all in the database.

2. The exact themes and plugins that were active

In wp_options, look for the rows where option_name equals:

• template — the name of your active theme’s folder
• stylesheet — the name of your active child theme (if any)
• active_plugins — a serialized list of every active plugin and its main PHP file path

That’s the blueprint. Even though the actual theme and plugin files are gone, you know exactly what to reinstall. Match the names to plugins/themes available on WordPress.org, GitHub, or wherever you originally got them, and download fresh copies.

3. All your settings

Site title, tagline, permalink structure, timezone, default category, comment settings, theme customizations, widgets, menus — every WordPress setting lives in wp_options. When you import the database into a fresh install, all of that comes back automatically.

4. Image references (but not the images themselves)

Every uploaded image has an attachment row in wp_posts (with post_type = attachment) and metadata in wp_postmeta showing the original file path. The images themselves are gone, but you have the complete list of what existed and where it was supposed to be — which is critical for the recovery step we’ll get to.

5. User accounts

Every admin, editor, author, contributor, and subscriber account survives in wp_users. Their passwords are hashed (so you can’t read them, but you can reset them). Your customer accounts, if you had a membership site or e-commerce, are also intact.

The Recovery Process: Step by Step

Here’s the order I follow when rebuilding a destroyed WordPress site from a surviving database. Don’t skip steps — the order matters because doing things out of sequence can cause data loss.

Step 1: Don’t touch the compromised server yet

Before you start the rebuild, take a complete database export from the compromised server. Do not modify the database in place, do not delete files, do not run any cleanup scripts. The first move is always to make a forensic snapshot of whatever survived.

In phpMyAdmin: select your WordPress database → click “Export” → choose “Quick” and “SQL” format → save the resulting .sql file to your local machine. Make a backup of that file. Now you have an offline copy of everything that survived.

Step 2: Set up a fresh, clean environment

Don’t rebuild on the same server the attacker had access to. Even if you can’t migrate hosting providers immediately, at minimum:

• Create a new database (with new credentials)
• Wipe the WordPress installation directory and start with a fresh download from WordPress.org
• Update PHP to a currently supported version (8.1+ at minimum in 2026)
• Generate fresh WordPress security keys for the new wp-config.php
• Use new admin credentials (do not reuse the old ones — they should be considered compromised)

If your old hosting environment was outdated (running PHP 7.x or older WordPress versions), this is the moment to fix that. Outdated environments are usually how attackers got in to begin with.

Step 3: Import the surviving database into the new install

Once your fresh WordPress install is running and you can log into wp-admin with a new admin account, it’s time to bring back the content.

In phpMyAdmin on the new server: select the new WordPress database → click “Import” → upload your saved .sql file. This will overwrite the fresh-install tables with the recovered ones from the old site.

Important: The site URL stored in the database may not match your new environment. After import, log into phpMyAdmin and check the wp_options table — find the siteurl and home rows and make sure they match the URL where the new WordPress install is actually accessible.

When you reload your site after this step, you should see your content back, even though the visual appearance will be broken because themes and plugins haven’t been reinstalled yet.

Step 4: Rebuild the active theme

Look up the theme name from the template entry in wp_options. Download a fresh copy from:

• WordPress.org (for free themes from the official directory)
• The original developer’s website (for premium themes — you may need to log into your account there)
• The marketplace where you originally bought it (ThemeForest, etc.)

Upload the theme folder to wp-content/themes/ on the new server. Activate it from Appearance → Themes.

If you had a child theme, you’ll need to recreate it manually (the parent theme name is in template; the child theme name is in stylesheet). Most child themes are minimal — typically just a style.css with the parent theme reference and possibly a functions.php. If you can’t recover the child theme, you can rebuild a basic one and accept that custom modifications are lost.

Step 5: Rebuild the plugins

Open the active_plugins entry in wp_options. The value is a serialized PHP array that looks something like:

a:5:{i:0;s:31:"akismet/akismet.php";i:1;s:33:"contact-form-7/wp-contact-form-7.php";i:2;s:19:"jetpack/jetpack.php";...}

Each entry is a path like plugin-folder/main-file.php. The folder name is the plugin slug — that’s what you need to identify which plugin to reinstall.

For each plugin in the list:

1. Search WordPress.org plugin directory for the slug
2. If found, install it through Plugins → Add New
3. If not found (premium plugin), download from the original source
4. Activate the plugin and check that its settings still work — most plugin settings are stored in the database too, so they should come back automatically

Step 6: Recover the missing images

This is the hardest and most time-consuming part. The uploads/ folder is gone and there’s no backup, but the database still references every image that ever existed.

The recovery sources, ranked by typical success rate:

• Wayback Machine (web.archive.org) — if your site was archived in the past, the Wayback Machine has cached copies of pages including their images. Browse to your archived URLs and download the images directly
• Google Image Search — search for your domain name with site:yourdomain.com in image search; sometimes Google’s cached image versions are still accessible
• CDN cached copies — if you used Cloudflare, KeyCDN, or another CDN, some images may still be cached at edge locations
• Your own backups elsewhere — Dropbox, Google Drive, your local computer, your email attachments, original camera photos
• Visitor browser caches — long shot, but if a regular visitor recently loaded a page, they may have it cached
• Stock photo originals — if you bought images from stock sites, your purchase history can re-download them

For each recovered image, place it in the matching path inside wp-content/uploads/ based on the original path stored in the database. The directory structure is usually uploads/YYYY/MM/filename.jpg — get the year/month right and the image will reconnect to its post.

In the real client cleanup that inspired this post, I was able to recover roughly 40–50% of images this way. That’s a realistic expectation for a destroyed-uploads scenario. The remaining images were replaced with placeholders or, where possible, sourced from public archives the client had access to.

Step 7: Reset all credentials

The attacker had server access. Treat every password as compromised:

• WordPress admin (force password reset for every user)
• Hosting cPanel
• FTP/SFTP credentials
• Database user password
• Any email accounts that received password resets during the compromise window

Generate fresh WordPress security keys for the new wp-config.php if you haven’t already.

Step 8: Harden the new environment

The whole reason the original site was destroyed is that something let an attacker in. Don’t recreate the same vulnerability:

• Update WordPress core to the latest version
• Update every theme and plugin to the latest version (if any won’t update or are abandoned, replace them)
• Enable two-factor authentication on WordPress admin and hosting cPanel
• Install a Web Application Firewall (Wordfence, Sucuri, Cloudflare WAF, or your host’s built-in)
• Set up real backups this time — automated, off-site, and tested. How to back up your WordPress site with UpdraftPlus walks through this
• Remove any plugins or themes you don’t actively use
• Throw away any nulled or pirated software — it’s likely how you got hacked in the first place (why nulled plugins and themes are a security disaster)

For a complete post-recovery checklist, see what to do after fixing a hacked WordPress site.

Why Hackers Delete Everything

The motivation behind a destructive wipe usually falls into one of three categories:

• Punishment. Sometimes the attacker has been on the site for weeks running a redirect or SEO spam campaign, gets discovered, and wipes the site as retaliation when they realize they’re losing access
• Cover-up. Destroying files removes the forensic evidence of how the attacker got in, what they ran, and who they’re working with. A wiped site is harder to investigate
• Ransom setup. Some attackers wipe the site and then demand payment to “restore” it. They typically don’t have a real backup to restore — they’re hoping you’ll pay before realizing that

If you receive a ransom demand alongside a wiped site, do not pay. Even if the attacker still has a copy of your data, paying doesn’t reliably get it back, and it confirms you as a profitable target for the next wave of attacks. Recover from the database (which they usually can’t take from you) and harden everything afterward.

What This Recovery Actually Looks Like

To make this concrete: the cleanup that inspired this post was a small business blog hosted on an old Bluehost VPS, running an outdated WordPress 4.x installation. By the time I got access:

• The active theme had been deleted
• All plugins had been deleted
• The entire uploads/ folder was gone, including every post image accumulated over years
• There were no usable backups — the most recent one had been deleted alongside the rest
• The WordPress database was intact

The recovery took about two days of careful work. The breakdown:

1. Day 1 morning: Database export, fresh WordPress install on an updated environment, database import. Site became technically functional within a few hours, but visually broken with no images.
2. Day 1 afternoon: Identified the active theme and plugin list from wp_options. Reinstalled everything from clean sources. Site began rendering correctly.
3. Day 2 morning: Image recovery via the Wayback Machine. Pulled archived versions of the most recent and most-trafficked posts first, then worked backward through history.
4. Day 2 afternoon: Hardening, credential rotation, set up automated off-site backups, monitoring.

Final result: 100% of posts and pages recovered, themes and plugins reinstalled to match the original setup, roughly 40–50% of images recovered from archives, the rest either replaced with placeholders or sourced from elsewhere. The client kept years of written content that would have been gone if the database had been wiped too.

What This Teaches You About Backups

The single biggest lesson from cleanups like this: everything I just walked through is what happens when you don’t have a backup. With a working off-site backup, none of this is necessary. You’d restore the site in 30 minutes, recover 100% of images, and be back to normal.

If you’re reading this because it just happened to you, the cleanup ahead is real. If you’re reading this because you’re worried it might happen and want to understand the risk, the answer is simple: get backups working today, not next week.

A working backup setup means:

• Automatic daily backups of both files and database
• Stored off-site (Google Drive, Dropbox, S3, or a dedicated backup service — not on the same server as the site)
• At least 30 days of retention so you can restore from before an infection
• Tested at least once — restore to a staging site to confirm the backup actually works

Backups stored on the same server as the site can be (and often are) deleted along with everything else during a destructive hack. That’s the point of off-site storage.

FAQ

Can I recover my WordPress site if I have absolutely no backup?

If your database survived, yes — usually with full content recovery and partial image recovery (typically 40–50% via the Wayback Machine and other archives). If the database was also wiped, recovery is much harder and depends entirely on external sources like cached search results and archive snapshots, with very limited success rates.

How do I know if my database is still intact after a hack?

Log into your hosting control panel and open phpMyAdmin (or your host’s database manager). Find your WordPress database and look at the wp_posts and wp_options tables. If they have rows with content in them, your database is intact. If they’re empty or missing, the attacker wiped it too.

The hacker is asking for ransom to restore my site. Should I pay?

No. Even if they have a copy of your data (which they usually don’t actually have), paying ransoms rarely results in restoration and marks you as a paying target for repeat attacks. Recover from your surviving database instead. The Wayback Machine and other archives can recover much of what looks lost.

How long does this kind of recovery take?

For a small to medium WordPress site (up to a few hundred posts), the technical recovery is usually 1–2 days of focused work. Larger sites or sites with extensive image libraries take longer because the image recovery scales with content volume. Sites running e-commerce or membership systems can take longer still due to the additional plugin reconfiguration.

Will my SEO recover after this kind of incident?

Mostly yes, if you’re quick. As long as URLs stay the same and the content returns, search rankings typically recover within a few weeks. The bigger SEO risk is downtime — every day the site is broken or showing errors, search engines lose confidence in the URL. Get the site back to working order as fast as possible, even if image recovery takes longer.

Is reinstalling WordPress enough after this kind of attack?

No. A fresh install only rebuilds the platform. You still need to import the surviving database, rebuild themes and plugins, recover what you can of the missing media, and harden the new environment so the same attack doesn’t happen again. The hardening step is non-negotiable — without it, you’re rebuilding a site for the same attacker to wipe a second time.

What if my hosting provider says they can’t recover anything?

Hosting providers usually mean “we don’t have a backup we can give you” — which is different from “your site is unrecoverable.” If the database files are still on the server (and they almost always are), you can extract them yourself via phpMyAdmin or by asking your hosting support to provide a database export. That export is usually all you need to start the recovery.

Need Help Recovering a Wiped WordPress Site?

Recovering a destroyed WordPress site from nothing but a database is one of the most demanding cleanup scenarios in WordPress security work. It requires database forensics, manual theme and plugin reconstruction, and patient image recovery from external sources — and most importantly, knowing what’s possible vs. genuinely lost so you don’t waste time on unrecoverable assets.

I’ve handled more than 4,500 WordPress malware and recovery cases since 2018, including no-backup disasters where every visible file had been deleted. If your WordPress site has been wiped and you’re not sure where to start, I can assess what’s still recoverable from your environment and rebuild the site properly.

Get Expert WordPress Recovery Help — or contact me directly via the hire me page.

Related Reading

• WordPress Malware Removal Service
• How to back up your WordPress site with UpdraftPlus (so this never happens to you)
• What to do after fixing a hacked WordPress site
• How hackers hide backdoors in WordPress
• Why nulled plugins and themes are a security disaster
• How to detect WordPress malware
• Why WordPress malware keeps coming back