If you run more than a handful of WordPress sites, you have probably stared at this fork in the road: do you bind them all into a single multisite network, or keep each one as its own standalone install? The marketing pitch for multisite is seductive — update once, log in once, manage everyone from a single dashboard. But multisite is an architecture decision, not a convenience feature, and the wrong call is painful to undo later. This guide walks through how the two models actually behave in production so you can match the architecture to your situation instead of the other way around.

What multisite actually is under the hood

WordPress Multisite is a mode you enable by adding define('WP_ALLOW_MULTISITE', true) and then define('MULTISITE', true) to wp-config.php. Once active, your single WordPress install spawns extra database tables — one set of wp_2_posts, wp_2_options, and so on per subsite — while sharing the global wp_users and wp_usermeta tables across the entire network. Every site runs on the same WordPress core files, the same PHP process, the same wp-content directory, and the same database. That sharing is the whole point, and also the whole risk.

You choose subdomains (brand.example.com) or subdirectories (example.com/brand) at setup, and that choice is effectively permanent. Mapping fully custom domains per subsite — clientsite.com instead of client.yournetwork.com — is built into core now (the old Domain Mapping plugin was merged into WordPress years ago), but it still means wildcard DNS and a wildcard or multi-domain SSL certificate, which not every shared host configures cleanly.

Where multisite genuinely wins

Multisite earns its keep when sites are operationally identical and centrally owned. The classic fits:

Franchise and chain rollouts — 40 location pages that all use one theme, one set of plugins, and one brand template. New location? Add a subsite in 30 seconds from a template.
Universities and large orgs — departmental sites where IT controls the stack and individual departments only touch content.
SaaS-style "site builder" products — products like the older WordPress.com model where each customer gets a subsite. This is what multisite was originally built for.
Language or regional variants of one brand that share design and roughly mirror content.

The concrete payoff is real: one core/plugin update propagates to every subsite at once, network-activated plugins are licensed and configured in a single place, and shared user accounts mean an editor logs in once to manage twelve properties. For a 50-site franchise network, that is hours of maintenance saved every month.

Where separate installs win

Separate installs win whenever the sites diverge — in stack, in ownership, in risk tolerance, or in lifecycle. Consider keeping them apart when:

The sites have different plugin needs. One needs WooCommerce and a heavy page builder; another is a lean blog. On multisite they share a plugin directory and PHP memory ceiling whether they like it or not.
Sites get bought, sold, or handed to clients. This is the big one. Extracting a single site out of a network is genuinely hard — more on that below.
One site is a revenue machine and the rest are brochureware. You don't want a runaway query on the marketing blog starving the store's database connections.
Different teams or agencies manage different sites. Multisite super-admins can touch everything; there is no clean per-site root boundary.

The failure-coupling problem nobody mentions in the sales pitch

This is the heart of the decision. Separate installs are bulkheaded — a disaster on one is contained to that one. Multisite couples failure modes that standalone sites keep independent:

A bad update breaks everyone simultaneously. Network-activate a plugin that throws a fatal on PHP 8.3 and all 40 sites white-screen at the same moment, not one.
Resource contention is shared. A crawler hammering one subsite's search, or a slow uncached query, consumes the same MySQL connection pool and PHP-FPM workers that every other subsite depends on.
The blast radius of a hack is the whole network. Compromise one subsite's theme and an attacker is already inside the shared filesystem and database where every other site lives. With separate installs — ideally separate hosting accounts — that lateral movement is much harder.
One PHP version, one MySQL config, for all. You cannot run subsite A on PHP 8.1 and subsite B on PHP 8.4. The network upgrades together or not at all.

For low-stakes brochure sites where an outage costs goodwill but not dollars, coupled risk is an acceptable trade for centralized management. For a portfolio where downtime has a measurable dollar figure per hour, failure isolation usually outweighs the management savings.

The exit cost: migrating a site out of a network

If there is one fact that should drive your decision, it is this: pulling a single site out of a multisite network is not a restore-from-backup operation. A standalone WordPress backup is a clean unit — copy the files, import the database, change the URL, done. A subsite is entangled in network-global tables and prefixed tables that a normal restore doesn't know how to separate.

The realistic tools are plugins built specifically for this: All-in-One WP Migration with its multisite extension, or WP Migrate (formerly WP Migrate DB Pro) which handles the table-prefix and serialized-URL rewriting. Even with the right tooling you are reconciling user IDs, rewriting serialized option data, and untangling wp_blogs references. Budget real time and test the extraction on a staging copy first. Going into multisite is a decision; coming back out is a project.

Operational details that bite later

Plugin licensing varies wildly. Some premium plugins (and many page builders) count every subsite as a separate activation; others sell a flat unlimited-network license. A 40-site network can turn a "cheap" plugin into a four-figure annual cost. Check the license terms before you commit to the architecture.
Backups work differently. A full-network backup is one enormous file containing every site. UpdraftPlus and managed hosts like WP Engine and Kinsta offer multisite-aware, per-subsite backup and restore; many cheaper backup plugins only do all-or-nothing. Verify per-site granularity exists before you rely on it.
Not every host supports multisite well. Subdirectory networks are easy; custom-domain networks need wildcard DNS plus SAN/wildcard SSL. Confirm your host (Cloudways, Kinsta, WP Engine, SiteGround) documents the exact setup you want.
Caching gets more complex. Network-wide object caching (Redis) and full-page caching must be configured so one subsite's purge doesn't nuke everyone's cache or, worse, leak cached content across sites.

A decision you can actually use

Strip away the elegance and the choice comes down to two questions. First: are these sites operationally the same animal — same theme family, same plugins, same team, same risk profile? If yes, multisite's leverage is real. Second: will any of these sites ever need to leave, scale independently, or fail without taking the others down? If yes, lean toward separate installs.

Two practical rules close it out. Don't migrate eight existing, already-configured standalone sites into multisite as a tidiness project — the effort is high and the payoff is marginal once each site has settled. Conversely, if you're spinning up eight new sites that will deliberately share a theme and plugin set, starting on multisite is sensible from day one because the hard-to-reverse decision is made before there's anything to untangle.

And remember the answer is rarely all-or-nothing. A common, durable pattern: run the dozen near-static franchise brochure sites on one multisite network, and keep the flagship corporate site and the revenue-critical WooCommerce store as their own isolated installs. Let the architecture follow the operational requirements — don't impose a uniform structure just because one dashboard sounds nicer than several.

WordPress Multisite vs Separate Installs: The Honest Comparison