My Website Has Been Hacked: What to Do First
5 min read
Finding your site defaced, redirecting somewhere strange, or flagged by Google or your hosting provider is an unnerving moment. The worst part of a compromise is usually what panic does to it. Deleting the suspicious files, or grabbing an old backup and pasting it over the top, both destroy the trail and leave a backdoor buried somewhere, and the site gets hit again within days. What follows is a calm order of work. Follow it and most sites come back.
Step one: confirm it is actually a compromise
Rule out the boring explanations first. Plugin conflicts, settings that drifted, a stale cache: all of them can make a site look wrong without anyone having broken in. A real intrusion usually leaves clearer traces, and usually more than one of them.
Two quick checks get you most of the way. Open your own site in a private window and see whether it matches what you see while logged in. Then search Google for site: followed by your domain, and look for pages you never created. Compromised sites often serve different content to search engines than to ordinary visitors, so the logged-in view is exactly where nothing looks wrong.
Any one of these means treating it as a security incident
- Pages have been altered. Unfamiliar content on the home page or inner pages, or redirects to gambling, adult or scam sites.
- A search engine is warning about you. Google results labelled as possibly hacked, or a security issue raised in Search Console.
- Admin accounts you did not create, or files with modification times that make no sense.
- Your hosting provider has been in touch. A malware or abuse notice, sometimes alongside a sudden spike in traffic or outbound mail.
Step two: contain the damage before deleting anything
Once you know you have been broken into, the first job is limiting the damage, not cleaning up. Getting this stage right is what makes recovery possible later.
Containment is three actions. First, change every related password: the site admin, the server or VPS, the database, FTP and SSH, plus the accounts at your registrar and your hosting provider. Start cleaning before the passwords are done and you are being reinfected while you work.
Second, take the site offline or put it into maintenance mode so it stops serving malware to visitors. Third, tell your hosting provider. They may have detected it already, and they can help isolate the site or pull connection logs for you.
Step three: clean out the malware and the backdoors
With the bleeding stopped, everything that was planted has to come out. The hard part is not the visible defacement, it is the backdoors. Intruders normally leave more than one hidden way back in, so cleaning up the altered home page and nothing else buys you a few days before they return.
Cleaning is done by comparison, not by eye. Diff the site files against a known clean copy to pick out anything modified or added. For WordPress you can compare core and each plugin against the official releases, which is the most efficient single step available. Then pull a list of recently modified files and start with the ones whose timestamps do not fit.
| Where things hide | How to check |
|---|---|
| Modified core, plugin and theme files | Compare file by file against the official releases, and watch for extra files |
| PHP backdoors named to look ordinary | Check modification times, and look hard at any script inside the uploads directory |
| Malicious code injected into the database | Review post content, site options and theme settings fields |
| Scheduled tasks added quietly | List both the site and the server schedules, and remove anything you did not create |
| Extra admin accounts and keys | Audit the user list, and remove access keys and remote login keys of unknown origin |
If you are not confident you can clear all of it, do not push on. There is no partial credit here. Missing one backdoor undoes the whole effort, and doing it a second time costs more than bringing someone in at the start would have.
Step four: restore from a backup you know is clean
If you keep off-site backups and have a rough idea when the intrusion happened, the cleanest route is restoring to a version from before it, then adding back the legitimate content created since. The one you want is the backup from before the break-in, not the most recent one. Keeping several restore points is exactly what that is for.
Do two things the moment the restore finishes: update core, plugins, themes and the operating system to current versions, then change every password again. A restore brings the old version back along with the hole that let them in, so leaving it unpatched reopens the door.
Recovery without a clean backup is still possible, it is just a much bigger job. Files have to be compared one by one, backdoors removed, and altered sections rebuilt, so both the time and the bill go up. This is the value that routine off-site backups quietly provide.
Step five: find the way in, or it happens again
Plenty of people finish the cleanup, restore the site, relax, and get hit again shortly after, because the hole is still open. The most important part of wrapping up is working out how they got in and closing it.
The entry points come from a short list: a published vulnerability in an out-of-date plugin or theme, a weak password that was brute forced, leaked credentials or keys, and other sites on the same server being compromised first. The last one gets overlooked most often. On shared hosting, a neighbour's problem can become yours.
With the hole closed, put the basics in place alongside it: regular updates, two-factor authentication, least privilege, and restricted admin login. Then schedule a full vulnerability scan or security health check to confirm nothing was left behind. Judging your own cleanup in the moment is hard, and a scan afterwards is a much firmer answer.
The last part is preparing for next time. Turn on monitoring and off-site backups so that if it does happen again you notice within hours and restore quickly, rather than hearing about it when a customer calls to say the site looks odd.
Being hacked is survivable. Panicking through it is what does the real damage. Work through confirm, contain, clean, restore and diagnose in that order and most sites come back. What decides whether it stays fixed is the last part: close the hole and put the basics in place, so the same gap cannot be used twice.
Common questions
- Can I clean up a hacked website myself?
- Simple defacement, possibly. The part that decides the outcome is finding the entry point and removing every backdoor, and backdoors are often buried deep enough that missing one means being hit again. If you are not confident, leave the site as it is, hold off on deleting anything, and bring someone in. That usually costs less time and money than a second round.
- What should I do first when a website is hacked?
- Contain it. Change every password (site admin, server, database, FTP and SSH), take the site offline or into maintenance mode, and notify your hosting provider. Do not delete files and do not paste an old backup over the top, or you will destroy the evidence or restore the backdoor along with the site.
- There is no backup. Is the site still recoverable?
- Usually yes, but it takes considerably more work: comparing files one by one, removing malware and backdoors, and rebuilding whatever was altered. This is why routine off-site backups matter so much. With a clean backup, recovery is far quicker.