⚡ Quick answer: The most common mistake is cleaning up the visible damage and relaxing. According to Sucuri’s report, 49.21% of compromised sites contained at least one backdoor, and 55.2% of infected databases had administrator accounts nobody had created. Remove the malicious code without finding the entry point and the site gets reinfected within days. The working order: preserve evidence, lock down access, find the entry point, clean, and only then ask Google to lift the warning.
This article is about what to do once it has already happened. Prevention and the cost of ongoing maintenance we covered in our piece on technical support; this one is the procedure for when prevention didn’t work.
Order matters here, and the first item runs against instinct.
Don’t delete anything yet. The urge is to wipe the suspicious files and breathe out. But deleted files are destroyed evidence: without them you won’t learn how they got in, and you can’t close the hole.
Take a full copy of the infected site. Files plus database, stored separately from your normal backups. This is your investigation material.
Change every password. Admin panel, hosting, FTP/SSH, database, and the email address used for password resets. If the mailbox was compromised, changing the site password achieves nothing.
Check the user list. This is the quickest win available: in 55.2% of infected databases, someone finds administrators nobody added.
Tell your host. They often already know, and they can usually tell you when and from where the login happened — they hold logs you don’t.
Not every piece of odd behaviour is an attack. But some symptoms point almost unambiguously at one.
| Symptom | What it usually means |
|---|---|
| A warning in search results or the browser | Malicious code or phishing detected |
| Pages you never created appear on your domain | SEO spam — the most common infection type |
| Visitors get redirected elsewhere | Redirect injection, often mobile-only |
| New administrators you didn’t create | A database-level backdoor |
| Hosting load jumps sharply | The site is being used for mailing or mining |
| Files modified when nobody was working | Direct interference with the filesystem |
SEO spam deserves a separate mention: Sucuri found it on 42.22% of infected sites. It’s the most insidious variety, because an owner can miss it for months — the pages are served only to search crawlers and to visitors from particular countries.
Checking is easy: search Google for site: plus your domain and look for results you never published.
This is the part skipped most often — and precisely why sites get reinfected.
The logic is simple: malicious code is the consequence, not the cause. Remove the code but leave the vulnerable plugin, weak password or open access that let them in, and you’ll be hacked again the same way.
Where the cause usually sits:
Access logs from the period before the first symptoms are the main source of the answer, and at Netloria an investigation always starts there rather than with a file scan. Look for unusual POST requests, hits on files that shouldn’t exist, and activity from IPs that look nothing like your visitors.
A backdoor is a way back in that the attacker left behind, working even after the original vulnerability is closed. The scale shows in the numbers: nearly half of compromised sites had at least one, and in a single year Sucuri’s team removed 21,062 of them.
They hide where beginners don’t look. Typical spots: files inside the uploads directory, which should never contain executable code; mu-plugins, which load automatically and don’t appear in the normal plugin list; a modified wp-config; scheduled tasks in the database that restore the malicious code after every cleanup; snippets injected into theme files.
Those scheduled tasks explain the most common client question of all: “we cleaned everything and three days later it was back.” The cleanup removed the symptom, and the scheduler quietly reinstalled it overnight. On incident work we always check the options table and the cron list — that’s where the things no file scanner and no eyeball in a file manager will catch tend to live.
A backup is the fastest route, and in most Netloria recovery jobs it’s where we start — but it comes with two traps.
First: the copy may already be infected. If the compromise happened three weeks ago and you roll back one week, you restore the site along with the backdoor. So establish the infection date first — from logs and file modification times — and only then pick a copy.
Second: a rollback also restores the vulnerability they came through. After restoring, update everything: core, plugins, themes, passwords.
If no clean copy exists, the longer road remains: reinstall the CMS core from the official source, reinstall every plugin and theme from scratch (not update — install clean versions), and clean the database by hand. Your own files — uploads, custom code — get moved back selectively, with inspection.
This is the part people most want to skip, because it’s unpleasant and has no technical fix.
If the site took orders or stored phone numbers, delivery addresses or purchase history, you need an honest assessment of whether that data could have been taken. Indicators: database access from an unfamiliar IP, large outbound traffic in the logs at odd hours, archives sitting in a publicly reachable directory, or a discovered script that dumps the users table.
Then the awkward part begins: if a breach is confirmed, the people whose data was affected have to be told. European law gives 72 hours from discovery to notify the regulator, and many local data-protection regimes set no explicit deadline at all — but the duty to protect the data doesn’t disappear either, and any business serving EU customers should work to the stricter standard regardless of where it is registered. Practically, something else matters more: customers forgive a hack far more readily than they forgive silence about it, and a company that writes “we had an incident, here’s what we did” loses considerably less reputationally than one whose breach its customers discover from spam arriving at an address only that site ever had.
Separately, invalidate all user sessions and force a password reset if the site had customer accounts. Even when the database probably didn’t leak — proving it rarely works out.
Once the site is clean, the mark in search and browsers still has to be removed — it won’t clear by itself.
The procedure: open the Security Issues report in Search Console, confirm the problem is no longer detected, and request a review. The request should describe what you actually did to fix it — boilerplate slows the process down.
Two details trip people up most often.
The site has to be crawlable. Google states plainly that the pages must not be blocked in robots or carry noindex — otherwise verifying the cleanup is impossible. The classic error is leaving the site in maintenance mode and submitting a request that is guaranteed to fail.
Timing. The official documentation says a review takes from a few days, and the Search Console help notes it can stretch to a few weeks. Figures like “cleared in 24 hours”, which circulate in articles, have no traceable source.
It’s also worth purging your site cache and CDN before submitting: if Google sees a cached infected version, the review fails.
Getting the site back online isn’t the finish. Without this part, the story repeats.
Check rankings and traffic separately. After SEO spam and a Google warning, organic performance usually dips and takes weeks to recover. How to track that properly is covered in our article on website metrics.
A few moves that feel logical and make things worse.
noindex hurts rankings more than the infection did.At Netloria the cases we see most often involve the first and third items: the site arrives after a DIY cleanup attempt, with two weeks of maintenance mode behind it and an untouched database. Untangling it afterwards is harder, because part of the trail has been wiped.
Doing it yourself is realistic if the site is simple, you have a clean backup, and the infection is recent and obvious.
Call in help when: the site is reinfected after cleaning; you can’t locate the entry point; the compromised site is a store holding customer and payment data; the infection ran for a long time and it’s unclear what was taken; or the site is your main sales channel and every hour of downtime costs money.
That last point matters most commercially. Spending two days on DIY attempts and then calling someone anyway works out more expensive than calling at the start, because the downtime is added to the cleanup cost.
Rough market figures: professional cleanup typically lands in the low hundreds of dollars for a straightforward case and rises past $1,500 when the infection runs deep or the site is large. On a typical project the work takes one to two days, assuming access and logs exist.
The main cost multiplier isn’t site size — it’s whether logs and backups survived. Without logs the investigation turns into a search, and the search is what consumes the hours.
It looks like this in practice. When logs exist, the work begins with a narrow question: what happened on the site in the day before the first suspicious file appeared — and the answer usually surfaces within an hour or two, because you can see a specific request, a specific file and a specific IP. With no logs you come at it from the other end: comparing every file against clean versions from official repositories, going through database tables by hand, hunting anomalies in timestamps — and that path takes several times longer for a worse result, because some of the implants simply go unnoticed. Which makes the single most useful thing you can do in advance not backups, but access logs enabled with a sensible retention period.
Compare that against the cost of ongoing maintenance and it becomes clear why prevention is almost always cheaper. That’s an argument for next time, though; when the site is already down, restoring it correctly matters more than regretting the monitoring you never set up.
If your site is in this situation right now, or you’d like someone to check it before it gets there — tell us what’s happening. We’re a web studio based in Ukraine, and we start by finding the entry point rather than by cleaning what’s visible: without that, any recovery is temporary.
