Almost nobody chose your website. Most compromises of small business sites begin with an automated scanner working through the internet looking for a known weakness — an outdated plugin, a reused password, an abandoned admin account — and your site simply answered the door. That is not comforting in the moment, but it does tell you what to do about it.
This guide covers how to confirm it, the order to work in, how to get a Google warning lifted, and what actually prevents a repeat.
First, confirm it is really a compromise
Not every strange symptom is an attack. Before you panic, check whether what you are seeing is one of these instead: an expired SSL certificate, a plugin conflict after an update, a hosting account suspended for non-payment, a DNS change that has not finished propagating, or a theme update that broke the layout.
Signs that it genuinely is a compromise:
- Pages you did not write, usually about pharmaceuticals, replica goods or gambling, often in a language your site does not use.
- Your site redirects somewhere else, sometimes only on mobile, or only for visitors arriving from Google.
- A browser warning, or a "This site may be hacked" label under your listing in Google results.
- Admin users in the dashboard that nobody created.
- Files changed at times when nobody was working, or new files with scrambled names.
- Your host emails you about abuse, outbound spam or excessive resource use.
- Customers tell you they got spam that appears to come from your domain.
A quick first check: open your own site in a private browser window on a phone, and search Google for site:yourdomain.com. Both will often reveal injected pages that look fine when you are logged in on your desktop.
The order to work in
Doing these in the wrong order is what turns a bad day into a bad fortnight. In particular, do not restore a backup first — if you do not know how they got in, you will restore the hole along with the site.
- Tell your host. They have seen it hundreds of times, they can see server logs you cannot, and many will scan or isolate the account for you. This is the fastest useful call you can make.
- Take the site offline or into maintenance mode if it is serving malware or spam. A site that is down for two hours is far less damaging than one quietly infecting customers.
- Make a copy of the compromised state — files and database — before you clean anything. It is your only evidence of how they got in, and you cannot get it back once it is cleaned.
- Change every password and rotate the keys. Hosting, control panel, database, FTP and SFTP, CMS admin accounts, and any API keys stored in configuration. Turn on two-factor authentication everywhere it is offered.
- Remove unknown admin users, and check for scheduled tasks and cron jobs that nobody recognises — a common way to re-infect a site that was just cleaned.
- Clean or rebuild. A known-good backup from before the compromise, with the entry point closed, is usually the fastest reliable route.
- Update everything — core platform, plugins, themes — and delete whatever is not actually used.
- Re-scan, then bring it back.
Finding how they got in
If you skip this, you will be doing all of it again next month. The usual entry points, roughly in order of frequency:
- An out-of-date plugin or theme with a publicly known vulnerability. By far the most common.
- A weak or reused admin password, or credentials leaked in a breach somewhere else entirely.
- An abandoned account belonging to a developer who left years ago.
- An old copy of the site sitting in a subfolder — the "/old" or "/backup" directory nobody updates but everybody forgets.
- Shared hosting cross-contamination, where another site on the same account was compromised first.
- A compromised computer belonging to someone with FTP access, with the credentials lifted from a saved session.
Your host's access logs around the time the first unexpected file changed will usually point at the answer. So will the modified dates on the injected files.
Getting a Google warning removed
If Google has flagged the site, visitors see an interstitial warning and your traffic stops almost entirely. The route back is Search Console — which is one of several reasons to have it set up before you ever need it.
- Open the Security Issues report in Search Console to see what Google detected and on which pages.
- Clean the site completely. A partial clean that leaves one injected file will fail review and cost you another cycle.
- Request a review, and describe what you found and fixed. A specific, honest description is reviewed faster than a blank request.
- Expect the review to take some time, and do not submit repeatedly — it does not speed anything up.
Separately, check whether the compromise injected spam pages that Google has indexed. Those need removing from the index as well as from the server, or your search results will carry them for a long time.
The mistakes that make it worse
- Restoring a backup without finding the entry point. You restore the vulnerability too, and are re-infected within days.
- Deleting everything immediately. You lose the evidence of how it happened.
- Cleaning only what you can see. Injected code is routinely spread across several files, with one dormant copy waiting to restore the rest.
- Not changing the database password because the dashboard login was changed and that felt like enough.
- Saying nothing to customers when their data may have been exposed. Depending on what was stored and where your customers live, you may have a legal obligation to notify people within a set period. Take advice rather than guessing.
What actually prevents a repeat
None of this is exotic. It is the unglamorous maintenance that gets skipped because the site looks fine:
- Update promptly. Most compromises exploit a vulnerability that was patched weeks or months earlier.
- Delete what you do not use. An inactive plugin still sits on the server and can still be exploited.
- Two-factor authentication on hosting and on every admin account.
- One account per person, with the minimum role that person needs, removed the day they stop working with you.
- Automatic off-site backups, kept for long enough to go back beyond a compromise you did not notice immediately. A backup stored only on the same server is not a backup.
- Test a restore occasionally. An untested backup is a hope.
- Search Console connected, so Google can tell you before your customers do.
Is it worth paying someone?
If the site takes payments, stores customer data, or is how you get your enquiries, then usually yes — not for the clean-up alone but for the maintenance that stops it happening. The cost of a monthly maintenance arrangement is normally a fraction of one emergency clean-up plus the lost traffic while a Google warning sits on your listing.
If it is a small brochure site you could rebuild in a weekend, a rebuild on current software, with the old installation deleted rather than left in a subfolder, is often the better value.
Keeping sites patched, backed up and monitored is part of how we look after the websites we build, and it sits alongside the SEO work for the simple reason that a flagged site loses both at once. If you are dealing with this now, contact us.
