The site has been hacked, and somewhere there is a backup from before it happened. Restoring it feels like the obvious move: press a button, go back to last Tuesday, and carry on. Sometimes that really is most of the job. Quite often, though, the restored site is infected again within days, and the owner is left wondering whether the backup itself was bad.
Usually the backup was fine. What it could not do was close the door the attacker used. This post explains how to tell when a restore is enough, when it quietly brings the problem back, and how to run one so you are not repeating the same week twice.
What a backup actually contains
A WordPress backup is a snapshot of two things at one moment: the files (WordPress itself, your theme, your plugins, your uploads) and the database (posts, pages, settings, users, orders). If you want a refresher on what a complete copy should include and where to keep it, our guide on backing up a WordPress site properly covers it.
The important word is snapshot. A backup records the state of the site, including any weaknesses it had at the time. If the attacker got in through an outdated form plugin, the backup from before the hack contains that same outdated form plugin. Restoring it returns you to the exact moment just before the break-in, with the window still open.
That is the whole problem in one sentence. A restore removes what the attacker added. It does nothing about how they got in.
When a restore is genuinely enough
There are situations where restoring a backup, followed by a short list of follow-up steps, really does finish the job. They tend to share three features.
- You know when the hack started. You noticed the spam pages, the redirect or the strange admin account quickly, and you can point to a day. The backup you plan to use is clearly older than that day.
- You know, or can strongly suspect, the entry point. A plugin had a published vulnerability and you had not updated it, or an old admin password was reused elsewhere and leaked. There is a specific thing you can fix.
- Nothing important changed since the backup. A brochure site that is edited once a month loses almost nothing by going back a week. A shop taking orders every hour is a different story, which we come to below.
When all three hold, the restore plus a proper patch of the entry point is a sound approach. When even one is missing, a restore on its own becomes a gamble.
Five ways a restore brings the hole back
1. The backup already contains the infection
Many hacks sit quietly for a while before anyone notices. An attacker may plant a small backdoor file weeks before they start using it for spam or redirects. If your backups only go back seven days, every one of them may hold that dormant file. You restore, the visible spam disappears, and the backdoor is still there waiting.
This is why the date you first noticed something is not the same as the date the site was first compromised. The second date is often earlier, and only file dates, logs and a careful look at what changed can narrow it down. Hidden files of this kind are the focus of our backdoor removal service, because they are the part most cleanups miss.
2. The vulnerable plugin or theme comes back with it
If a plugin with a known security flaw let the attacker in, restoring a backup puts that same version straight back. Automated scanners look for exactly these versions across the web, so the site can be found and broken into again quickly. After any restore, every plugin, theme and WordPress core needs updating before the site is left alone, and anything abandoned by its developer needs replacing.
3. Stolen passwords still work
The backup contains your user accounts with their existing passwords. If the attacker obtained an admin password, a hosting password or database details, those credentials still work after the restore. Restoring the site does not change a single password. Every one of them has to be changed afterwards, not before, so the new ones are what end up in the restored site.
4. The infection lives outside the backup
Most plugin backups cover the WordPress folder and the database. They do not cover everything in your hosting account. If the attacker placed files in a parent folder, in another site on the same account, in a cron job set up through the hosting panel, or in an extra FTP user, restoring WordPress leaves all of that untouched. The site looks clean for a while, then something outside it writes the malware back in.
5. Only part of the backup restores
Restores fail more often than people expect, especially on shared hosting where a large import can be stopped halfway. A half-finished restore can leave a mix of clean old files and infected new ones, which is harder to clean than either. If yours stalled or left the site broken, read what to do when a WordPress restore fails before trying again.
Choosing which backup to use
If you have several backups, the newest is not automatically the right one. Work out the oldest sign of trouble you can find, then pick a copy from before it, with some margin.
Useful clues for dating a hack:
- The earliest spam URL appearing in Google Search Console’s page indexing report, or the first day traffic from odd search terms appeared.
- Modification dates on files that should not have changed, such as files inside wp-includes, though attackers sometimes fake these dates.
- When an unfamiliar admin user was registered, which appears in the users table of the database.
- Your hosting access logs, if the host keeps them long enough, showing repeated requests to a file you do not recognise.
- The date of a security notice for a plugin you were running.
The trade-off is content. An older backup is more likely to be clean but loses more recent work. Before choosing, write down what changed since that date: blog posts, new pages, form entries, orders, user sign-ups. You will need that list later.
Check the backup before you trust it
Do not restore an unknown backup straight onto the live site. Restore it somewhere else first: a staging copy, a subdomain or a local install. Our explanation of how a staging site works covers the options most hosts give you.
On that copy, look for the things the hack added on the live site. If the live site had a file called something like wp-content/uploads/2024/cache.php, check whether the backup has it too. If the live site had a rogue admin, check the backup’s user list. If there was injected JavaScript in the footer, search the backup’s database for the same domain name.
Run a malware scanner against the staging copy as well. It will not catch everything, but if it flags something in the old backup, you have learned that the backup is not as clean as you hoped, and you learned it without touching the live site.
A safer restore, step by step
- Copy the hacked site first. Download the current files and database before anything is overwritten. This copy is evidence. It shows what the attacker changed, and it holds any orders or content that arrived after your backup.
- Restore to staging and inspect it, as described above.
- Clear the hosting account, not just WordPress. Remove the old site files rather than restoring on top of them, so nothing extra survives. Check for unfamiliar cron jobs, FTP users, extra domains and files above the web root.
- Restore the clean backup to the live location.
- Update everything immediately. WordPress core, every plugin, every theme, including inactive ones. Delete plugins and themes you do not use. Our comparison of core, plugin and theme updates explains what each one touches.
- Change every credential. WordPress admins, hosting panel, FTP or SFTP, database password (and update wp-config.php to match), and the security keys and salts in wp-config.php, which logs out every existing session.
- Rebuild what was lost. Re-enter content and data from the list you wrote earlier, copying text by hand from the hacked copy rather than importing whole tables from it.
- Watch it closely for two weeks. Rescan, check for new admin users, and look at Search Console for new unknown URLs.
The special case of shops and membership sites
For a WooCommerce store or any site where customers create data, going back in time has a real cost. Orders placed after the backup, new customer accounts and changed stock levels all disappear. Payment providers will still have records of those payments, so customers can end up charged for orders the site no longer remembers.
In this situation a full restore is often the wrong tool. A better route is usually to restore clean files only (WordPress, plugins and theme from fresh downloads, your theme from a known good copy) while cleaning the current database in place, so recent orders survive. That takes more care, because the database also needs checking for injected scripts and rogue users, but it avoids losing the business that happened during the hack.
If you must restore an older database, export the recent orders from the hacked copy first, and check them against your payment provider’s dashboard before re-entering anything.
Signs the restore did not hold
Keep an eye out for these after a restore. Any one of them suggests something survived:
- The same spam pages or redirect return, even partly.
- A new administrator account appears that nobody created.
- Files reappear in uploads or in the site root after you deleted them.
- Your security plugin’s settings change, or the plugin is deactivated without anyone doing it.
- The host sends another malware notice.
Reinfection after a restore almost always points to one of the five causes above: a backdoor in the backup, an unpatched entry point, a stolen password, something outside WordPress, or a broken restore. Restoring again from the same backup will produce the same result.
What a restore cannot tell you
A restore makes the symptoms vanish, which is a relief, but it also wipes away much of what would explain the attack. That is another reason to keep the hacked copy. If customer data may have been exposed, you may need to know what the attacker reached, and that evidence lives in the hacked files and logs, not in the backup.
It also tells you nothing about whether Google has already indexed spam pages or flagged the site. Those need their own checks and, if necessary, a review request in Search Console once the site is clean. The broader recovery, from first response to clearing warnings, is laid out on our hacked website repair page.
Keep backups that make the next restore easier
A few habits make a future restore far more useful:
- Keep backups for longer than a week. A month or more of history gives you a chance of finding a copy from before a slow infection.
- Store at least one copy away from the hosting account, so a compromised or suspended account does not take your backups with it.
- Keep a note of which plugins and versions you run, so you can match a hack to a published vulnerability.
- Test a restore now and then, on staging, so the first time you do it is not during an emergency.
If you have restored once and the hack came back, or you are not sure the backup you have is clean, that is the point where a second pair of eyes helps. Our reinfected WordPress site service starts by finding what survived the last attempt, and you can message us on WhatsApp starting with the word HACKED to tell us what you are seeing.
Next in this series: Notify Customers After a Website Breach: Who to Tell
