June 22, 2026

WordPress security for agencies: how to protect 20+ client sites without burning out

You took on the maintenance contracts because the recurring revenue looked great. Then a Wordfence advisory hits on a Sunday night, you realize 14 of your clients run that plugin, and you're suddenly doing emergency triage until 3 AM. If you're running a fleet of WordPress sites without a system, you're not running an agency — you're running a pager rotation with extra steps.

This post is the system. Monitoring, patching, triage, and incident response for agencies and freelancers who maintain anywhere from 10 to 100+ WordPress sites. It's not theoretical. It's what separates the agencies that grow past 20 clients from the ones that quietly drop maintenance retainers because they can't keep up.

The fleet monitoring problem

You cannot log into 20 sites every day. You can barely log into five. Once a maintenance portfolio gets past about eight sites, manual checking becomes a coin flip — you'll catch some problems, miss others, and never know which until a client emails you about it.

You need three layers of automated monitoring running on every site in your fleet:

Uptime monitoring. Five-minute checks minimum, ideally one-minute for higher-tier clients. UptimeRobot, Better Uptime, and Pingdom all work. The free UptimeRobot tier gets you 50 monitors at five-minute intervals, which covers most agencies starting out. Set up SMS alerts for downtime over two minutes, email for everything else. Pro tip: monitor the homepage and a critical page (checkout, contact form, login) on each site. Homepages cache aggressively and can stay "up" while the rest of the site is broken.

File integrity monitoring. This is the one most agencies skip, and it's the one that catches real attacks. When a plugin gets compromised or a backdoor gets dropped into /wp-content/uploads/, you want to know within hours, not weeks. Wordfence's free version does this on individual sites. For fleet management, you want a tool that centralizes the alerts — more on that below.

Malware scanning. Daily or twice-daily scans on every site. Wordfence, Sucuri, and MalCare all do this. The point isn't catching everything (no scanner does), it's establishing a baseline and getting alerted when that baseline changes.

The goal of monitoring isn't to prevent incidents. It's to compress the time between "something broke" and "I know about it" from days to minutes. That single change does more for client retention than any other security investment.

Patch management without the panic

Auto-updates are the most-debated topic in WordPress agency circles, and the people on both sides are wrong. The answer isn't "auto-update everything" or "update nothing without manual review." The answer is a tiered approach:

Auto-update WordPress core minor releases. These are 5.8.1 → 5.8.2 style updates. They're security patches. The WordPress security team is conservative — they don't ship breaking changes in minor releases. Turn these on. They're enabled by default in modern WordPress; don't disable them.

// In wp-config.php — these are usually the defaults, but verify
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Auto-update plugins selectively. For plugins from reputable developers (Yoast, Wordfence, WooCommerce official, Gravity Forms), turn on auto-updates. For niche plugins with small teams, do manual updates with a staging test first. The risk calculus: a security flaw in an unpatched plugin will hurt you more often than a botched auto-update from a well-maintained one.

Manual updates for major core versions, themes, and WooCommerce. Major core releases (5.x → 6.x), theme updates, and anything touching e-commerce should never auto-update. Always update in staging first, click through the critical user flows, then push to production. WooCommerce updates in particular have a history of breaking custom checkout flows.

Your staged rollout process should look like this:

Update fires on Monday. You triage in your dashboard — what changed, what risks does it carry?
Tuesday: push to staging on three to five "canary" sites (your own, plus two clients with permission to be first).
Wednesday: smoke test those canaries. Run through key flows. Check error logs.
Thursday–Friday: roll out across the fleet in batches.
Document any sites that needed special handling.

This sounds like a lot. It is. But it scales — once you've built the runbook, the only variable is how many sites are in the batch.

The 0day triage matrix

This is the scenario that defines agencies: a critical vulnerability drops in a popular plugin. Active exploitation in the wild. You need to know, immediately:

How many of my client sites run this plugin?
What versions are they on?
What's my patch order?

If you cannot answer question one in under 60 seconds, you don't have a manageable fleet — you have a portfolio of accidents waiting to happen.

