img

Bottom line: most small-business WordPress malware cleanups cost between $300 and $1,800 in 2026. Straightforward cleanups start around $300. Serious incident response on e-commerce sites runs $1,800 to $6,500 or more.

Two scenarios bring people to this page. Either your site is compromised right now and you need to know what fixing it costs, or you got a quote that came back higher than you expected and you want a sanity check. Both are reasonable. Here’s what’s worth understanding before you keep shopping…

Malware removal is specialist work that takes hours when it’s done right. The wide range in price comes down to a single question: did the cleanup find the entry point and the persistence the attacker left behind, or did it just delete the obvious malicious files? Those are fundamentally different services that happen to share a name. The first one solves the problem, the second one resets the clock; the visible symptoms disappear for a week or two, and then the compromise returns through a backdoor that was never touched.

Below is how I think about pricing, why the same word (“malware”) can mean a $300 job or a $6,500 job, and when you don’t need to hire anyone at all.

Quick Pricing Reference

Situation Typical Cost Best For
Basic WordPress malware cleanup $300-$500 Single site, contained infection, clean access, no reinfection pattern
Advanced WordPress cleanup $500-$1,800 Redirects, SEO spam pages, hidden admin users, server-level persistence, repeat reinfections
Full incident response + hardening $1,800-$6,500+ E-commerce, membership sites, business-critical sites, possible data or payment exposure
Ongoing monitoring & hardening from $100/month Businesses that cannot afford another compromise

The rest of this article explains what each of those tiers actually covers, what moves a job from one tier to the next, and how to decide whether to hire someone at all.


What You’re Actually Paying For

Removing malware is the visible part of the work. Most of the cost is everything around it: figuring out how the attacker got in, finding everything they touched, removing every backdoor (not just the obvious one), confirming the site is genuinely clean, and then closing the door so the same thing doesn’t happen again next month.

A typical WordPress cleanup includes some combination of:

stonegate_ir // incident response protocol
01 triage
Confirm what's actually wrong
Not every "hack" is a hack. Sometimes the malware alert is a misconfigured plugin, a false positive from the host, or a legitimate file tripping a signature. We confirm the real situation before touching anything.
site scanlog reviewfalse-positive check
02 forensics
Find the entry point, timeline, and scope
How did they get in? When? What did they touch? The answers determine whether this is a single-file defacement or a full-compromise scenario, and they dictate every step that follows.
access logsfile timestampsuser audit
03 file cleanup
Remove malicious files, restore legitimate ones
Injected PHP, obfuscated shells, modified core files, rogue uploads. Every file gets compared against known-good sources. Malicious code is removed; legitimate files are restored to verified copies.
diff analysiscore integrityupload scan
04 database cleanup
Purge what's hiding in the data layer
Attackers don't just drop files, they inject posts, create hidden admin accounts, plant malicious options rows, and schedule rogue cron jobs. The database gets the same forensic treatment as the filesystem.
user table auditoptions sweepcron inspection
05 backdoor sweep
Find the persistence mechanisms others miss
This is where cheap cleanups fail. Attackers leave multiple re-entry points: webshells in non-obvious directories, mu-plugins, modified theme functions, base64-encoded callbacks. Miss one and you're reinfected within days.
mu-pluginswebshell detectionobfuscation patterns
06 hardening
Close the door they came in through
Cleaning up without hardening is just waiting for round two. Credentials get rotated, file permissions get locked down, the vulnerable entry point gets patched, and WAF rules go in to block known attack patterns.
credential rotationpermissionsWAF rulespatching
07 verification
Confirm it's clean and staying clean
The site gets a final full scan, blocklist status is checked across Google, Norton, Sucuri, and others, and we monitor for reinfection signals. You get a clean bill of health, not a hope and a prayer.
full scanblocklist checkreinfection monitor

When pricing varies between tiers, it’s almost always because some of those steps blow up in scope.


Tier 1: Basic cleanup — $300 to $500

Best case scenario. The site is online, you have admin access, the infection looks contained, and the attacker hasn’t been inside long enough to build a colony. Usually this is a single WordPress site (not a multisite network) with one obvious symptom — a defaced page, a known plugin vulnerability, a single round of injected code. No e-commerce, no membership data, no payment pages. The host hasn’t suspended the account, and nothing is actively reinfecting while I’m working.

