Work through this in order. The steps below are the same ones we'd take, and they're useful whether you fix it yourself, hand it to your host, or ask us. The most damaging mistakes all happen in the first ten minutes, so start at step one rather than the scariest-looking file.
Doing these out of order is what turns a bad afternoon into a lost week.
Put up a maintenance page, or ask your host to suspend the site. If it is serving malware or a scam page to visitors, every minute it stays up costs you reputation and search standing.
Don't wipe anything yet — taking it offline is enough for now.
Download the files and export the database before touching anything, and keep that copy untouched. It is the only record of what happened and how — and it is the difference between fixing the cause and guessing at it.
Hosting panel, FTP/SFTP, database, site admin accounts, and the email address they all recover to. Use a device you're confident is not itself compromised, and make every password unique.
Turn on two-factor authentication everywhere it is offered.
Look for admin users you didn't create, forwarding rules added to your mailbox, and changes to your DNS records or domain registrar contact details. Attackers routinely leave a second way back in.
They can see server-level logs you can't, may already have detected it, and can confirm whether other sites on the same account are affected. Most have a documented procedure for exactly this.
This is the step people skip, and it is the only one that stops a repeat. Cleaning without finding the entry point means the same compromise returns — often within days.
Every one of these is understandable in the moment. All four make the problem harder to solve.
Why rebuilding beats cleaning
Once code has run on your server, you cannot easily prove which files are still trustworthy. Rebuilding from clean sources and re-adding your content gives you certainty; picking bad files out one at a time gives you hope. When it matters, choose certainty.
Almost none of it is targeted. It's automated scanning finding something unpatched, guessable, or over-trusted.
The single most common cause. A known flaw is published, scanners sweep the whole internet for it within hours, and anything unpatched gets found.
If a password you used elsewhere appeared in someone else's breach, it is already being tried against your admin login — automatically, at scale.
A convincing email about your domain or invoice, a fake login page, and the attacker has your control panel — no software flaw required.
A contact form or file upload that doesn't check what it receives can let an attacker leave a file behind that runs on your server.
Every external script on your pages runs with your site's authority. If that provider is compromised, so is every site embedding them.
A previous developer, an ex-employee, a trial service granted access years ago. Access that outlives its reason is a standing invitation.
All of this is covered free on this site
We publish 141 tutorials on exactly these topics — no signup, no paywall. Start with web security for the attacks themselves, or cyber awareness for the phishing and password side.
Recovery ends when the site is clean. Prevention starts with reducing how much there is to attack.
Every unused plugin, theme, and account is attack surface you're maintaining for no benefit.
Not "when something breaks". Most compromises exploit a flaw whose fix was already available.
A password manager and two-factor authentication remove two of the most common causes outright.
A backup nobody has ever restored is a guess. Test one, and keep a copy somewhere the live server cannot reach.
The fewer moving parts the site has, the less there is to compromise. This is why we build the way we do.
If the site keeps getting hit
Repeated compromises usually mean the platform itself carries more risk than the site needs. Rebuilding on something with far fewer moving parts often costs less than another year of cleanups — that is what secure website migration is for.
Common signs: your browser or search engine warns visitors about the site, pages you never wrote appear in search results, the site redirects somewhere else on mobile only, admin users exist that nobody created, or your host emails you about abuse. Any one of these deserves a proper look.
Only after you know how they got in. Restoring puts back the same vulnerable version, and if the backup was taken after the compromise it may contain the attacker's files too. Find the entry point first, then restore or rebuild.
It can, especially if the site was flagged as unsafe or used to host spam pages. Cleaning it up quickly, removing the injected content, and requesting a review through Google Search Console is the recovery path. The longer it stays compromised, the longer that takes.
If personal data may have been exposed, many jurisdictions require notification within a set time, sometimes to a regulator as well as to the people affected. That is a legal question — take advice early rather than deciding on your own under pressure.
Scanners are useful for detection and for finding obvious injected code. They cannot prove a server is clean, and they don't tell you how the attacker got in. Treat a clean scan as encouraging, not as an all-clear.
We can help you contain it, work out how it happened, and rebuild the site so it doesn't recur. Get in touch with what you've seen so far and when you first noticed it — and follow the checklist above in the meantime, because those steps matter more than who does them.
Tell us what you're seeing and when you first noticed it. We'll tell you what it looks like, what to do next, and whether it's something you can handle yourself — that answer is free either way.
Free consultation • No obligation • Straight answers