Multisite or Separate Installs: Which Should You Run?
WordPress multisite is one core, one plugin set and one blast radius for every site on it. Most teams should run separate installs. Two situations make it the honest answer.
On This Page
The request usually arrives phrased as a tidying exercise. Nine WordPress sites, nine update cycles, nine sets of logins, nine invoices. Somebody suggests a network, and on the whiteboard it looks obviously correct: one install, one update, one place to look. Then you ask what happens the day one of those nine needs a plugin the other eight cannot run, and the whiteboard goes quiet.
Our position, stated plainly: WordPress multisite is a commitment most teams should refuse. Not because it is badly built. It has been in core for years, it is well engineered, and it does exactly what it advertises. The trouble is that what it advertises includes a shared failure surface, and teams evaluate the sharing without ever pricing the failure.
There are two situations where a network is the honest answer, and we will get to both. Everywhere else, separate installs with a little shared tooling buy you the same tidiness at a far smaller radius of damage. The difference only becomes visible on a bad day, which is why it is so easy to argue away on a good one.
What WordPress multisite actually shares
Multisite is a mode, not a product. Switching it on turns one installation into a network of sites that share the same files and the same database, with per-site tables sitting alongside a shared set. That single sentence contains the whole trade, and it is worth being specific about which things are shared.
- One codebase. Core, themes and plugins exist once on disk. A site cannot run a different version of a plugin from the rest of the network, because there is only one copy of it.
- One update event. When core or a plugin updates, every site takes it at the same instant. No staggering, no canary site, no property that waits a week while you watch the others.
- One user table. Accounts are network-wide and granted roles per site. Convenient, until you consider how far a single super admin credential reaches.
- One database. Per-site tables are namespaced, but they share a server, a connection pool and a backup regime. Restoring one site alone is fiddly without extra tooling.
- One environment. One PHP version, one set of server limits, one caching layer, and one place where a resource problem becomes everybody’s resource problem at once.
- One admin surface. Network administration is a real skill, and it is not the same skill as running a single WordPress site well. Somebody has to hold it.
What a network does not share, by default, is content. Each site keeps its own posts, pages, options and uploads. That is the part everybody expects, and it is the least interesting part of the arrangement, because content sharing is the thing most teams actually wanted when they asked about a network in the first place.
The case for shared updates, taken seriously
The strongest argument for a network is maintenance arithmetic. Nine sites means nine update cycles, nine plugin inventories, nine security postures and nine chances to forget one. A network makes that one of each. Anyone who has inherited an estate where two sites are several major versions behind will feel the appeal immediately, and they are right to.
The arithmetic is honest as far as it goes. What it leaves out is that a single update event is also a single point of failure. A plugin release that breaks a template breaks it everywhere, simultaneously, at whatever moment you pressed the button. Staged rollouts are the standard answer to that problem in every other part of software delivery, and a network removes the option by design.
There is a quieter cost too. A network converges on the union of every site’s requirements, because a plugin one site needs must be installed for all of them. The install grows, the attack surface grows with it, and the argument about how many plugins is too many becomes far harder to win, because nobody can point at a plugin and name the single site that depends on it.
Isolation, and the size of a bad day
This is the section that settles the argument for us. The phrase to hold on to is blast radius: how much goes down when one thing goes wrong. Everything else in this comparison is a preference. This one is arithmetic you cannot argue with once it happens.
One bad plugin
A fatal error in an active network plugin is a network-wide outage. So is a PHP version bump the network cannot take, a corrupted core file, or a change to a shared parent theme that one site depended on in a way nobody documented. On separate installs the same fault takes one site down while the others keep publishing, selling and answering forms.
Themes deserve their own warning. A network almost always ends up with a shared parent and per-site children, which is elegant right until the parent needs a change that only two sites want. We have written about when a theme becomes a liability; inside a network that liability is multiplied by the number of sites, and it cannot be unwound one site at a time.
One compromised account
Security is worse than most teams assume, and not because multisite is insecure. The code is the same code. The difference is that a super admin credential is a key to every site on the network, and privileged accounts accumulate quietly: an agency, a former developer, a plugin that asked for elevated access years ago and never gave it back. On separate installs a stolen credential is a bad day for one property. On a network it is a bad day for the portfolio.
The mitigations are the ordinary ones, and they matter more here than anywhere: fewer privileged accounts, enforced two-factor authentication, file editing disabled, and a written answer to what happens at three in the morning. Our notes on hardening WordPress apply as written, and so does the harder question of preparing for the day you are compromised, because on a network the recovery plan has to cover sites that were never targeted at all.
One shared resource pool
Performance is shared as well. One site running an expensive query, an unindexed meta lookup or a badly behaved scheduled task spends capacity every other site needs. The diagnosis is the usual one, and we have set it out in why WordPress is slow and which fixes move the numbers. What changes on a network is attribution: the site showing the symptom is frequently not the site causing it, and working out which one is costs hours nobody planned for.
If one site on this network has an outage caused by another site on this network, who explains it, and to whom? When the sites belong to different clients, different business units or different budgets, that conversation is expensive, and it will happen more than once.
The migration nobody prices
Getting a site into a network is straightforward. Getting one out is not, and this is the cost that never appears in the plan, because it is always somebody else’s future problem.
A standalone install is a directory and a database, and moving it is essentially a copy. A site inside a network is a set of prefixed tables, rows in a shared users table, an uploads directory nested under a numeric site identifier, and options that point at network-level values. Extraction means exporting, importing into a fresh install, remapping accounts, relocating media, reconfiguring plugins that stored network settings, and auditing every internal URL the network was quietly rewriting on your behalf.
None of that is exotic. All of it is work, and it lands at the worst possible moment, because sites usually leave a network when a commercial relationship changes and somebody wants their property back this quarter. The same discipline that makes a website migration hold, chiefly a URL inventory and a redirect map, is what makes an extraction survivable. Build both while nobody is asking for them.
Enabling multisite is reversible in theory and a migration in practice. Decide as though you cannot undo it, because by the time you want to, you will have sites, accounts, media paths and plugin settings arranged the network’s way rather than yours.
The comparison that matters
Feature lists will not settle this, because both arrangements run the same software. These are the differences that show up in the second year, when the estate has grown and the person who set it up has moved on.
| Concern | Multisite network | Separate installs |
|---|---|---|
| Core and plugin updates | One action, every site at once | Per site, stageable or automated |
| A fatal plugin error | Network-wide by default | Contained to one site |
| A stolen admin credential | Super admin reaches every site | Reaches one site |
| Plugin choice per site | Constrained by the network | Free, per site |
| PHP version per site | Identical for all | Independent |
| Database | Shared server and backup regime | Independent per site |
| Restoring one site | Selective, and fiddly | An ordinary restore |
| Moving one site out | Export, remap, re-audit URLs | Copy files and database |
| Creating a new site | Minutes, from a template | A provisioning job you own |
| Skill required | Network administration | Ordinary WordPress operations |
The two cases where a network is right
We said there were two. Here they are, and notice what they share: in both, the sites are not really separate businesses.
One owner, many near-identical sites
A university with departmental sites. A franchise with location sites. A membership body with chapter sites. Same brand, same template, same governance, same group deciding what a plugin is allowed to be. Here the shared codebase is not a compromise, it is the requirement, and the fact that a network makes drift structurally difficult is the entire point. You want every site to be the same, and you want it to stay that way without anybody policing it.
Many short-lived sites from one template
Campaign microsites, event sites, course sites, internal sandboxes. Creating one should take a minute and cost nothing, and its whole life is measured in months. Nobody will ever extract one, because nobody will want one after it ends. Networks are genuinely good at this, and building the same capability across separate installs means writing and maintaining provisioning tooling you would probably rather not own.
Both cases assume two things: no site will ever need its own plugin set, and no site will ever need to leave. If either is false for even one site on your list, the case collapses, because the cost lives entirely in the exception. Sites that need genuinely different design and build decisions need different installs, and that is usually obvious long before anyone writes it down.
What to run instead, and how to keep the tidiness
Share the tooling, not the install
Separate installs do not have to mean separate everything, and this is where the multisite argument usually goes wrong. The maintenance arithmetic is solvable without a network: a management layer that applies updates across sites, a shared deployment pipeline, one backup and monitoring policy, and a plugin allowlist enforced by review rather than by the filesystem. Updates then run per site, which means they can be staged, which means a bad release stops at the first site instead of the last. That is what a website maintenance arrangement should look like once it covers more than one property. It costs more to set up than switching a flag, and much less in the year somebody wants a site moved.
If the real motive is content
The other reason people reach for a network is publishing: one editorial team, several sites, and a wish to write something once. That is a content problem wearing a hosting costume. A network will not solve it. You get a shared users table, not shared content, and editors still end up copying posts between sites by hand while wondering what the network was for.
A content layer solves it properly. That can be a shared endpoint each site reads from, or a workspace that publishes to several targets: a structured content workspace such as Acrosite generates the required files, commits them to GitHub and triggers the configured deployment, which turns publishing to three sites into a routing decision rather than a hosting arrangement. Shared content and shared infrastructure are different problems, and solving the first with the second is how estates get stuck.
Multi-brand estates feel this most, because the sites are supposed to look different. Our parent company has written about the sequencing in when brand and build run together, and the practical version fits in a line: shared infrastructure suits sites that are meant to be the same, and punishes sites that are meant to differ.
How to decide, in order
Answer these honestly and in sequence. Most teams stop at question two.
- Will any site ever need a plugin the others cannot have? Not today, ever. One yes rules out a network, because the workaround is a conditional load that nobody will maintain after the person who wrote it leaves.
- Will any site ever leave? Sold, spun out, handed back to a client, moved to another agency. If that is plausible, price the extraction now and set it against the maintenance you were trying to save.
- Do the sites share governance? One group deciding what is allowed, one approval path, one security policy. Different owners with different appetites do not belong on shared infrastructure.
- Can you tolerate a simultaneous outage? An update goes wrong and every site is down together. If that sentence needs a stakeholder meeting before you can answer it, you already have your answer.
- Who runs the network? Not who holds the password. Who understands super admin hygiene, domain mapping, per-site backups and network updates, and will still be around in two years.
- Is the real problem content? If the motivation is publishing once to several sites, fix it in the content layer and leave the hosting alone. That reframing dissolves a good half of these projects.
Multisite is not a convenience. It is an agreement that every site updates on the same day, at the same version, carrying the same risk.
If you are already running a network
If you already run one and this reads as an indictment, it is not. Plenty of networks run well for years, and rebuilding a working estate to satisfy an article is a poor use of a budget. The useful question is not whether to dismantle it. It is whether you could dismantle it if you had to.
So run the drill. Pick the site most likely to leave and extract it into a standalone install on staging. Time it. Write down everything that broke: the media paths, the user accounts, the plugin holding network-level options, the internal links that were being rewritten for you. What you end up with is an extraction runbook and a real number, and both are worth considerably more than an opinion about architecture.
The second habit worth adopting is a named owner per site. A network without per-site ownership drifts into a shared responsibility that nobody actually holds, and that is the state in which a plugin nobody remembers installing becomes everybody’s problem on a Tuesday morning. If you are weighing a network against separate installs for a specific estate, send us the list of sites and what each one is for.
Common questions.
What is WordPress multisite?
WordPress multisite is a mode in WordPress core that turns one installation into a network of sites sharing the same files, the same database server and the same user table. Each site keeps its own posts, pages, options and uploads, but core, themes and plugins exist once on disk. Updates apply to every site at the same moment, and a network administrator role sits above the individual site administrators.
Is multisite more secure than separate WordPress installs?
No, and in one specific way it concentrates risk. The code is the same code, so the underlying posture is comparable, but a super admin credential on a network reaches every site on it. On separate installs a stolen credential compromises a single property. Networks therefore need fewer privileged accounts, enforced two-factor authentication, and a recovery plan covering sites nobody attacked directly.
Can you move one site out of a WordPress multisite network?
Yes, but it is a migration rather than a copy. You export the site, import it into a fresh installation, remap accounts out of the shared users table, relocate media from the network uploads structure, reconfigure plugins that stored network-level options, and audit internal URLs the network was rewriting. Rehearse the extraction on staging before a commercial deadline forces you to do it quickly.
How many sites do you need before multisite makes sense?
Site count is the wrong test. What matters is whether every site can run the same plugin set, whether any site will ever need to leave, and whether one group governs all of them. Two near-identical location sites under a single owner suit a network better than twenty unrelated client sites do, because the cost lives in the exceptions rather than in the quantity.
Can each site in a multisite network use different plugins?
Plugins can be activated per site, but they must be installed once for the whole network, so every site carries the code even when it is inactive. You cannot run two versions of the same plugin on different sites, and no site can use a plugin the network administrator has not installed. Over time a network converges on the combined requirements of every site on it.
What is the alternative to multisite for managing many WordPress sites?
Separate installs combined with shared tooling. A management layer applies updates across the estate, a shared deployment pipeline handles releases, and one policy covers backups, monitoring and allowed plugins. Updates then run per site, so they can be staged and a bad release stops at the first site. Setup costs more than enabling a network; extraction later costs far less.
Does multisite affect SEO?
Not directly. Each site in a network keeps its own URLs, titles, canonical tags and sitemap, and search engines treat sites on separate domains as separate sites. What can affect search performance is the shared infrastructure underneath: a slow query on one site consumes capacity every site needs, and a network-wide outage takes every property offline at the same time.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.