Most of these I can turn around in one to two business days. The work is methodical rather than adversarial — you’re not chasing someone, you’re cleaning up after them.


Tier 2: Advanced cleanup — $500 to $1,800

This is where most of my malware engagements actually land. The site is compromised in a way that suggests the attacker spent real time inside it, or in a way that keeps reasserting itself after a basic cleanup didn’t take.

The signs are usually some combination of hidden admin users that didn’t exist last week, SEO spam injection (sometimes hundreds of posts in Japanese, Russian, or pharma-keyword gibberish), malicious redirects that send mobile visitors to a different site than desktop visitors, reinfection within hours or days of a previous cleanup, or server-level persistence — backdoors that live outside the WordPress install entirely, in .htaccess, in cron, or in the user’s home directory. When several plugins are compromised at once rather than just one, that usually points to stolen credentials rather than a single vulnerability, which changes the scope of what needs to be checked.

These take longer because the cleanup itself is the easy part; the hard part is making sure you’ve found everything. I’ve worked cases where the visible malware was placed last month but the actual backdoor had been sitting there for over a year, untouched, waiting to be reactivated. If you only clean what’s obvious, the attacker comes back the moment they want to. Tier 2 jobs usually run two to four business days depending on how patient the attacker was.


Tier 3: Incident response — $1,800 to $6,500+

This tier isn’t really “malware removal” anymore. It’s incident response, and the cost goes up because the work expands well beyond file cleanup.

Tier 3 is what happens when a payment skimmer is stealing credit cards at checkout, when customer data may have been exposed, when API keys or merchant credentials are in the wild, when a membership site’s user accounts are potentially compromised, or when the host has suspended the account and there’s a contractual deadline to get it back online. Often the business is actively losing money while we work — fraudulent charges, chargebacks, blocklisted email, lost orders.

At this tier you’re paying for forensics, written documentation you can hand to your processor or your insurer, customer-impact analysis, credential rotation across multiple systems, and coordination with the host, the payment processor, and sometimes law enforcement. The cleanup itself is maybe a quarter of the bill. The rest is the work that makes the cleanup actually mean something. Tier 3 engagements typically run one to three weeks of active work, sometimes longer if there’s an audit trail to preserve.


What Changes The Price

The same compromise can cost very different amounts depending on what’s around it. Multisite installs are slower because every subsite has to be checked individually. Sites without clean backups — or with backups that turn out to be infected — take longer because rebuilding is slower than restoring. Custom themes and unmaintained plugins multiply the surface area; every custom file is a place a backdoor could live. Hosts that don’t give shell access add real time to the job, because file-level cleanup over SFTP and a hosting file manager is dramatically slower than over SSH. Pirated themes and plugins are often both the source of the infection and a place reinfection hides. Large media libraries take time to scan for PHP files masquerading as images. And if the attacker is still actively inside the site while I’m cleaning, the job becomes meaningfully harder.

A few things that aren’t entry points but still expand the work: when Google has flagged the site, there’s a Search Console review-request step and a recovery timeline tacked onto the end. When the database is infected and not just the files, the cleanup is a different and slower kind of work.

The factors that pull a job toward the cheaper end of its tier are mostly the inverse: a current, clean backup from before the compromise, knowing roughly when the infection started (which narrows the forensic window dramatically), working admin and hosting access without a password recovery dance, a cooperative host willing to share access logs, and a site running on current PHP, current WordPress core, and supported plugins. If most of those are true, your cleanup will land on the lower end of whichever tier it falls into.


Cheap Cleanup vs. Proper Remediation

This is where the market gets confusing for business owners.

A cheap cleanup often means someone deletes the obvious malicious files and hands the site back. The Google warning may temporarily disappear. The visible symptoms may stop. But this approach doesn’t always answer the more important question: how did the attacker get in, and can they get back in tomorrow?

The difference between a $200 cleanup and a $2,000 cleanup isn’t the deletion step — that’s a few minutes either way. The difference is the work around it: finding the entry point, finding the secondary backdoors, hardening what was exploited, and verifying the site is genuinely clean afterward.

