Managing multiple WordPress sites at scale means replacing per-site manual work with a single source of truth: one dashboard that shows uptime, pending updates, backup status and PHP errors across every site, a standardised hosting stack, a fixed update cadence, and automated monitoring. Past roughly 10–15 sites, logging into each wp-admin stops working, you switch to a fleet workflow or you start missing outages and security updates.
If you run 20, 100 or 500 WordPress sites, your enemy isn’t any single task, it’s the multiplication. A two-minute job done by hand becomes 200 minutes across 100 sites. The agencies that stay sane don’t work faster; they remove the multiplication. This guide covers the systems that do that, in the order you’ll feel the pain.
The first decision: centralised dashboard vs logging into each site
Logging into each site individually is fine at three sites and impossible at thirty. The break point is usually 10–15 sites, where you can no longer hold “which sites need updates” in your head, and you start finding out a site is down from the client rather than from a monitor.
A management dashboard inverts the model. Instead of you visiting each site, a central control panel pulls status from every site on a schedule and shows it in one table. The three common approaches:
| Approach | Best for | Trade-off |
|---|---|---|
| Manual login per site | Up to ~5–10 sites | No central visibility; outages found late; updates skipped |
| Hosted SaaS dashboard (ManageWP, WP Umbrella, etc.) | Teams who want zero infrastructure | Often priced per-site; your fleet data lives on a third party |
| Self-hosted dashboard plugin (Siteward, MainWP) | Agencies and devs at scale who want flat cost + data ownership | You host the control panel yourself (one WP install) |
Whichever you pick, the dashboard should answer four questions at a glance, without you opening any site: Is it up? Does it need updates? Is a recent backup in place? Is it throwing errors? If a tool can’t answer those four, it isn’t a fleet tool.
Standardise the stack before you scale it
The cheapest fleet to manage is one where every site looks the same. Variation is what kills you, every bespoke plugin, every odd PHP version, every snowflake host is a separate thing to remember at 2am.
- One host (or two), one PHP version. Pin a current, supported PHP (8.2/8.3 in 2026) across the fleet. Mixed PHP versions mean a plugin update that’s safe on one site breaks another.
- A standard plugin baseline. Define a canonical set: security, caching, backups (UpdraftPlus is the common pick), SEO. Document exceptions per site rather than treating every site as unique.
- Naming and access conventions. Same admin user pattern, same wp-config constants, secrets in a password manager, not in your inbox.
- WP-CLI everywhere. Standardising on hosts with SSH + WP-CLI access lets you script the long tail.
wp plugin list --update=available --format=countacross a host tells you in seconds where work is pending.
Standardisation is the highest-leverage thing on this list because it makes every other system simpler. You can’t automate chaos.
Update cadence: a schedule, not a reflex
Out-of-date plugins are the single biggest source of WordPress compromises, but “update everything immediately” breaks sites and “update when I remember” gets people hacked. Run a cadence instead:
- Security releases: within 24–48 hours. WordPress core minor/security releases and any plugin with a disclosed vulnerability jump the queue.
- Routine updates: a fixed weekly window. Pick a low-traffic day. Update in a batch, with a fresh backup taken first.
- Major versions: staged. Test major plugin/theme jumps and core majors on one or two representative sites before rolling fleet-wide.
- Always back up immediately before bulk updating so a bad release is a five-minute restore, not an incident.
A good dashboard turns this from a chore into a filter: see every pending update across the fleet in one list, tick the ones you want, apply them in one action. The discipline is yours; the mechanics should be one click.
Monitoring: assume something is broken right now
At 100 sites, statistically something is always slightly wrong. The point of monitoring is to know before the client does. Three layers matter:
- Uptime. Check each site’s public URL on a short interval and alert on failure (with a retry to avoid false alarms from a single blip). Checking the public URL, not an internal plugin endpoint, means you still catch a full outage when WordPress itself is down.
- Performance. Response time is an early warning: a site creeping from 400ms to 3s is usually a failing plugin, a runaway query or a host problem before it becomes a full outage.
- Critical errors. The PHP fatal that triggers “There has been a critical error on this website” should surface on your dashboard naming the plugin or theme at fault, so you fix the cause, not hunt for it.
Alerts should fire on state changes (up→down, down→up), not every cycle, or your team learns to ignore the channel. Route them to email plus Slack/Zapier so they land where you actually look.
Backups and documentation: the boring stuff that saves you
You don’t need a backup tool on every site so much as backup visibility across every site. A backup plugin that silently stopped running three weeks ago is worse than none, because you think you’re covered. Track, per site: when the last backup ran, whether it succeeded, and where it’s stored off-server. Surfacing UpdraftPlus backup health on the dashboard turns “I hope everyone’s backed up” into a column you can scan.
For documentation, keep a single fleet register, a spreadsheet is fine to start, with: site URL, host, login location, plugin exceptions, DNS/registrar, client contact, and renewal dates. The goal is that any team member can pick up any site without you in the room.
The per-site cost trap
Here’s the trap that ambushes growing agencies: most hosted management tools charge per site per month. It feels cheap at 10 sites and becomes a tax on growth. Watch what happens at scale:
| Sites managed | Typical per-site SaaS (~$2/site/mo) | Flat-rate self-hosted |
|---|---|---|
| 25 | ~$600/yr | One flat price |
| 100 | ~$2,400/yr | Same flat price |
| 250 | ~$6,000/yr | Same flat price |
Every new client you win raises your tooling bill. The fix is a model where adding a site costs you nothing: a flat annual or one-time licence, ideally self-hosted so your fleet data stays on your server rather than a vendor’s. This is exactly the wedge behind tools positioned as a leaner MainWP and ManageWP alternative, unlimited sites, one price, no per-site fee.
Where automation actually pays off
Automate the high-frequency, low-judgement work; keep humans on the judgement calls.
- Worth automating: uptime checks, update-availability scanning, backup-status pulls, error detection, alert routing. These run constantly and have a clear pass/fail.
- Keep human: deciding whether to apply a risky major update, triaging a genuinely broken site, client comms. Automation should hand you a clean decision, not make it for you.
Siteward (by OmnisWP) is one self-hosted option built for this scale: a free dashboard plugin manages unlimited sites with a parallel engine that stays fast at 200+, surfaces uptime, pending updates and critical errors (naming the culprit), and keeps every byte of fleet data on your own server. Backup-health, WP-Cron-health and Zapier alerting sit in the paid Pro tier (Agency $129/yr or a $399 lifetime licence). It’s deliberately lean, if you’ve found MainWP heavy or ManageWP’s per-site pricing painful, it’s worth a look. See the pricing and Pro features to compare against your current bill.
A 30-minute starting checklist
- Pick a central dashboard and connect every site to it.
- Document your fleet register (URL, host, logins, exceptions, renewals).
- Set uptime + critical-error alerts to a channel you check daily.
- Confirm every site has a working, recent, off-server backup.
- Put a weekly update window on the calendar and a 24-hour rule for security releases.
- Standardise PHP version and your plugin baseline; log the exceptions.
Do those six and managing a large fleet stops being a memory test and becomes a dashboard you glance at with coffee.
FAQ
What is the best way to manage multiple WordPress sites?
Connect every site to a single management dashboard that pulls uptime, pending updates, backup status and PHP errors on a schedule, instead of logging into each wp-admin. Pair it with a standardised stack (one PHP version, a fixed plugin baseline), a weekly update cadence with a 24-hour rule for security releases, and automated uptime and error alerts.
How many WordPress sites can one person realistically manage?
With manual per-site logins, about 5–10 before things slip. With a centralised dashboard, standardised stacks and one-click bulk updates, a single person can comfortably oversee 100+ sites because the work no longer multiplies per site, you act on a fleet, not on individual installs.
Is it cheaper to use a self-hosted or SaaS WordPress management tool?
SaaS tools that charge per site get expensive fast, roughly $2/site/month is about $2,400/yr at 100 sites and $6,000/yr at 250. A flat-rate, self-hosted dashboard costs the same whether you manage 10 sites or 500, so it’s far cheaper at scale and keeps your fleet data on your own server.
How often should I update plugins across many WordPress sites?
Apply security releases within 24–48 hours, run routine updates in a fixed weekly window on a low-traffic day, and stage major version jumps on one or two test sites first. Always take a fresh backup immediately before any bulk update so a bad release is a quick restore rather than an incident.
What should a WordPress management dashboard monitor?
At minimum: uptime (checking the public URL with a retry so full outages are caught), response time as an early warning, backup health per site, available core/plugin/theme updates, and critical PHP errors, ideally naming the offending plugin or theme. Alerts should fire on state changes, not every cycle.