How to manage multiple WordPress sites without it consuming your week
Managing five WordPress sites by logging into each one works. Managing forty that way does not, and the point at which it stops working arrives faster than most people expect.
The short answer
Past about five sites, manual management stops scaling and something has to change. The three viable approaches are WordPress multisite, a self-hosted management dashboard, or a managed management platform. Multisite is right only when sites genuinely share a codebase; for independent client sites, a management tool is almost always correct. The workflow matters more than the tool: batch by risk, verify after every change, and make backups provably restorable.
Why manual management fails at around five sites
The failure is not dramatic. Nobody decides that managing sites individually has stopped working. What happens is that the time cost grows linearly while attention does not, and things start being skipped.
The arithmetic is simple enough to be uncomfortable. Logging in, reviewing pending updates, taking a backup, applying updates and checking the site takes perhaps fifteen minutes per site if nothing goes wrong. At five sites that is just over an hour a week, which is manageable. At forty it is ten hours a week, which is a quarter of someone's job, and it is a quarter spent on work that generates no revenue and produces nothing a client can see.
So it gets skipped. Updates wait until there is a spare afternoon. Backups are assumed rather than checked. Nobody looks at whether a site is slow until the client mentions it. The portfolio drifts, and then one day a plugin with a published vulnerability that has been unpatched for six weeks gets exploited on a client site.
The way out is to stop working site by site. Being able to bulk update WordPress plugins across every site in one pass removes the per-site tax on the routine work, and a single WordPress maintenance dashboard replaces the thirty wp-admins you would otherwise have to remember to visit.
The specific things that break first
- Security patches applied on a monthly cadence rather than within days
- Backups running but never restore-tested, so nobody knows if they work
- Certificates renewing manually with no owner, until one lapses
- PHP versions drifting past end of life without anyone tracking it
- Client reports written from memory at month end, or not sent at all
- Administrator accounts for former staff and agencies never removed
The three approaches, and when each is right
WordPress multisite management
Multisite runs several sites from a single WordPress installation sharing one codebase, one plugin set and one database. It is genuinely excellent for the case it was designed for: many sites that are variations on the same thing, such as a university's departmental sites or a franchise's regional pages.
It is usually the wrong choice for a client portfolio, and the reasons are worth stating clearly because multisite is frequently proposed by people who have not run one at scale.
- All sites share a plugin and theme codebase, so one client cannot have a plugin another does not
- A plugin conflict or a bad update affects every site in the network simultaneously
- One database means one failure domain and one restore, so you cannot restore a single client
- Moving a site out of a multisite network later is real work, not a configuration change
- Hosting requirements and complexity increase, and fewer hosts support it well
- A compromise on one site is a compromise of the network
Use multisite when sites genuinely belong together and are managed as one product. Do not use it as a way to manage unrelated client sites more efficiently, because the coupling it introduces is a liability rather than a convenience.
A self-hosted management dashboard
Tools in this category install a dashboard on a WordPress site you host, then connect your other sites to it as children. MainWP and InfiniteWP are the established options. There is no per-site fee, your data sits on your own server, and the extension ecosystems are large.
The trade is that the dashboard is itself a WordPress site requiring hosting, patching, hardening, its own backups and occasional debugging. When it is down you lose visibility across every client at once. Monitoring that runs from your own server also inherits your server's blind spots: if your host has a routing problem, uptime checks can produce false alerts or miss real ones.
This is the right choice when you have server skills available, a large portfolio where per-site fees would be significant, or a contractual requirement that data sits on hardware you own.
A managed management platform
Hosted platforms connect your sites to infrastructure someone else runs. There is nothing to host or patch, monitoring runs independently of your hosting, and capability arrives without you installing extensions. You pay per site or per portfolio tier, and your data sits with the vendor.
This is the right choice when your team's time is worth more than the fee, when you want monitoring that survives your own hosting having a bad day, or when you need capability like verified update rollback that is hard to assemble from parts.
The honest summary
Self-hosted costs less money and more time. Managed costs more money and less time. Multisite costs less of both but only works when sites genuinely share a codebase. Which is right depends on your portfolio size and what an hour of your team's time is worth, and anyone who tells you there is a universal answer is selling something.
What to look for in a management tool
Every mature tool in this category does bulk updates, backups and a dashboard. Those are table stakes and comparing them tells you very little. The questions that actually differentiate products are these.
- What happens when an update breaks a site? Is there verification after the update and automatic rollback, or only a backup you restore by hand once someone notices?
- Have my backups ever been restored? Confirming a backup completed is not the same as knowing it works.
- Does it show portfolio patterns? When one plugin is vulnerable across eleven sites, is that one problem or eleven rows?
- Can I get my data out? Full export in a machine-readable format, on demand, without asking.
- How is site access authenticated, and can I revoke it independently from my side?
- What does it cost at my actual site count with the features I actually need, rather than the headline price?
Designing the workflow
The tool matters less than how you use it. A well-designed workflow on a mediocre tool beats a careless workflow on an excellent one, because most incidents come from process rather than software.
Batch by risk, not by convenience
The instinct with a management tool is to select all sites and update everything at once, because that is what the tool makes easy. It is also how one bad plugin release breaks forty client sites simultaneously.
Group sites into risk tiers instead. Low-risk sites — internal, staging, low-traffic brochure sites — go first. Watch for twenty-four hours. Then medium-risk client sites. Then high-value sites and stores, individually, in their own quiet windows. This costs almost no additional working time because the work is scheduled rather than performed, and it converts a portfolio-wide incident into a single-site one.
Verify, do not assume
An update that reports success has told you the files were replaced. It has not told you the site still works. The gap between those two things is where most maintenance incidents live, and closing it means checking after every change: does the page return a valid response, does it still look the same, do forms submit, does checkout complete.
Make backups provable
Take a restore point before every update rather than relying on last night's scheduled backup, and test restores on a schedule so backup status is evidence rather than assumption. A backup that has never been restored is a hypothesis.
Automate the routine, escalate the exception
The goal of automation is not to remove human judgement. It is to remove human attention from work that does not need it, so attention is available for work that does. Routine security patches on low-risk sites should run without anyone thinking about them. A rolled-back update on a client store should reach a person immediately.
Common mistakes
- Batch-updating stores alongside brochure sites, which concentrates revenue risk unnecessarily
- Treating a successful update as a working site, with no verification step at all
- Monitoring only for HTTP 200, which misses blank pages and broken checkouts entirely
- Using multisite to manage unrelated client sites because it looked simpler at the start
- Never testing a restore, then discovering the archive is incomplete during an incident
- Leaving the WordPress administrator email as an address nobody reads, so recovery messages go nowhere
- Choosing a tool on feature count rather than on what it does when something goes wrong
When to change approach
The signals that your current approach has stopped working are fairly consistent, and they show up before an incident does if you look for them.
- Maintenance regularly gets deferred because there is no time this week
- You cannot say how long a known vulnerability has been unpatched on client sites
- Nobody knows whether the backups would restore
- A client told you their site was down before your monitoring did
- Client reports are written from memory, or have quietly stopped
- Adding a site to the portfolio feels like adding work rather than adding revenue
That last one is the clearest signal. In a working setup, the marginal cost of an additional site should fall as the portfolio grows, because the process is the same and the automation is already built. If each new site feels like a proportional increase in workload, the approach rather than the effort is the problem.
Common questions
Around five is where manual management starts costing more than a tool. By fifteen it is difficult to justify not having one. Below five, a tool is often unnecessary overhead unless you specifically want verified update safety.
Usually not. Multisite couples sites together: shared codebase, shared database, shared failure domain. That is excellent for sites that genuinely belong together and a liability for independent client sites. Use a management tool instead.
Yes. Every management tool in this category except WPMU DEV's bundled offering is hosting-neutral and connects through a plugin, so a portfolio spread across eight hosts is normal.
Verification after updates. Most maintenance incidents are updates that reported success and broke something anyway. Adding a restore point, a post-update check and automatic rollback removes most of that risk without changing anything else about how you work.
No, and particularly not stores. Stagger by risk tier so a bad plugin release affects one low-risk site rather than the whole portfolio. It costs almost no extra working time because the updates are scheduled rather than watched.
Manage the portfolio, not each site
Risk-tiered update batching, verification after every change, and restore-tested backups across every site you look after.
Free during early access. No credit card required.