WordPress Multisite lets a single WordPress installation run a network of sites sharing one codebase and database. It's genuinely useful for the right use case, and a source of ongoing pain when used as a general-purpose "manage lots of sites" solution.
What multisite actually is
One WordPress core install, one set of plugins/themes (activated per-site or network-wide), and one database — with each site's content separated by table prefix. Sites can share users, media (optionally), and plugin/theme code, all administered from a single network dashboard.
Where multisite genuinely fits
- A network of related sites under common ownership and branding — a university with per-department sites, a media company with multiple regional editions, a franchise with per-location sites that share the same design and plugin set.
- You need centralized control over which plugins/themes are available network-wide, with one place to push core/plugin updates across every site at once.
- The sites are similar enough that sharing a codebase is a feature, not a constraint — divergent per-site customization fights against multisite's model.
Where multisite causes more problems than it solves
- Managing unrelated client sites for an agency. This is the most common multisite misuse — using it purely to reduce hosting/admin overhead across clients who have nothing in common. A single compromised site on the network can expose the entire install (core files and the database are shared), and a client wanting to leave means an actual site export/migration, not just closing an account.
- Sites need different plugin versions or conflicting plugins. Multisite shares the codebase; if Client A needs Plugin X v2 and Client B needs it frozen at v1, you're stuck.
- You need per-site custom PHP tweaks.
mu-pluginsand per-site theme functions help, but anything requiring genuinely divergent server-level configuration (different PHP versions, different resource limits) doesn't fit the shared-install model. - Scaling to very high traffic on one site in the network. A traffic spike or attack against one site consumes shared server resources for every other site on the network — there's no isolation.
The security and blast-radius consideration
This is the point most worth taking seriously: multisite means one WordPress core vulnerability, one compromised plugin, or one compromised admin account is a potential foothold into every site on the network, not just one. For unrelated sites (especially different clients' businesses), that shared blast radius is usually not an acceptable trade for the convenience.
The alternative: separate installs, centralized management tooling
For "I manage many WordPress sites" without the "they're actually one network" property, the better fit is usually separate WordPress installs per site, managed through a fleet-management tool or hosting platform's dashboard rather than through shared code. You get the same centralized visibility and bulk-update convenience without the shared database, shared codebase, or shared security blast radius.
The takeaway
Ask "are these actually one network of related sites, or am I just trying to manage many separate sites conveniently?" Multisite is the right answer to the first question and the wrong answer to the second — where a proper fleet-management workflow on separate installs almost always serves you better.
