Website Hacked? Recovery Sequence for Small Business Sites
By Aqui Tem Achadinhos Editorial · Updated September 20, 2026
A hacked website costs money in three separate ways — lost visitors, lost search rankings, and the cost of repair. The recovery order matters, because the wrong first step can destroy evidence you need.
First 15 minutes: contain, do not clean yet
Do not delete anything yet. Deleting compromised files can remove the evidence needed to find how the attacker got in — and the same hole stays open.
Change your hosting and admin passwords from a clean device. Assume every credential on the site is compromised.
Enable or verify two-factor authentication on hosting, CMS admin and domain registrar. The registrar is the one people forget — and losing the domain is the worst-case outcome.
Take a full backup of the current infected state, for forensic reference, before you change anything.
Check the domain's DNS records for anything you did not add.
How the site was probably compromised
Vector
Frequency
How to check
Outdated plugin, theme or CMS version
Very common
Version numbers vs. the vendor's latest release
Stolen admin credentials
Very common
Login logs, unfamiliar IPs or users
Nulled / pirated themes and plugins
Common
Compare files against the official release
Compromised hosting account
Less common
Neighbouring sites on the same server affected too
Cross-site scripting in a form
Less common
Injected code in user-submitted content
Step 2: check what the search engines already know
Before you fix anything, document the current state — including any warning page Google shows. That warning appears when Google detects malware or phishing, and it is your most urgent business problem because it blocks all search traffic, not just a portion.
Signal
Where to look
"This site may be hacked" warning
Google Search Console → Security Issues
Manual action
Search Console → Manual Actions
Indexed spam pages
Search site:yourdomain.com and look for unexpected URLs
Unfamiliar content in search results
Google's cached version of your pages
Step 3: clean correctly
Cleaning means more than deleting the suspicious file, because the attacker almost always leaves more than one of them:
Replace core files with fresh copies from the official source — do not just edit them.
Reinstall plugins and themes from official repositories — this eliminates hidden backdoors in modified files.
Delete unknown admin users and reset the passwords of the rest.
Check scheduled tasks and cron jobs — a favourite place to hide a re-infection trigger.
Review the database for injected content, scripts in post bodies and rogue options rows.
Also check .htaccess / server config for injected redirect rules.
⚠️ The lesson of every reinfection
If a site is reinfected within days, the cleanup missed the entry point, not the malware. Removing payloads without patching the vulnerability is the most common cause of repeat compromise — and the second infection always costs more than the first.
Step 4: request a review
Once the site is genuinely clean, submit a review request in Search Console. Be specific about what was infected, what you removed, and what you changed to prevent recurrence. Vague submissions get rejected, and each rejection costs days of lost traffic.
Step 5: prevent the next one
Automatic backups, stored off-server, with a tested restore procedure. An untested backup is not a backup.
Automatic updates for CMS and plugins — and remove plugins you do not use. Every inactive plugin is attack surface.
Two-factor authentication on every admin account and the registrar.
Least privilege — editors do not need admin rights.
Monitoring with alerting — you want to learn about a compromise in minutes, not weeks. Sites often stay infected for months because nobody was watching.
A web application firewall in front of the site, which blocks common exploit patterns before they reach your code.