What to do when your website is hacked

Finding out your site is hacked is a genuinely bad day — defaced pages, a browser warning, a spike in spam, or an email from your host. Take a breath: this is a recoverable situation with a known playbook. The order matters more than the speed. People who skip ahead to “just delete the weird files” usually meet the attacker again within the month, because deleting symptoms doesn’t close the door they came through.

1. Contain it

First, stop the bleeding without destroying the crime scene:

• Take the site offline or into maintenance mode so visitors aren’t exposed to malware or phishing content while you work.
• Don’t delete anything yet. Copy the site files and database somewhere isolated, and download every log you can reach — web server, FTP/SSH, control panel, application. Logs age out fast, and they’re how you’ll find the entry point.
• From a device you trust, change every related password: hosting control panel, SSH/SFTP, database, CMS admin accounts, and the email tied to those accounts. Enable multi-factor authentication while you’re in there.
• Tell your hosting provider. Many hosts can scan, restore, or at least confirm what their logs show — and if they suspended the account, you’ll need them anyway.

If the server is a VPS you operate, audit active sessions and authorized SSH keys too — the SSH hardening guide covers what good looks like.

2. Work out what happened and what it touched

Before rebuilding, answer three questions honestly:

How did they get in? The usual suspects, roughly in order: an outdated plugin, theme, or CMS with a known vulnerability; a stolen or weak password; or another compromised site on the same account spreading sideways. Compare file modification times against your logs to find the first malicious change.

What did they leave behind? Look for new administrator accounts, unfamiliar files (especially PHP files in upload directories), modified core files, scheduled tasks you didn’t create, and redirect rules added to server configuration. Attackers routinely install several backdoors so that cleaning one isn’t enough.

What data was exposed? If the site stores customer accounts, orders, or personal data, assume the database was readable and act accordingly — depending on where you and your customers are, notification laws may apply, and this is the point to involve a professional rather than guess.

3. Restore clean — don’t spot-clean and hope

The most reliable recovery is restoring from a backup you can prove predates the compromise, then immediately patching the entry point you identified. That’s the payoff of the backup routine: a known-good state beats forensic cleaning every time.

No clean backup? Then rebuild rather than patch: fresh CMS core files from the official source, plugins and themes reinstalled from their official versions (never copied from the infected site), and your content carried over with the database checked for injected scripts, spam links, and rogue admin users. WordPress users can verify core integrity with wp core verify-checksums and lean on the WordPress hacked-site FAQ for platform-specific steps.

However you restore, rotate every secret the old environment knew: API keys, application salts, database credentials, and any tokens in configuration files. Assume the attacker read them all.

4. Close the door and clear the warnings

Update everything to current versions, remove plugins and themes you don’t use, and re-check user accounts one last time. Then work through the security checklist properly — the goal is that the next attempt bounces off.

If Google flagged the site, open the Security Issues report in Search Console once the site is genuinely clean, review what was detected, and request a review. Requesting a review while remnants remain just slows everything down; a successful review clears the search warnings and the browser interstitials that go with them.

Keep watching for a few weeks: unfamiliar files reappearing, odd outbound traffic, new admin users, or a fresh Search Console warning all mean a backdoor survived. It happens — go back to step 2 with the new evidence.

5. Write down what you learned

While it’s fresh, record the timeline, the entry point, what data was touched, and what you changed. If the incident revealed that backups were missing or untested, fix that this week, not someday — the backup and restore guide turns this incident into the last one that hurts this much.

Sources and further reading

• web.dev: Help, I think I’ve been hacked
• Google Search Console: Security Issues report
• WordPress.org: FAQ — My site was hacked
• WordPress Advanced Administration: Hardening WordPress