WordPress Multisite: When It Helps and When It Hurts

Multisite is one of the most misunderstood features in WordPress: pitched as a free way to run many sites from one dashboard, adopted for convenience, and then discovered to be an architectural commitment with sharp edges. We have built networks that were exactly right, and we have been called in to dismantle networks that should never have existed. The difference is rarely technical skill; it is whether the sites genuinely belong together, and that deserves a clear-eyed look before anyone runs the network setup screen.

What multisite actually is

A network is one WordPress codebase, one database and one user table serving many sites, each with its own content tables, domain or path, and settings. Plugins and themes are installed once at network level and activated per site; users exist once and hold roles on whichever sites need them. That single sentence contains both the entire appeal and most of the risk: everything important is shared. Domain mapping is native these days, so a network can serve entirely unrelated-looking domains from one install, which is exactly what makes it tempting for agencies.

Where it genuinely helps

• Many sites with one owner and one standard: university departments, franchise branches, regional editions of the same publication.
• Shared logins as a feature: staff who need access across dozens of sites without dozens of accounts.
• Operational leverage: one update, one deployment and one security review covering fifty sites instead of fifty of each.
• Fast provisioning: spinning up a new branch site from a template in minutes, not days.

Multisite is a governance decision wearing a technical costume. If the sites share an owner and a standard, it shines; if they merely share a server, it chafes.

Where it hurts

Everything shared is shared in failure too. A performance problem, a compromised plugin or a botched upgrade touches every site at once, and maintenance windows must suit everyone simultaneously. Plugin compatibility is a persistent tax, because a meaningful minority of plugins handle multisite badly or not at all. Backing up or restoring a single site from a shared database is awkward at exactly the moment you least want awkward. And the one everybody underestimates: extracting a site from a network later, for a sale, a rebrand or a divorce of teams, is a genuine migration project, not an export button.

There is also a quieter organisational failure mode. Networks built for clients with unrelated sites drift into trouble the first time one client needs a plugin, a PHP version or a compliance posture the others cannot share. Separate installs with good automation would have cost slightly more per site and removed the coupling entirely.

Scale adds its own texture. Very large networks need care around the shared tables every site touches, reporting across sites is not native, and admin tooling built for one site often behaves oddly at network level. None of this is unsolvable, but each solution is bespoke, and bespoke is the opposite of what most people wanted from multisite in the first place.

The questions that decide it

Do all the sites answer to the same owner, on the same standards, on the same release cadence? Will any site plausibly need to leave? Does every plugin in the expected stack support multisite properly? And is the alternative actually worse? Modern tooling narrows multisite's old advantage: WP-CLI, configuration management and hosts with multi-install automation deliver one-command updates across a fleet of independent sites, keeping the leverage while dropping the coupling. If the honest answers still point at a network, multisite is mature, well-supported and excellent at its job. It simply insists you mean it. And if the ownership question cannot be answered crisply, that is itself the answer.

Weighing a network against a fleet of separate installs is a judgement call with long consequences, and it is one STRCLI is always happy to think through with you.