If a cleanup quote doesn’t mention any of those four things, it’s removing symptoms, not solving the problem. The compromise will usually return within days or weeks, often through a backdoor the cleanup never touched.


When You Can Probably Fix It Yourself

Not every compromised WordPress site needs a professional. If you have a clean backup from before the infection started, and you actually know roughly when the compromise happened, you’re already most of the way there — restoring is faster than cleaning, assuming you can verify the backup itself isn’t infected. The other prerequisites are mostly about comfort level: are you willing to replace WordPress core, plugins, and themes from scratch using official sources? Are you willing to look through your user list for accounts you didn’t create, scan your cron jobs for entries you didn’t add, and read access logs to see whether the attacker is still poking at the site? And is this a site you can take offline for a day or two without losing money — no checkout, no membership area, no customer data sitting in the database?

If all of that’s a yes, the practical playbook isn’t complicated. Take the site offline, replace core and plugins and themes from official sources, restore the database from a clean backup (or scrub it manually if you have to), rotate every credential the site touches — admin, hosting, FTP, database, email, any API keys — harden what you can, and watch the access logs for a couple of weeks afterward to make sure nothing’s coming back. If you’re technical enough to do all of that without panicking, you don’t need to hire anyone. Genuinely.


When You Should Hire Someone

The other side of the line is harder to ignore once you know what to look for. If the site keeps getting reinfected after you clean it, the cleanup hasn’t found everything — there’s a backdoor somewhere you’re not looking, and another round of file deletions won’t change that. If visitors are being redirected, especially only on mobile or only when they arrive from search engines, the attacker has injected logic that varies by visitor, and that kind of compromise rarely shows up in a casual scan. If Google or Safe Browsing is showing a warning on your site, the cost of leaving it in place compounds the longer it sits there, and getting it removed properly requires a clean site plus a Search Console review you can’t afford to burn by submitting too early.

The other situations that mean you should bring someone in are mostly about stakes rather than complexity. Unknown admin users that appeared without explanation. Login or checkout pages involved in the compromise. A host that’s suspended your account. Any site that processes payments, stores customer data, or has a membership area. No clean backup from before the infection — or no clear sense of when the infection actually started, which makes “before” hard to define. Each of those raises the cost of getting the cleanup wrong to the point where doing it yourself isn’t really worth the risk, even if you’d technically be capable of it.

If you’re sitting somewhere in the middle — capable enough to do the work, but with a site that has real customers or real revenue on it — the honest answer is that the triage call is free. Spend twenty minutes telling me what’s going on and I’ll tell you which side of this line you’re actually on. Sometimes the answer is “you don’t need me, here’s what to do.” That’s a fine answer.


What Stonegate Does Differently

WordPress malware removal at Stonegate is not just deleting suspicious files. The methodology, in order:

  1. 01
    Triage and timeline. Before touching anything, I figure out roughly when the compromise started and what changed. The timeline tells you which logs matter and which backups are still trustworthy.
  2. 02
    Entry point first. I find the entry point before the cleanup, not after, because cleanup without that information is guesswork. Common entry points: a vulnerable plugin (often something niche), reused or weak admin credentials, a backdoor left from a previous unrelated compromise, or pirated software.
  3. 03
    File-level cleanup with version control. Replacing core, plugins, and themes from official sources beats trying to "clean" them in place. Custom code is diffed against version control or known-good copies.
  4. 04
    Database review. Hidden admin users, malicious options rows, injected post content, malicious cron jobs, fake user roles — none of these show up in a file scan.
  5. 05
    Persistence sweep. This is the step most cheap cleanups skip. Backdoors hide in places like server cron, the user's home directory, .htaccess files in obscure subdirectories, mu-plugins, dropins, and even in image files with executable permissions. If the persistence sweep is skipped, reinfection is a question of when, not if.
  6. 06
    Hardening. Closing the entry point, updating credentials across every system the site touches, configuring a real WAF, fixing file permissions, removing unused plugins and themes, and updating PHP if it's behind.
  7. 07
    Verification. External scans, search-engine warning removal, log monitoring for the first week or two, and a written report of what was found and what was done.

The goal isn’t only to get the site clean. It’s to reduce the chance the same compromise comes back.


Real Examples (Anonymized)

A few patterns from past engagements, with identifying details removed:

