Usually yes, because this is the kind of work where the first day matters. What we need before touching anything is a short written authorisation naming the site, the hosting account and the dates — email confirmation is enough to begin — plus access created as a separate account in our name rather than your own login shared over WhatsApp. That takes minutes and it means the server logs can later show exactly which actions were ours.

Should we delete the suspicious files ourselves while we wait?

Please do not. Deleting the visible files destroys the timestamps and log entries that show how the attacker got in, and without that the site is very likely to be compromised again within days. Put the site into maintenance mode if you can, change the passwords from a different device, and leave the files where they are. Everything is backed up before anything is removed.

How long until the Google warning disappears?

The review request goes in the same day the site is genuinely clean, and how quickly the warning lifts after that is Google's timing, not something anyone here can promise. The important word is genuinely — a review request submitted on a site that is still infected fails, and repeated failed requests make the next one slower. We do not submit until the checksums verify and the entry point is closed.

Will you find how they got in?

In most cases yes, from log entries and file modification times around the point where behaviour changed — usually an outdated plugin with a publicly disclosed flaw. Sometimes the hosting provider only retains logs for a short window and the honest answer is that the entry point could not be conclusively identified. When that happens we say so in writing and explain what it means, rather than inventing a cause.

Can you guarantee it will not happen again?

No, and nobody can. What we can say is which route in has been closed, what has changed, and what remains your responsibility — chiefly keeping software updated and keeping multi-factor authentication switched on. A site is never finished being secure, and any supplier who tells you otherwise is selling something.

What happens after the cleanup?

Two weeks of rechecking is included, because reinfection from something missed almost always shows up inside that window. Beyond that, ongoing monthly monitoring is available and worth it for anything taking orders or holding customer data — updates applied, malware scanning, and backups verified by actually restoring one rather than trusting the green tick.

Cybersecurity

Malware removal and site cleanup

A compromised site cleaned properly — evidence preserved first, the way in found and closed, the Google warning lifted, and two weeks of watching afterwards.

From: $200–$2,500
Typical time: 1–5 days
Usually bought by: Hacked site owners

What this actually solves

This is not a considered purchase. The phone rings because Chrome is showing a red interstitial to every visitor, because Google has pulled the site out of search results, because the hosting company has suspended the account, or because customers are receiving spam that appears to come from the business. Trading has stopped. Somebody needs it not to have stopped.

The damage is rarely the defaced page itself. It is the fortnight of lost enquiries, the search visibility that took years to build and evaporates in days, and the customers who saw a browser warning next to a company name they were about to trust with a card number. For a shop in season, that compounds hourly.

The second problem, and the one that actually determines whether this work was worth buying, is that a site can be cleaned and still not be fixed. Someone reinstalls the theme, the site comes back, and three days later the red screen returns — because only the visible damage was removed and the door was left open, often with a small file left behind specifically to let the attacker back in. Cleaning is the easy half. Finding the way in is the half that decides whether you are buying a fix or buying three days.

How the cleanup runs, in order

The order is not stylistic. Each step destroys the evidence needed by the one before it if they are swapped, which is why cleanup done in a panic so often ends up costing more.

Preserve the evidence before anything is changed. A complete copy of the files and database taken off the server, the access and error logs saved, the plugin, user and DNS lists exported, screenshots dated. If this project ever touches an insurance claim, or if we break something and need to go back, this is the only thing that makes either possible. Two to four hours.
Containment. All administrator passwords changed, every logged-in session terminated, unrecognised admin accounts disabled — disabled, not deleted, because they are still evidence — and the site put into maintenance mode so visitors stop being harmed while the work happens. One to three hours, same day.
Eradication from a clean source. Surgical file-by-file cleaning is the wrong instinct; it misses things. The reliable method is to reinstall the core, the plugins and the theme from their original sources and to review only the content and the uploads folder by hand. On WordPress, wp core verify-checksums and wp plugin verify-checksums --all compare every file against the official copy and surface both modified files and files that should not exist at all. A scan for PHP files changed in the last seven days narrows the rest. Done on a staging copy first, then applied live. Half a day to two days, depending on size.
Find the entry point. Log entries and file modification timestamps around the point where behaviour changed. Usually this lands on a specific outdated plugin with a flaw its authors disclosed and patched months earlier. Without this step the previous three are temporary. Half a day to a day.
Hardening. Everything updated, multi-factor authentication on the hosting and email accounts, a web application firewall and rate limiting on the login page in front of the site, security headers set, unused plugins removed entirely rather than deactivated, and backups moved somewhere that is not the same server — then a restore actually tested. Half a day to a day.
Delisting and two weeks of watching. A review request in Search Console once the site is genuinely clean, the same with any other blocklist flagging it, then rechecks across the following fortnight, which is when anything missed reappears. Same-day submission, then Google's own review time, fourteen days of monitoring.