The triage matrix is a spreadsheet (or database, if you've grown out of spreadsheets) with these columns: site URL, client name, hosting provider, primary contact, plugin inventory, theme, PHP version, WordPress version, last backup timestamp, monthly revenue from this client. The plugin inventory column is the critical one. When a CVE drops, you should be able to filter your sheet and get a list of affected sites in seconds.

Most fleet management tools build this for you automatically (next section). If you're under 10 sites, a manual spreadsheet works. Above that, you need tooling.

Your patch order, when an active 0day hits multiple clients:

Highest-traffic and e-commerce sites first. A compromised WooCommerce site can leak customer payment data, which is a legal disaster.
Sites with admin accounts the attacker would value. Anything connected to an email list, payment processor, or sensitive data.
High-revenue clients next. Honest economics.
Everyone else, batched.

Communicate proactively. The email you send to all affected clients while you're patching is part of your professional brand. Something like: "Plugin X disclosed a critical vulnerability this morning. Your site is affected. We're patching in priority order over the next four hours and will confirm when your site is updated. No action needed on your end." That email turns an emergency into a demonstration of competence.

Centralized tooling: MainWP vs ManageWP

You cannot run a 20+ site fleet from the WP admin of each site. You need a central dashboard. The two main contenders:

ManageWP (owned by GoDaddy). Cloud-hosted, polished UI, freemium pricing. The free tier covers core fleet management (one-click updates across all sites, basic uptime, backups). Premium add-ons run $1–2 per site per month each — backups, security checks, SEO, performance. For a 20-site fleet running the full stack, you're looking at roughly $40–80/month. Pros: zero setup, works immediately, good mobile app. Cons: GoDaddy owns it (make of that what you will), per-site pricing scales linearly, you don't control the data.

MainWP. Self-hosted (you install it on a WordPress site you control), open-source core, paid extensions. One-time or annual license for the extensions you want; no per-site fees. Pros: you own the data, flat pricing regardless of fleet size, more extensible. Cons: you're maintaining another WordPress site (your dashboard site itself needs to be hardened), UI is functional but dated, slightly steeper learning curve.

My honest take: if you're under 15 sites, ManageWP free tier is fine. As you scale past 25–30 sites, MainWP's flat pricing wins on cost and you've earned the operational maturity to host your own dashboard. The pivot point is roughly $50/month — when ManageWP's per-site fees cross that, switch.

Either way, the dashboard is non-negotiable. The hours it saves you in month one pay for any subscription many times over.

White-label incident response: have a runbook

This is where most agencies fall apart. Monitoring catches the incident, but then what? When a client calls at 7 PM saying their site is showing pharmacy spam in Google results, your response in the next 30 minutes determines whether you keep the client.

You need a written runbook. Not in your head — written down, version-controlled, accessible from your phone. Mine has these phases:

Phase 1: Containment (first 60 minutes). Take the site offline or put it behind a maintenance page. Snapshot the current (compromised) state for forensics — don't just restore a backup and overwrite the evidence. Change all admin passwords, rotate hosting credentials, revoke active sessions.

Phase 2: Assessment. When did the compromise happen? Check wp-content/uploads/ for PHP files (there should be none). Check the wp_users table for unauthorized admins. Diff the core files against a fresh WordPress download. Review access logs for the entry point.

Phase 3: Eradication. This is the phase amateurs skip. Removing visible malware isn't the same as removing the attacker's foothold. I worked on a Southern California contractor's WordPress site where a previous freelancer had "cleaned" the malware multiple times — the spam posts kept coming back. The reason: there was a self-healing backdoor that would regenerate the malicious code every few hours. Cleaning the symptoms without finding the persistence mechanism is worse than doing nothing, because it gives the client false confidence. (Full write-up: thewizrdz.io/case-studies/wordpress-malware-incident-response.)

Eradication means: removing every backdoor, every modified core file, every unauthorized user, every malicious cron job, and every compromised credential. Then you patch the vulnerability that let them in.

Phase 4: Recovery. Restore from a known-clean backup if possible, or rebuild on top of the cleaned site. Verify the site works. Bring it back online.

Phase 5: Hardening. Add the protections that should have been there: 2FA, login attempt limits, file editing disabled, security headers, a WAF rule blocking the original attack vector.

Phase 6: Reputation recovery. If the site was blacklisted by Google Safe Browsing or showing spam in search results, submit reconsideration requests, request reindexing of clean URLs, and clean up any malicious search snippets.

Phase 7: Client communication. A written incident report. What happened, what you did, what's been changed, what you recommend going forward. This is the document that turns a stressful incident into a renewal.

A runbook isn't a luxury. It's the difference between handling an incident in four hours versus four days, and the difference between a client thanking you for your professionalism versus posting about you on Reddit.

What to actually charge

Maintenance retainers should not be priced like a commodity. The agencies that race to the bottom on $29/month "unlimited WordPress maintenance" plans either lose money on every incident or cut corners until something catastrophic happens.

Real numbers for a 20-site fleet, assuming you've built the systems above:

Tooling: $50–100/month
Your time: roughly 4–8 hours per week across monitoring, patching, and client communication
Reserve for incidents: budget for 2–3 incidents per year per fleet of 20 sites

Price retainers to cover this with margin. [TODO: Sebastian — drop in your actual retainer pricing tiers here, or leave as "starts at $X/site/month" range.] The agencies that win at WordPress maintenance treat it as a security service, not a babysitting service.

Closing thought

Twenty client sites is not a side hustle. It's a fleet, and fleets need systems. The agencies that burn out are the ones still doing this manually at site 25 because they never built the runbooks, the dashboards, and the triage matrices when they had 10 sites and time to think.

Build the systems before you need them. Future-you, fielding three simultaneous 0day calls, will thank present-you.

If you're running an agency or freelance practice and want help setting up the monitoring, patching, and incident response runbooks for your fleet — or you want to white-label IR through someone who's done it — that's exactly what the agency-tier security retainer is built for. Have a look at thewizrdz.io/#security or send a message through the contact form on thewizrdz.io. Happy to talk through your specific fleet setup.