Case 01

A real estate firm came in worried about email spoofing. The deeper problem turned out to be an actively compromised WordPress site with hidden backdoors, attacker sessions still open, and outbound spam being sent through the site itself. The email problem was a symptom, not the cause.

Case 02

An e-commerce site looked like a redirect problem from the outside. Underneath, the compromise included a payment skimmer, abused Stripe keys, spam infrastructure, and an old backdoor that changed the whole scope of the response.

Case 03

A WordPress media site had a hidden admin user, a fake plugin, a URL-triggered backdoor, and ad injection stored where normal file scans would not catch it. The visible symptom was only the surface of the compromise.

Case 04

A routine WordPress audit uncovered publicly downloadable backups, suspicious login artifacts, and email authentication gaps before they became a larger incident.

Case 05

A neglected WordPress stack shows the pattern behind many expensive cleanups: old core, old PHP, unpatched plugins, and an avoidable compromise that becomes far more costly than maintenance would have been.

Each of those cases looked different from the outside. Underneath, the pattern was the same: the attacker had built persistence the owner couldn’t see, and surface-level cleanup wouldn’t have removed it.


How Stonegate Prices It

I price cleanups on scope, not by the hour, because it’s not in your interest to wonder whether the clock is running every time we exchange a message. After a quick triage call — usually free, usually 15 to 30 minutes — I’ll tell you which tier the job is in, what’s included, what’s separate, and a fixed number. If the job turns out to be smaller than I estimated, I tell you. If it turns out to be bigger, I tell you that too, in writing, before any extra work starts.

If you’re not sure what you’re dealing with, that’s fine. Most clients aren’t. The triage call is genuinely the right first step — sometimes the answer is “this isn’t malware, it’s a caching plugin misconfigured” and you don’t need to hire anyone at all.


If your WordPress site is compromised right now, or you’re not sure whether it is, get in touch and I’ll take a look. Triage is free, the answer is plain English, and the quote afterward will be a real number, not a placeholder.


Frequently Asked Questions

Tier 1 cleanups usually take one to three business days. Tier 2 cleanups usually take three to seven business days. Tier 3 incident response usually takes one to three weeks. Anyone promising same-day cleanup on a serious compromise is usually skipping forensics, verification, or both.
Yes, if the cleanup did not find the entry point or did not sweep for persistence. Reinfection within days almost always means the attacker’s secondary backdoor was missed. A cleanup that includes both steps should not reinfect.
Only after the site is genuinely clean and you submit a review request through Google Search Console. The warning does not time out by itself, and submitting too early before the site is actually clean can fail the review and reset the timeline.
For most small-business sites with content history, SEO history, and configured integrations, cleanup is faster and cheaper than rebuilding. For abandoned sites with no traffic and no backups, rebuilding on a current platform is sometimes the better answer.
It depends on the compromise. A simple defacement or SEO spam infection usually does not touch customer data. A payment skimmer, a database backdoor, or admin-level access by the attacker means data exposure is possible and needs to be investigated explicitly. If the site collects payments, logins, or personal information, assume data exposure until you have ruled it out.
Hosts run automated scans for known malware signatures. They will usually flag, throttle, or suspend a site that triggers those scans. The flag is real, but the host’s solution is usually limited to using a paid scanner or restoring a backup. Neither answer tells you how the attacker got in.
Yes, often badly. Compromised sites are routinely used to send spam through the site’s mail server, which can get the sending IP and domain blocklisted. I see this constantly: a client comes in worried about email delivery, and the root cause is a compromised website that has been sending spam for weeks.
If you have a clean backup from before the compromise, restoring is faster and safer. The catch is that clean needs to be verified because many backups already contain the backdoor. If the only backups you have are from after the compromise started, restoring just resets the timeline without solving anything.
A WAF or scanner can help prevent future compromises and detect some threats. Neither removes existing infections reliably, especially server-level persistence, database injections, or backdoors hidden in custom code. They are useful as part of a hardening strategy, not as a substitute for cleanup.
Keep PHP, WordPress core, and plugins current. Use real backups, a real WAF, admin accounts that are not shared, and credentials that are not reused across systems. Most compromises I see are preventable with maintenance that costs less per year than a single cleanup.

Related Reading