Restoring your content after a hack

Restoring a hacked WordPress is more than just putting your posts back online. When the attacker has deleted pages, hidden your content, or replaced your site with spam, you need to recover what was legitimate without reintroducing the infection. This is where most people slip up and reinfect their site within the first hour.

the rule that changes everything: clean first, restore second

If you remember one thing, make it this. Clean the site, remove the backdoor and the injected code, and only then put the content back. Not the other way around.

The temptation is strong: grab your latest backup and reinstall it over everything. The problem is that if that backup was taken after the break-in, it contains the vulnerability, the attacker’s admin account, or the backdoor. You restore, the site comes back, and a few hours later it’s infected again. You’re going in circles.

So the correct order is:

1. Confirm the break-in and clean the site (remove malicious files, fake accounts, injected code).
2. Verify the site is clean.
3. Restore only the missing legitimate content, from a trusted source.

Before any of that, take the time to confirm the site is actually hacked. Sometimes the content hasn’t disappeared, it’s just hidden or deindexed, and a restore isn’t even needed.

option 1: restore from a backup made before the infection

This is the best case. If you have a copy dated from before the hack, you get your content back intact, with its formatting, images, and metadata.

The key word here is “before.” The whole challenge is to date the infection, then pick a backup that predates it.

where to find your backups

With your host. Most hosts (Bluehost, SiteGround, Hostinger, DreamHost, and so on) keep automatic backups across several days, sometimes several weeks. Log in to your account, look for the “backups” section, and check the dates available. This is often the most reliable source because it’s out of the attacker’s reach.

Through a backup plugin. If you had UpdraftPlus, BackWPup, or something similar installed, your archives are stored somewhere (Google Drive, Dropbox, a folder on the server). Check the history. One caveat: an attacker with admin access may have deleted or corrupted the backups stored on the site itself. The ones offloaded to an external cloud are safer.

choosing the right date

First, work out when the break-in happened: the date of the first fake post, the creation date of the unknown admin account, the Google alert. Then pick a backup clearly older than that, not the one from the day before in case the infection was already brewing.

If you’re hesitating between two dates, take the older of the two. A few days of lost content beats a reinfection.

Restore that backup onto an already-cleaned site, or restore it and then clean it thoroughly. While you’re at it, reinstall the WordPress core cleanly with original files, which wipes out any modified code in the core.

option 2: no backup, finding the text elsewhere

No usable backup? The situation isn’t hopeless. Your content was published, so it was seen, indexed, and archived by others. You’ll recover it text by text. It’s slower, but it works.

the Google cache

When Google crawls a page, it keeps a copy. Type this into the search bar:

cache:your-site.com/the-post-title

or search for the exact title of the post and click the cached version if it’s offered. You get the text as it was on the crawler’s last visit. Copy it, recreate the page in WordPress.

The Google cache clears fairly fast after a site change, so act without waiting. The longer you delay, the more Google replaces its copies with the hacked versions.

the Wayback Machine (archive.org)

This is the most reliable tool for the job. The site web.archive.org stores dated copies of millions of pages. Enter your site’s address and you get a calendar: each dot is a capture.

Click a date from before the hack and you see your site as it was that day. Move from page to page, pull the text, the titles, sometimes even the images. For a site with a lot of posts, first find your old sitemap or your “all posts” page in an early capture so you have the full list to rebuild.

monitoring services

If you were using a monitoring tool like WP Umbrella or ManageWP, it has probably kept a history of backups or versions. Check your dashboard; you may find a clean copy you’d forgotten about.

what infects a restore, and how to avoid it

The classic trap is worth repeating: a backup taken after the compromise almost always contains whatever allowed the attack. An unpatched vulnerability, a file dropped by the attacker, a hidden way in. Restore that copy and you reopen the door.

Two habits to protect yourself:

• Keep several dated backups, not just the latest one. A rotation over 7, 15, or 30 days lets you pick a copy from before the incident. A single backup overwritten every night is useless the day you discover a hack that’s a week old.
• Never restore a full database without inspecting it when you suspect a compromise. Fake admin accounts, code injected into options or widgets, scripts hidden inside posts all live in the database, not just in the files.

When in doubt, copy the content (the text of posts and pages) rather than reimporting a raw database dump. It’s more tedious, but you start over on a genuinely clean foundation.

after the restore: verify and reindex

Once the content is back, the job isn’t done.

Reread your pages. Check that internal links work, that images show up, that no foreign script is hiding in content you pasted from the cache. Compare it against what you remember: a truncated post beats nothing, but you may as well complete it while you’re there.

On the Google side, your hacked pages may have been deindexed or flagged as dangerous. Once the site is clean and the content is restored:

• Request reindexing of your important pages through Search Console (inspect the URL, then “request indexing”).
• If a Safe Browsing alert was active, request a review from Search Console to get the warning lifted.
• Resubmit your sitemap (sitemap.xml) to help Google find the whole structure again.

Indexing picks back up gradually; expect a few days to a few weeks depending on the size of the site.

FAQ

Can I restore my backup straight over the hacked site? If the backup predates the infection, yes, but clean it afterward anyway to be safe. If you don’t know its date, no: you risk reinstalling the vulnerability. Clean first, restore the content after.

I lost posts and I have no backup. Is it hopeless? No. The Wayback Machine and the Google cache almost always let you recover the text of published posts. It’s manual, but recoverable.

How long does content stay in the Google cache? A few days as a rule, sometimes less after a big site change. That’s why you have to act fast: the Wayback Machine, by contrast, keeps archives far longer.

---

At WP-Detox, we start with a free scan, then the cleanup takes about 30 minutes for €149 all-in. We always back up the site before we touch anything, and recovering your legitimate content is part of the cleanup, not an add-on. If we can’t clean your site, you get refunded. For the bigger picture, see the complete guide for when WordPress is hacked.