Multisite is one of the most misunderstood features in WordPress. It is not a plugin, not a separate product, and not automatically the right answer for “I have several sites.” It is a mode built into WordPress core that lets one installation run many sites from one database and one codebase. That sharing is the whole appeal, and it is also where the complications start.
Before you convert a client’s sites or start a new agency network, it helps to know exactly what multisite shares, what stays separate, and where the tradeoffs bite in real operation.
What Multisite Actually Shares
A WordPress multisite network is one instance of WordPress core, one set of themes and plugins on disk, and one database (with separate table prefixes per site, like wp_2_posts alongside wp_posts). Every site in the network draws from the same codebase.
- Core and plugin files. Update WordPress or a plugin once, and every site on the network gets the update at the same time. There is no drift between sites running different plugin versions.
- User accounts. A user created at the network level can be given access to any number of sites without creating duplicate logins.
- Server resources. One PHP process pool, one OPcache, one Redis or Memcached object cache, one set of LiteSpeed Cache rules. Efficient in theory, since PHP 8.3 with OPcache and a persistent object cache serve all the sites from the same warmed-up cache rather than each site paying its own cold-start cost.
- Network-level settings. Things like user registration policy, allowed file upload types, and network admin permissions are set once and apply everywhere (unless a site admin overrides what they are permitted to).
What Gets Complicated
The same sharing that makes multisite efficient also removes isolation, and isolation is often what you actually wanted.
Plugins Are All-or-Nothing (Mostly)
Every plugin lives in one shared wp-content/plugins folder. A network admin can activate a plugin network-wide or leave it activatable per site, but the plugin files themselves are identical for everyone. If one client on the network needs an older version of a plugin for compatibility reasons while another needs the latest, multisite cannot serve both from the same install. You would need a code-level workaround or, more realistically, a separate installation for that site.
One Vulnerability, Every Site
Because all sites share the same core and plugin files, a security issue in one plugin exposes every site on the network, not just the one using it. A single compromised plugin, a leaked admin credential, or a misconfigured upload permission can become a network-wide incident instead of an isolated one. Separate installs contain the blast radius; multisite concentrates it.
Backups and Restores Are Coarser
A full network backup captures the whole database and file set. Restoring means restoring everything, including sites that were never affected. If Site A gets corrupted content and you want to roll back to yesterday, you cannot restore just Site A’s tables without careful surgical work, because a network-wide restore also rewinds Site B, C, and D. Standalone installs let you back up and restore one site at a time without touching anything else.
Performance Isolation Disappears
One site with a runaway plugin, a bad cron job, or a traffic spike can slow down PHP processing for the entire network, since all sites share the same PHP-FPM pool and OPcache. A traffic surge on one site can degrade Core Web Vitals for every other site sharing that network, from LCP to INP, even though those sites did nothing differently.
Domains: Subdomains, Subdirectories, and Mapped Domains
Multisite networks are set up in one of two structures at creation time, and this choice cannot easily be changed later:
- Subdomains (
site1.example.com,site2.example.com), which requires wildcard DNS and, in most cases, a wildcard SSL certificate. - Subdirectories (
example.com/site1,example.com/site2), simpler to set up since it uses the existing domain and certificate.
Domain mapping lets individual sites in the network use entirely custom domains instead of the network’s base domain, which is common for agencies running client sites on one network. This works well with a Cloudflare setup in front of the network, since Cloudflare handles Universal SSL and edge caching per hostname regardless of which site on the backend serves the request. Just remember that a WAF rule, bot rule, or cache rule applied at the network’s origin level still governs every mapped domain equally. Individual clients cannot get their own custom security posture without extra work at the edge layer.
When Multisite Wins
Multisite earns its complexity in a few specific situations:
- A single organization running many similar sites (franchise locations, university departments, regional versions of one brand) that genuinely want the same plugins, the same theme, and centralized control.
- An agency that wants one place to push core and plugin updates across a portfolio of nearly identical client sites, accepting that a shared vulnerability is a shared risk they are actively managing.
- Large membership or community networks where users move between sites and a single login system is a real feature, not just a convenience.
When Separate Installs Win
Separate WordPress installs are usually the better default, especially when:
- Clients or business units need different plugins, different versions, or different update schedules.
- Isolation matters for security or compliance, and one compromised site must never touch another’s data.
- Sites have very different traffic patterns, and you do not want one site’s spike degrading another’s performance.
- Backup and restore need to happen on a per-site basis without network-wide side effects.
Managing many separate installs is where wp-cli earns its keep, since scripting updates, backups, and plugin activation across a fleet of standalone sites removes most of the manual overhead that made multisite attractive in the first place.
Making the Decision
The real question is not “how many sites do I have” but “how much do these sites need to be identical, and how much damage is acceptable if one goes wrong.” If the answer is “very identical, low individual risk tolerance is fine because it’s all one team,” multisite is a legitimate, efficient choice. If the answer involves different clients, different risk profiles, or sites that need to evolve independently, separate installs managed with good tooling will save you more headaches than multisite ever creates convenience.
Takeaway
Multisite is a genuine feature for genuine use cases, not a shortcut for managing unrelated sites under one roof. Know what it shares (code, users, resources) and what it complicates (plugin flexibility, security isolation, granular backups) before committing, since the domain structure and database layout are hard to unwind once real content and clients depend on them.