> blog
What 1,500 WordPress sites taught us about running a fleet
Most agencies build WordPress sites and hand them off. We hand off, then host.
The economics shift completely past 100 sites
When you have 5 WordPress sites, problems take 30 minutes each to fix. Manageable. When you have 50, that’s 25 hours a week. When you have 500, you can’t fix problems site-by-site any more: you have to fix CLASSES of problems platform-wide.
We hit this wall around 200 sites. The fix was JezPress: a centralised platform that manages the fleet, lets us roll out updates from one place, monitors everything, and converts “visit each WP-admin” into “run a fleet operation.”
If you’re running 5 WordPress sites, you don’t need this level of infrastructure. If you’re running 50, you should be thinking about it. If you’re running 500, you can’t function without it.
Plugin sprawl is the biggest operational risk
On a typical WordPress site, you’ll see 15-25 active plugins. Across 1,500 sites, that’s 22,500-37,500 plugin instances. When ONE of those plugins develops a vulnerability, every instance is at risk.
We track plugin currency across the fleet daily. Within 24 hours of a security advisory, we know exactly which sites have the vulnerable version and we patch them automatically.
Doing this manually is impossible past about 50 sites. Doing it tooling-driven is straightforward but the tooling has to be built, which we did, and is now part of JezPress.
Standardisation is non-negotiable
Snowflake sites (each with a different theme structure, different plugin set, different auth setup) can’t be managed at scale. Either you standardise, or you accept that fleet operations cost more than per-site operations on a tiny fleet.
Our fleet runs Elementor + a small set of approved theme bases + JezPress + a curated plugin list. New sites can deviate, but every deviation has cost. Most clients accept the standardisation in exchange for the lower hosting costs and better security posture.
Site density matters more than people think
Many shared hosts pack 200-500 WordPress sites onto a single server. Performance suffers, security incidents cascade across tenants, traffic spikes on one site drag down the others.
We’re much less dense. Smaller groupings with proper resource isolation. Costs more per site at the infrastructure level, but the performance difference is dramatic. Sites stay fast, security incidents are contained, traffic spikes don’t affect neighbours.
Surprising thing #1: client churn is low
We expected WordPress hosting to be price-competitive and churn-prone. Reality: when sites are reliable, fast, secure, and supported by humans who answer the phone, clients stay for years. Many of our hosting clients have been with us for over a decade.
The lesson: cheap hosting competes on price and loses customers when something breaks. Our model competes on operational quality and keeps customers because nothing breaks.
Surprising thing #2: support volume is bimodal
Most months: very few support tickets per site. Sites just run. Then quarterly, there’s a WordPress core update or a plugin update or a hosting infrastructure change, and the volume spikes briefly.
We staff for the spikes, not the average. The slow weeks pay for the busy weeks. If we staffed for the average we’d be terrible at the busy weeks.
Surprising thing #3: most “security incidents” aren’t
When sites get flagged for “security issues,” 80% of the time it’s false positives. WordPress core updates that look weird in a malware scanner. Legitimate plugin behaviour that triggers alarms. Cloudflare WAF challenges that prevent harmless requests.
Real compromises are rare with proper baseline security. The Cloudflare-fronted, JezPress-secured, OAuth-only sites we run almost never get compromised. The exceptions tend to be social engineering against the client themselves (phished credentials, leaked passwords) rather than direct platform attacks.
What this means for clients
If you have one WordPress site and it works, none of this affects you directly. But the platform-level work is what makes your individual site work.
If you’re running multiple WordPress sites yourself, particularly across different developers, the operational complexity compounds quickly. Talk to us about consolidating onto one platform: the economics shift dramatically once you cross about 5-10 sites under your management.