A client once asked us to manage five country sites for their industrial brand. They were five separate WordPress installs, five plugin stacks, five update calendars, and one marketing manager doing her best. Multisite was the obvious answer — except it was not, for reasons worth explaining, because Multisite decisions get made on the wrong criteria.
When Multisite is the right call
- Same plugins, same team. Country or product sites sharing 90% of the stack, maintained by one team.
- Unified brand, separated content. Marketing wants per-country sites that share design and components.
- Compliance boundaries. Data residency or per-region legal pages that must not mix.
In those cases Multisite turns five update nights into one. Plugin licensing often improves too — many premium plugins price per network rather than per site.
When it is the wrong call
- Sites with different stakeholders. If each country office has its own agency, Multisite becomes a permission negotiation. Agencies want admin access; network admins resist. We watched this dynamic stall a product launch for six weeks.
- Different plugin needs. One site needs e-commerce, others do not. Multisite shares the plugin directory, and plugin bloat accumulates network-wide.
- One site is critical. A misconfigured network-wide update can take down the whole family at once. Separate installs fail separately.
The maintenance math
Multisite consolidates updates but concentrates risk, and it complicates hosting (single codebase needs capacity for the busiest site). Backups get heavier. Staging one site means staging considerations for all. We quote Multisite maintenance as roughly 60% of managing the same sites separately — a saving, but not the 90% people imagine.
Migration is a one-way door
Extracting a site from a network later is genuinely painful: database table surgery, URL rewrites, plugin re-licensing. Going in is easy; coming out is a project. Decide with that asymmetry in mind. If a split is plausible within two years (divestiture, rebrand), stay separate. For migration mechanics between separate installs, our site migration checklist covers the process.
Our practical rule
Multisite when sites are siblings (same brand, same team, same stack). Separate installs when sites are cousins. If you are unsure which yours are, write down who administers each site and who pays for it — the answer usually falls out of that list. If performance across the network worries you, the free audit benchmarks it before you commit. And for single-site speed problems in a family of installs, the slow-theme guide still applies per site.
Yes, by design — one user table across the network. That is convenient for internal teams and a problem when sites belong to different organizations. Yes — each network site can activate any theme installed on the network. Sharing one theme family is where the maintenance savings come from. Somewhat: one codebase serves all sites, so capacity must fit the busiest one, and staging affects the whole network. Most managed hosts support it, but confirm limits first. Technically yes, but it is a real migration project: separating database tables, rewriting URLs, and re-licensing plugins. Plan exits before entering.Does WordPress Multisite share users across sites?
Can each Multisite site have its own theme?
Is Multisite harder to host?
Can I move a site out of a Multisite network later?
