A hacked website triggers panic, and panic produces bad decisions — deleting things that were evidence, restoring a backup that’s also infected, or spending hours on the wrong fix while the actual backdoor stays open. Recovery goes faster and holds better when it follows a fixed order: contain, diagnose, remove, restore, rotate, patch, verify. This guide walks through each step in that order.

1. First: Confirm You’re Actually Hacked

Not every broken or strange-looking site is a security breach — some of these signs overlap with plugin conflicts, a bad update, or a caching issue. But taken together, or any one of them combined with an external warning, they’re a strong signal:

• Google Search Console shows a Security Issues warning, or Chrome/Safari shows a “Deceptive site ahead” or “This site may be hacked” warning to visitors
• Your host has suspended or flagged your account for abuse, malware, or spam origination
• Unfamiliar admin users, files, or scheduled tasks you didn’t create
• The site redirects visitors to an unrelated site, or shows different content to Google than to a browser (cloaking)
• A sudden spike in outbound email or server resource usage you can’t otherwise explain
• Unfamiliar pages appearing in Google’s index for your domain, often spam/pharma/gambling content you never published

2. Step 1: Contain the Damage

3. Step 2: Identify the Scope and Entry Point

Before cleaning anything, understand what actually happened — cleaning without knowing the entry point almost always means getting reinfected within days, since the door the attacker used is still open.

• Check server access and error logs around the time you first noticed symptoms, looking for unusual request patterns, unfamiliar IP addresses making repeated requests, or requests to files that shouldn’t exist
• Check for recently modified files — most file managers and SSH access let you sort by modification date; files changed outside your own normal update/deployment activity are a strong lead
• Review installed plugins/themes/extensions for known vulnerabilities — an outdated, vulnerable plugin is the single most common entry point on CMS-based sites
• Check for unfamiliar admin/user accounts created around the time of the breach
• Consider common entry points: an outdated CMS core, plugin, or theme; a weak or reused admin password; a vulnerable third-party script; or compromised credentials from an unrelated breach elsewhere reused on your site

4. Step 3: Remove Malware & Backdoors

• Remove any files, code injections, or database entries identified as malicious
• Specifically search for backdoors — small, often disguised scripts (frequently in uploads folders, theme files, or disguised as legitimate-looking core files) that let an attacker regain access even after the original vulnerability is patched
• Check for injected code in legitimate files, not just standalone malicious files — a common technique appends malicious code to the end of an otherwise legitimate, unmodified-looking file
• Remove any unfamiliar admin/user accounts found in Section 3
• Check scheduled tasks/cron jobs for anything unfamiliar that could re-trigger an infection
• Re-scan after cleaning, not just before, to confirm nothing was missed

5. Step 4: Restore From Backup (If You Have One)

If you have a backup from before the compromise, restoring it can be faster and more reliable than manually hunting down every piece of injected code — but only if you’re confident the backup itself predates the breach. See our backup and restore guide for how restoration actually works on most hosting platforms.

• Confirm the backup’s date is genuinely before signs of compromise appeared — restoring an already-infected backup accomplishes nothing
• Restore to a staging environment first if possible, and verify it’s clean before pushing it live
• Still complete Section 7 (patch the entry point) even after restoring — a clean restore doesn’t fix whatever let the attacker in the first time, so without patching it, you’re vulnerable to the exact same attack again

Our backup and data loss research covers how many sites actually have a usable, recent backup when they need one — a sobering number worth reading if this incident is what made you realize you don’t.

6. Step 5: Rotate Every Credential

Assume anything the attacker could have read was read, and change all of it — this step is easy to under-scope by only changing the one password you assume was involved.

• Hosting account / control panel password
• CMS admin passwords, for every admin-level account
• Database password (and update your application’s config file to match)
• FTP/SFTP credentials
• API keys and access tokens for any connected third-party service
• SSH keys, if used — generate new key pairs rather than assuming old ones are still safe
• Any password reused across other accounts or services, since credential reuse is itself a common entry vector

7. Step 6: Patch the Actual Entry Point

This is the step that actually prevents a repeat, and it depends entirely on what you found in Section 3.

• If it was an outdated plugin/theme/CMS core — update everything, and remove anything unmaintained or no longer needed rather than just patching it
• If it was a weak or reused password — enforce strong, unique passwords and enable two-factor authentication for all admin accounts going forward
• If it was a vulnerable third-party script or integration — update or remove it; if it’s abandoned/unmaintained, replace it entirely
• If the entry point genuinely can’t be identified — add a web application firewall in front of the site as a general hardening layer; see our WAF guide for how this helps even without knowing the exact original vulnerability

8. Step 7: Clear Google’s Security Warnings

If Google flagged your site (a Security Issues report in Search Console, or a browser warning to visitors), fixing the site alone doesn’t automatically remove the warning — you need to explicitly request a review once you’re confident everything is genuinely clean.

9. If Customer Data Was Involved

If the breach may have exposed customer or user personal data (not just website files), this becomes a legal and communications matter, not only a technical one.

Depending on your jurisdiction and industry, there may be additional notification obligations beyond GDPR (state-level breach notification laws in the US, sector-specific rules for healthcare or financial data). This is a genuine point to involve legal counsel rather than guessing — the technical cleanup and the legal/notification obligations are separate tracks that both need attention.

10. Preventing the Next One

• Keep CMS core, plugins, and themes updated on an ongoing basis, not just after an incident
• Use strong, unique passwords and two-factor authentication for every admin account
• Set up uptime and integrity monitoring so a future compromise is caught in minutes, not weeks — see our monitoring guide
• Maintain automated, off-server backups with a retention window long enough to have a genuinely clean restore point available
• Add a web application firewall as a standing layer of protection, not just a post-incident response
• Remove unused plugins, themes, and accounts — anything installed but not maintained is attack surface with no offsetting benefit

11. Recovery Checklist

• Site taken offline or into maintenance mode
• Hosting account password changed immediately
• Evidence (logs, infected file state) preserved before cleanup
• Entry point identified, not just symptoms cleaned
• Malware and backdoors removed, then re-scanned to confirm
• Clean backup restored, if available and verified pre-breach
• Every credential rotated — hosting, CMS, database, FTP, API keys, SSH
• The actual entry point patched, not just the visible damage
• Google Security Issues review requested, if flagged, only once genuinely clean
• Legal/notification obligations assessed if any customer data was involved
• Monitoring and backups improved to catch and recover from a future incident faster

12. Frequently Asked Questions