Someone has told you your site is showing pages you did not write. Or you searched for your own business and found listings for products you do not sell. Or the site looks completely normal to you and customers say it sent them somewhere else. Your website has been hacked, you restored a backup, felt relieved for a day, and it came back.
The backup did not fix it because a backup restores the damage, not the door. Whoever got in almost certainly left a way back: an extra administrator account, a file that looks like part of your site, a scheduled task, a modified plugin. Restore the site and the door restores with it. So the order that works is contain, clean, verify, tell Google, and only then close the entry point, and doing those in a different order is why people spend three weeks on a job that takes two days.
Your website was hacked and the backup did not fix it. Here is why
There are three common reasons, and it is usually worth knowing which one you have before you do anything else.
- The backup contains the break-in. If the site was compromised weeks ago and you restored last night's copy, you restored the compromise. Most of these sit quietly for a while before they start publishing.
- The way in is still open. An out-of-date plugin with a known vulnerability, a weak administrator password, a stolen hosting login. Restoring files changes none of those, so within hours you are back where you started.
- They left something outside the site. A scheduled task on the server, a file in a directory your backup does not cover, a database entry rather than a file. Whole categories of persistence survive a file restore untouched.
Which is why the reinfection is not bad luck and not your fault. It is the predictable result of treating a security incident as a broken file.
The first hour: contain
- Take a copy of everything as it is now, files and database, before you change anything. It is evidence, it is how anyone works out what happened, and you may need to compare against it later. Store it somewhere separate.
- Change the passwords that matter, starting outside the site. The hosting control panel first, then the domain registrar, then the database, then every site administrator, then the email account those accounts recover to. Doing the site first and the hosting later is a common and expensive order.
- Turn on two-factor authentication where it exists, particularly on hosting and the registrar.
- Force everyone out. Most systems have a way to invalidate existing sessions or rotate the keys that keep people signed in. If you skip this, an attacker who was already logged in stays logged in, and your password change achieves nothing.
- Decide about taking the site down. If it is serving malware to visitors or handling payments, put up a holding page while you work. If it is a brochure site quietly hosting spam, leaving it up while you clean usually costs less than the downtime.
- Tell your host. They deal with this constantly, many include a malware clean-up in the plan you already pay for, and they can see things from the server side that you cannot.
The first day: clean, then verify
Cleaning means removing everything they added and replacing everything they altered. In practice, on a typical content-managed site, that is:
- Replace the core software and every plugin and theme with fresh copies from the original source rather than repairing the files in place. Anything no longer maintained or no longer used gets deleted, not disabled, because a deactivated plugin is still a file on your server that can still be reached.
- Hunt the persistence. Unknown administrator accounts, unfamiliar scheduled tasks, files whose modification date sits on the day of the break-in, code injected into the database, and anything added to the files that control redirects and server behaviour.
- Look at the uploads folder properly. It is meant to hold images and documents. Anything in there that can execute is not supposed to be there.
- Scan from two directions. A security plugin from inside gives you file-level detail, and an external scanner visiting your public pages sees what a visitor sees, including redirects that only fire for people arriving from search. Neither alone is sufficient.
- Then verify like a stranger. Visit from a phone on mobile data, from a Google result, and in a private window. If your host can show you access logs, look for the requests that arrived just before the first spam page appeared.
If your site is large, or if the same infection has already returned once, this is the point where an hour of somebody who does this professionally is cheaper than another fortnight of your evenings. It is what our security and updates work exists for. If the person who built the site has also stopped answering, our guide to recovering a website when a developer disappears covers that half of the problem.
Telling Google, and getting the spam pages out of search
This is the part most guides skip, and it is the part that decides whether your business gets its search traffic back. A cleaned site with a thousand spam pages still in Google's index is still a hacked site as far as your customers are concerned.
- Make the fake pages return a proper error. They should answer with 404, or better with 410, which tells search engines the page is deliberately gone. Redirecting them all to your homepage looks tidy and slows the clean-up down.
- Check Search Console for a security notice. If Google has flagged the site, there will be a message with example URLs, and those examples are the fastest map of the infection you will get.
- Request a review once you are genuinely clean, describing what you found and what you did. Malware warnings are often lifted within a day or two; other categories can take a couple of weeks.
- Use the removal tool for the worst offenders. It hides pages from results quickly while the permanent fix works through, which matters if the spam is embarrassing or is being seen by customers.
- Resubmit a clean sitemap, and then watch the index shrink over the following weeks rather than checking hourly.
- Keep watching for a month. Search your own site with the site: operator once a week. New spam appearing is not a new attack; it means the door is still open.
Finding how they got in
If you skip this, you will be doing all of the above again. In the overwhelming majority of small business sites, the answer is one of five things:
- An out-of-date plugin, theme or core version with a publicly known vulnerability. This is the most common answer by a wide margin, and the least interesting.
- A weak or reused password, on the site, the hosting or the email account those recover to.
- A compromised computer. If the machine you edit the site from is infected, your saved credentials went with it, and cleaning the server changes nothing.
- A shared hosting neighbour. On cheap shared plans, a compromise of another site on the same server can reach yours. If your host has a habit of this, that is a reason to move rather than to keep cleaning.
- An old account nobody removed. The developer from four years ago, the marketing agency you stopped using, the plugin you trialled once.
Making it much less likely to happen again
- Updates applied on a schedule, by someone whose job it is. Almost every one of these begins with a patch that existed and was not applied.
- Fewer plugins. Every one is a door. Delete what you do not use rather than deactivating it.
- Two-factor authentication and unique passwords on hosting, registrar, site and the recovery email.
- Backups you keep somewhere else, with a retention long enough to reach back past a slow-burning compromise, and at least one restore you have actually tested.
- Monitoring that tells you, rather than a customer telling you. Uptime checks, file-change alerts and a weekly external scan cost very little and change the story from three weeks of spam to one afternoon, which is most of what always-on monitoring is for.
Not for you if
What this costs
For a straightforward infection on a small site, a professional clean is illustratively a few hundred dollars, and your host may do it for nothing. Where it grows is reinfection, a compromised database, a large store, or search recovery after a long infection: illustratively $800 to $4,000, most of it in the careful verification rather than the deleting. Ongoing care that makes a repeat unlikely is a modest monthly figure, and it is worth comparing honestly against what a fortnight of spam in your search results costs a business like yours.
One last thing, because people are often embarrassed to be in this situation and it slows them down. Almost nobody is hacked because they were careless. They are hacked because a plugin they trusted had a hole in it and nobody was watching. What matters now is the order you work in, and you have it.