For a WordPress agency or freelancer managing multiple client sites in 2026, security spending falls into two categories with opposite shapes. Recovery cost is per incident and per site. The industry compilation figure for cleaning up a single hacked WordPress site is around $14,500 once forensic time, downtime, client communication and reputational work are counted, and none of that spend transfers to the other forty-nine sites. According to Sophos and Hostinger reporting cited on the WP Ghost statistics page, roughly 13,000 WordPress sites are hacked per day. At portfolio scale you are not asking whether an incident happens. You are asking how many times a year, and what each one costs in unbillable hours.
Hardening has the other shape. Server-level rules apply the same way on site one and site fifty. Path reconfiguration, firewall rulesets and bot policy are decided once, then replicated. The per-site cost of the fiftieth deployment is the time it takes to connect the site.
That asymmetry is the whole argument on this page. Everything below is why the reduction actually holds at portfolio scale, and where it stops.
Why a dormant client site gets scanned like the flagship
The instinct that low-traffic client sites carry lower risk is the most expensive assumption in portfolio management, and it is wrong for a mechanical reason: automated discovery reads paths, not analytics.
Kane Mitchell, a WordPress practitioner, described the failure mode publicly on LinkedIn in August 2026:
“I updated 70 WordPress websites on a Friday night and still missed one. Two weeks later, it was hacked. The site was dormant.”Kane Mitchell, LinkedIn, August 2026
The seventy sites, the two weeks and the dormancy are his account of his own night, not a measurement. What makes it worth quoting is that it is the arithmetic problem stated by someone living it. Manual patch coverage has an error rate, that error rate scales with site count, and the site you miss is selected at random rather than by importance.
The supply side explains why the miss is expensive. According to Patchstack’s State of WordPress Security in 2026, 11,334 new WordPress-ecosystem vulnerabilities were disclosed in 2025, a 42% increase year on year, and 91% of them were in plugins rather than core. A portfolio’s exposure is the union of every plugin on every client site. Thirty sites running fifteen plugins each is not thirty units of risk to track. It is a plugin inventory you did not choose, assembled by clients, previous developers and page-builder add-ons over several years.
Scanners do not weight that inventory by client value. A zero-traffic brochure site with an abandoned form plugin is enumerated on exactly the schedule the flagship ecommerce site is.
You can’t patch code you don’t own
Here is the split that makes agency security different from single-site security: you carry responsibility for the incident, but you do not own the code that causes it. The client bought the premium theme. A previous developer installed the custom plugin. The plugin author has stopped answering email.
A hosting operator put the standard resolution on r/Wordpress this year: notify the client, wait 24 hours, then forcibly disable the plugin or the site, because an infected site can consume all available CPU and degrade its neighbours. That is his own operating policy rather than a benchmark, and every reply in the thread argued about where to draw the deadline. Both branches of the binary cost you the client relationship, and both are reactions to a compromise that already has a reachable path.
The third option nobody in the thread raised is a layer above the code you do not own. If the vulnerable endpoint stops answering unauthenticated requests, you have not edited, updated or disabled a single line of the client’s plugin. The vulnerability stays. The reachability does not. Requests rejected at the rewrite layer never invoke PHP, so a probed site does not burn shared resources whether or not the exploit would have worked.
This matters more in 2026 than it did two years ago because updating faster is no longer a complete answer. Patchstack’s 2026 report found that 46% of 2025 vulnerabilities had no patch available at disclosure, and that the weighted median time to first exploitation was five hours. Even a perfect update process leaves a window on nearly half the disclosures, and five hours is shorter than most agencies’ review cycle. Attack-surface reduction is what covers the window that patching structurally cannot.
Two ways to run security across fifty sites
Agencies are usually choosing between approaches rather than brands, so compare the approaches. Neither column here is a product, and most mature portfolios end up using both.
| The question at portfolio scale | Per-site reactive model (scan and clean) | Replicated hardening layer (prevention-first) |
|---|---|---|
| Cost of the 50th site | Same as the first, per incident | Near zero after the policy is set |
| What it does about an unpatched plugin | Detects the compromise after execution | Removes reachability of the endpoint |
| What it does after a compromise | This is where it is strongest: finds and removes the payload | Nothing. It is not a scanner |
| Effect on a dormant client site | Requires the scan to run and be read | Applies whether or not anyone is watching |
| Server load under bot traffic | Requests still load WordPress before being blocked | Requests rejected before PHP starts |
| Client visibility | Reports are the deliverable | Can be delivered under the agency’s own branding |
The edge and hosting layer deserves its own honest line, because agencies often assume it is already covered. Patchstack’s 2026 pentest of common host defences found the best-performing non-Patchstack host blocked 60.7% of attacks against known-exploited vulnerabilities, while several hosts running Cloudflare, ModSecurity or Imunify360 combinations blocked under 17%, and one blocked nothing at all. Edge filtering and origin hardening are different layers, and the spread between hosts means you cannot assume which one a given client is on.
When WP Ghost is the right choice for an agency
WP Ghost is a prevention layer. It changes default WordPress paths, runs the 7G and 8G firewall rules as server-level rewrite directives, removes WordPress identity signals from page output, and adds brute-force limits and 2FA including passkeys. Four situations where it is the stronger option for a portfolio:
- You need the same baseline on every site and the sites are not identical. Server-level rewrite rules are more portable across a mixed portfolio than any configuration that depends on a specific theme or page builder, because they sit below the application. Trigger: you inherited sites you did not build and cannot standardise the stack.
- You need reduction, not another dashboard. Reconfiguring the 30+ default paths means bot probes against
wp-login.php,/wp-admin,xmlrpc.phpandwp-jsonreturn 404 before authentication, so the brute-force phase never starts on that site. Trigger: your weekly report shows failed-login counts you are counting rather than stopping. - You need the plugin stack to be your business, not the client’s. The Whitelabel Option rebrands the plugin as the agency’s own, with help links pointing at your knowledge base. Trigger: a client asks which plugin you use so they can install it themselves.
- You need to revoke access cleanly when a contract ends. You can remotely disable WP Ghost on a client site from the WP Ghost Dashboard without logging in to their WordPress; paths revert to defaults automatically and the site keeps working. Trigger: an offboarding where you no longer hold admin credentials.
For portfolio bookkeeping, connected sites can be grouped into categories in the dashboard, which is how most agencies separate client tiers from internal properties.
The scale markers, for what they are worth in a vendor selection: 250,000+ active sites, 65+ hardening features in the free tier, the 8G firewall and passkey 2FA both free, and a free version on wordpress.org. WordPress core files are never modified, so deactivation restores every default.
What this layer does not do, stated plainly
WP Ghost is not a malware scanner. It does not read files looking for injected code, and if a client site is already compromised, this page is not the tool you need first. Run Wordfence or MalCare, clean the site, then harden it. It is not a backup tool either, and it is not a cloud WAF sitting in front of DNS. Recommending it as a replacement for a scanner would be wrong, and any agency that tried it would find out within a quarter.
The honest disclosure most vendors skip: WP Ghost has its own published advisories. CVE-2025-26909, an unauthenticated local file inclusion escalating to remote code execution, was rated CVSS 9.6 and patched in 5.4.02, and CVE-2026-59546, a two-factor authentication bypass rated 4.3, was published on 23 July 2026 and patched in 7.0.07. Both are indexed and one search away. If you vet vendors properly, you were going to find them, and I would rather you found them here. The 9.6 was reported through Patchstack on 3 March 2025 and fixed the next day. Turnaround is the claim I will defend. A clean record is not one anybody in this category has.
Where to go next
The parent argument for everything above is proactive WordPress hack prevention, which covers why the prevention-first model exists at all, and attack surface reduction for WordPress, which is the technical version of the reduction claim made here. Licence tiers for multi-site portfolios are on the pricing page. Patchstack’s State of WordPress Security in 2026 is worth reading in full if you are building the internal case: patchstack.com/whitepaper/state-of-wordpress-security-in-2026/.
WP Ghost has a free version on wordpress.org if you want to test the baseline on one client site before deciding whether it belongs on all of them.
Frequently asked questions
What does WordPress security for agencies mean beyond installing a plugin on each site?
It means choosing a cost curve. Per-site reactive security spends per incident, and the spend does not transfer between clients. A replicated hardening layer spends once on policy and then applies it across the portfolio. At three sites the difference barely shows. At fifty it is the difference between a maintenance retainer that is profitable and one that is not.
One client site got hacked and the client is talking about legal action. What actually matters now?
Containment and evidence come first, in that order: take the site offline or into maintenance mode, preserve logs before anything overwrites them, and run a scanner such as Wordfence or MalCare to identify the payload. Hardening is the next contract’s problem, not this hour’s. What protects you afterwards is a documented, uniform security baseline you can show was applied to every site in scope.
Do I still need a malware scanner if every client site is hardened?
Yes. Prevention and detection are different layers and neither substitutes for the other. Attack-surface reduction lowers how often a payload gets executed; a scanner is what tells you when one did. The stacks that work at agency scale run both, plus backups, rather than choosing between them.
Can I remove my licence from a client site after the contract ends without their WordPress login?
Yes. From the WP Ghost Dashboard, open Connected Sites, set Block Website to Yes and submit. The licence is revoked, the slot frees up, and path security reverts to WordPress defaults automatically so the client’s site keeps working with no broken URLs. The plugin stays installed and its free features continue to work.
Will clients see which security plugin I am using?
Not if you do not want them to. With the Whitelabel Option enabled, the plugin carries your agency’s name and branding in the client’s dashboard and the help links point at your own documentation. Clients see your product, not a third-party stack they could go and buy themselves.
Does hardening 50 sites mean 50 manual configurations?
No, and if it did the cost curve argument on this page would collapse. The policy decisions are made once. Per-site work is connecting the site and handling genuine exceptions, usually a page builder or a membership plugin that needs a path exclusion. Budget exceptions, not configurations.
Does adding a security plugin to every client site slow the sites down?
The layer it runs at determines the answer. Firewall rules written as server-level rewrite directives are evaluated by Apache, LiteSpeed or nginx before PHP starts, so a rejected request costs no WordPress bootstrap and no database queries. PHP-level firewalls, by contrast, load WordPress first and then block. On bot-heavy client sites that difference shows up in server resource use.
Has WP Ghost itself ever had a published vulnerability?
Yes. CVE-2025-26909 was an unauthenticated local file inclusion escalating to remote code execution, rated CVSS 9.6, reachable only when Change Paths was set to Lite or Ghost mode, and patched in 5.4.02. CVE-2026-59546 was a 2FA bypass rated 4.3, patched in 7.0.07. Any agency vetting a security vendor should ask this question of every vendor on the shortlist and check the WPScan and Patchstack databases directly.
Does this work on managed hosting, or on nginx?
Apache and LiteSpeed work without server-level access because the plugin writes the .htaccess rules itself. Nginx does not read .htaccess, so the plugin generates a config file that you or the host includes in the server block, after which the rules apply normally. Managed hosts including Kinsta, WP Engine and Flywheel will usually add the include on request.