Multisite or Separate Installs? Managing 20+ Client Sites

Twenty client sites. Twenty sets of plugin updates, twenty backup configurations, twenty invoices from three different hosts, and one Tuesday morning where you realise nobody has logged into six of them since launch. At that point somebody on the team always says the same thing: should we just put everything on multisite?

Sometimes yes. Usually no. This post sets out when WordPress multisite for agencies genuinely reduces operational load, when it quietly creates a single point of failure across your whole client base, and what the realistic alternatives look like once you are managing more than twenty installs.

The question behind the question

Agencies almost never want multisite for its own sake. They want three things: one place to run updates, one bill instead of twenty, and one codebase so a fix applies everywhere. Multisite delivers all three. It also couples the fate of every site on it, which is the part that gets underweighted in the planning meeting.

So the real question is not technical. It is: how similar are these sites, and how independent do they need to be? Similar and dependent points to multisite. Different and independent points to separate installs with good tooling on top.

Where multisite is the right call

Multisite earns its complexity when the sites are variations of one thing rather than twenty unrelated businesses.

• Franchise and multi-location networks. One brand, one theme, per-location content. This is the case multisite was designed for.
• Universities, councils and large intranets. Many departmental sites, one identity system, central governance.
• Productised site offerings. If you sell a $200-per-month site on a fixed template to dozens of small businesses, per-site infrastructure destroys the margin.
• Language or regional variants of one site. Shared design system, separate content teams, shared plugin stack.
• Staging fleets and demo environments. Internal use, low risk, high convenience.

The common thread is a shared plugin and theme stack. If every site on the network needs the same twelve plugins and the same parent theme, network-wide management is a genuine saving. The general architecture is covered in more depth in the tutorial on WordPress multisite and scalable websites.

Where multisite goes wrong for agencies

The failure modes are predictable, and all of them are business problems rather than bugs.

• Shared blast radius. One bad plugin update, one PHP fatal, one compromised super admin account, and every client on the network is affected at once. Twenty separate incidents are annoying; one incident affecting twenty clients is a reputational event.
• Selling a site is painful. When a client leaves, or wants to move to their own hosting, you are exporting a subsite out of a shared database. It is doable and it is never a fifteen-minute job.
• Plugin compatibility. A meaningful minority of commercial plugins are not multisite-aware, and licensing is often priced per site anyway, which erases part of the saving.
• WooCommerce complexity. Each store needs its own tables, payment credentials and PCI-relevant configuration. Multiple stores on one network is a specialist build, not a default.
• Client isolation expectations. Some clients — and increasingly some procurement teams — will not accept sharing a database with unrelated companies. Read the MSA before you architect.
• Scaling ceilings. Networks with hundreds of subsites need careful database work, and the operations required stop looking like standard WordPress hosting.

Side by side

Factor	Multisite	Separate installs
Update effort	One pass for the whole network	Automated per site, needs tooling
Risk isolation	Poor — shared failure domain	Strong — problems stay local
Hosting cost	Lower per site at volume	Higher, but scales with revenue
Plugin licensing	Often still per site	Per site
Offboarding a client	Subsite export, several hours	Standard migration, well understood
Per-client customisation	Constrained by shared stack	Unlimited
Security blast radius	Network-wide	Single site
Best fit	Similar sites, one owner or one brand	Unrelated clients, varied builds

Read that table with your own client list in mind. If more than a third of your sites need something the network stack does not support, multisite will cost you more in exceptions than it saves in updates.

The middle path most agencies should take

For a portfolio of unrelated client sites, the winning setup is separate installs plus a management layer. You get isolation and per-client flexibility, and you remove the manual labour with tooling rather than architecture.

1. Standardise the stack. Decide on one caching plugin, one backup approach, one security plugin, one forms plugin. Variation is the actual cost driver, not the number of installs.
2. Consolidate hosting to one or two providers. Not for the discount — for the fact that your team learns one control panel and one support process.
3. Use a central management dashboard. ManageWP, MainWP, InfiniteWP or your host’s own multi-site console will run updates, backups and uptime checks across the portfolio from one screen.
4. Version-control the parts that matter. Themes and custom plugins in Git, deployed through a repeatable pipeline as described in our post on safe staging to production deployment.
5. Automate updates in two waves. Low-risk sites on Tuesday, revenue-critical sites on Thursday after the first wave has been checked. Visual regression screenshots before and after cost minutes and catch most breakage.
6. Keep a portfolio register. One row per site: host, stack, tier, backup location, renewal dates, key contacts. Everything else depends on this existing.

Done properly, twenty separate installs take roughly the same routine effort per month as a twenty-site network, without the shared failure domain. The effort moves from repetitive clicking to setup — which is a one-time cost, and one that outsources cleanly under WordPress maintenance and support.

If you do choose multisite, do these six things

• Decide subdomain versus subdirectory before launch. Changing later is a mapping exercise you will not enjoy.
• Restrict super admin access to two named people and use hardware-backed two-factor authentication for both.
• Test every plugin update on a staging clone of the entire network, not of one subsite.
• Back up per subsite as well as network-wide, so restoring one client does not mean rolling back nineteen others.
• Document the subsite export process before you need it, including domain mapping, uploads and user reassignment.
• Write the network’s plugin policy down and enforce it, because “just for this one client” is how networks become unmaintainable.

Also plan for exits from the start. Every client site should be portable within a working day. If it is not, you have built lock-in for yourself rather than for them, and it will surface at the worst possible moment. Our zero-downtime migration checklist is the process we use when a subsite has to move out.

The cost picture, honestly

Multisite saves hosting money at volume and saves update labour. It does not usually save plugin licensing, and it adds a category of risk that is hard to price until it happens. For a productised offering with thin margins, that trade is often worth taking. For a portfolio of $8,000 custom builds, it rarely is — the hosting delta is noise next to the cost of one network-wide outage.

The labour question is separate from the architecture question. If the real problem is that nobody has time to run maintenance across twenty sites, a monthly block of developer hours solves that regardless of which architecture you choose. Our dedicated monthly plans run from $699/mo for 15–20 hours to $3,599/mo for 100–120 hours, month to month, and the wider outsourcing model is explained in our guide to white label WordPress development for agencies.

Frequently asked questions

Is WordPress multisite for agencies a good idea in 2026?

It is a good idea for networks of similar sites under one brand or one owner, and a poor default for a portfolio of unrelated clients. Managed hosting and central dashboards have removed most of the labour advantage that once made multisite attractive for mixed client work.

How many sites before separate installs become unmanageable?

With no tooling, around ten. With a central management dashboard, a standardised stack and automated backups, several hundred is routine. The limiting factor is stack variation, not site count.

Can you run WooCommerce stores on multisite?

Yes, and it is supported, but each store carries its own tables, payment configuration and compliance surface. Unless the stores are near-identical, separate installs are simpler to build and far simpler to debug during a checkout incident.

How hard is it to move a subsite off a network later?

Expect several hours for a straightforward content site: export the subsite tables, remap uploads and URLs, reassign users, re-point the domain and re-test. It is predictable work, but it is never as quick as copying a standalone install.

Does multisite affect security?

It concentrates it. A compromise at network level reaches every subsite, so super admin accounts, plugin vetting and update discipline matter more than on a standalone install. The upside is that hardening once protects everything at once.

Deciding

Ask one question: if this network went down for four hours, how many client conversations would you be having? If the answer is one, multisite is fine. If it is twenty, buy the isolation.

If you want a second opinion on your specific portfolio before committing, send us the site list and stack and you will get a straight recommendation and a timeline back the same business day.