What moves the price

$200–$2,500 in 1–5 days covers nearly every case, and three factors decide where a particular site sits.

What the site is. A small brochure site sits at the bottom of the range. A shop taking live orders sits near the top, because every step has to be done without losing transactions, the customer data raises the stakes on the investigation, and the staging-first sequence becomes mandatory rather than sensible.

How long it has been compromised. A site caught in the first day or two is contained quickly. One that has been quietly serving redirects for three months has spread — into the database, into cron jobs, into the uploads folder, into files whose timestamps have been deliberately altered — and the search damage takes longer to unwind.

How much of it is recoverable. A site with a clean backup from before the compromise and code in a repository is a substantially shorter job than one where the only copy of the theme is the modified copy sitting on the infected server, and every file has to be judged by hand.

What usually goes wrong

Only what is visible gets cleaned. The obvious files are removed, the site loads, the invoice goes out — and nothing was done about the outdated plugin that let it happen or the small backdoor left in the uploads folder. The site is compromised again within the week, and you have paid for a few days, not a fix.

The cleanup happens before anyone looks at the logs. Reinstalling first feels like progress and permanently destroys the timestamps and log entries that identify the entry point. Once those are gone, the honest answer for the rest of the engagement is that nobody knows how it happened — which is a bad sentence to write and a worse one to build a hardening plan on.

Backups turn out to be on the infected server. A backup plugin dutifully writing daily archives into a folder inside the same web root is extremely common and provides almost no protection, because whatever reached the site reached the backups too. Discovering this during a cleanup rather than before one is the difference between a restore and a rebuild, and it is the first thing checked.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Can you start today?: Usually yes, because this is the kind of work where the first day matters. What we need before touching anything is a short written authorisation naming the site, the hosting account and the dates — email confirmation is enough to begin — plus access created as a separate account in our name rather than your own login shared over WhatsApp. That takes minutes and it means the server logs can later show exactly which actions were ours.
Should we delete the suspicious files ourselves while we wait?: Please do not. Deleting the visible files destroys the timestamps and log entries that show how the attacker got in, and without that the site is very likely to be compromised again within days. Put the site into maintenance mode if you can, change the passwords from a different device, and leave the files where they are. Everything is backed up before anything is removed.
How long until the Google warning disappears?: The review request goes in the same day the site is genuinely clean, and how quickly the warning lifts after that is Google's timing, not something anyone here can promise. The important word is genuinely — a review request submitted on a site that is still infected fails, and repeated failed requests make the next one slower. We do not submit until the checksums verify and the entry point is closed.
Will you find how they got in?: In most cases yes, from log entries and file modification times around the point where behaviour changed — usually an outdated plugin with a publicly disclosed flaw. Sometimes the hosting provider only retains logs for a short window and the honest answer is that the entry point could not be conclusively identified. When that happens we say so in writing and explain what it means, rather than inventing a cause.
Can you guarantee it will not happen again?: No, and nobody can. What we can say is which route in has been closed, what has changed, and what remains your responsibility — chiefly keeping software updated and keeping multi-factor authentication switched on. A site is never finished being secure, and any supplier who tells you otherwise is selling something.
What happens after the cleanup?: Two weeks of rechecking is included, because reinfection from something missed almost always shows up inside that window. Beyond that, ongoing monthly monitoring is available and worth it for anything taking orders or holding customer data — updates applied, malware scanning, and backups verified by actually restoring one rather than trusting the green tick.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Malware removal & site cleanup All Cybersecurity services