WordPress Multisite or Separate Installs: A Practical Decision Framework

The question usually arrives too late

Most organizations do not plan for multiple WordPress sites. They accumulate them. The main site was built five years ago, then marketing spun up a microsite for a campaign, then the German subsidiary needed its own blog, and now someone in IT is looking at four hosting bills, four sets of admin credentials and four update schedules. The next sentence is almost always: “Can’t we just put all of these into one WordPress multisite?”

Sometimes the answer is yes, and it genuinely improves operations. Sometimes multisite is the right idea applied to the wrong problem, and the organization ends up with a single system that is harder to run than the four separate ones it replaced. The difference between those outcomes is not technical skill — it is knowing what multisite actually changes under the hood, and being honest about which of those changes you want.

This article lays out how we evaluate that decision, grounded in how WordPress multisite actually behaves rather than in the feature list people imagine it has.

What multisite actually changes

WordPress multisite is a network feature built into core: one installation of WordPress, one database, one set of core files, hosting any number of virtual sites. When you enable it, the sites in the network are, as the official documentation puts it, virtual — they share the WordPress core files, the plugin directory and the theme directory, while each keeps its own database tables and its own media upload directory.

That one sentence contains most of the decision. Sharing core means one WordPress update patches every site at once. Sharing the plugin and theme directories means a plugin is installed once, at the network level, and individual sites can activate it but cannot install anything themselves. Individual site administrators get a scoped-down experience, and a Network Admin dashboard — which appears under My Sites once the network exists — becomes the place where software, updates and user roles are actually managed.

Two structural consequences are worth internalizing early. First, everything shares one hosting environment: one database server, one PHP process pool, one filesystem. A traffic spike on one site in the network is a spike on all of them. Second, the sites in a network are deliberately independent of each other. The WordPress documentation is blunt about this: if what you actually need is tightly interconnected sites that share data or users across sites, multisite may be the wrong tool. Multisite is centralized administration, not centralized content.

Where a network genuinely earns its keep

There is a cluster of scenarios where multisite is the clean answer, and they share a common shape: many sites with the same owner, the same operational standards, and the same software.

University departments are the classic case. A publisher running a portfolio of niche blogs. A company that needs a microsite per product line or per regional campaign, where every site follows the same brand guidelines and the same security baseline. In these situations the network model fits the org chart: there is one central team responsible for what software runs, and local teams responsible only for content.

The operational wins are real. One WordPress core update covers the entire network instead of twelve separate logins. A security decision — removing a compromised plugin, rotating salts after an incident, applying the kind of hardening measures we describe in our WordPress security checklist — is made once and applies everywhere. New sites can be provisioned in minutes without a new hosting account, a new database or a new deploy. When an organization is genuinely running ten or more sites to a single standard, that consolidation is worth a lot of real money, and it is the reason large networks are usually run this way rather than as a pile of independent installs.

If your situation looks like that, multisite deserves a serious look, and our WordPress development services page describes how we approach network architectures.

Where it bites

The problems start when multisite is adopted for reasons that sound similar but are structurally different.

Consolidating a small number of dissimilar sites. Three sites with different plugin stacks, different update tolerances and different owners do not become easier to manage inside one network. They become three sites that can no longer be updated, rolled back or debugged independently. A bad plugin update is no longer one site’s problem; it is every site’s problem at the same time. The blast radius of every software decision grows to the size of the network.

The subdirectory trap. WordPress restricts the network type you can choose, and the restrictions surprise people. On an installation that is more than one month old, you cannot choose a subdirectory-based network at all — the official documentation attributes this to permalink problems and notes it has been a known limitation for a long time. A subdomain-based network is unavailable if your WordPress URL contains a path rather than a bare domain, or if you are working on localhost. And if your WordPress address uses any port other than :80 or :443, you cannot create a network at all. These constraints mean the decision has to be made deliberately, early, with the hosting setup known — not retrofitted.

One-way doors. The choice between subdomains and subdirectories can theoretically be changed later, but the documentation warns that reconfiguring it might not be easy. The same caution applies to the whole architecture: merging separate installs into a network is a genuine migration project, and splitting a network back into independent installs is worse, because content, media paths and user accounts all need untangling. Treat “we can always change it later” as false comfort.

Plugin behavior under multisite. A plugin that works fine on a single site can behave differently in a network: some do not handle network activation at all, some store settings per-site when you expected network-wide, and some are simply never tested in multisite. Before committing, the plugin stack that matters to you should be tested in a network environment. This is the single most common source of regret we see.

Administration is no longer WordPress-as-usual. Themes and plugins are installed at the network level only. Site administrators cannot install their own. If your organization actually wanted site-level autonomy — local teams choosing their own tools — multisite takes that away, and the workaround is a constant flow of network-admin requests.

Small structural quirks with real consequences. In a path-based network, the main site’s posts get a /blog/ prefix in their URLs, and removing it requires configuration the documentation explicitly does not recommend. Custom domains on network sites need domain mapping on top of the network setup. For on-demand subdomain sites, wildcard DNS is required. None of these are dealbreakers alone; together they mean the network needs an administrator who understands the machinery, not someone who just knows the single-site WordPress dashboard.

The questions we actually ask

When a client asks us whether to consolidate, the conversation usually comes down to five questions.

Is there one owner and one set of standards? If yes, a network aligns with the governance. If the sites belong to different legal entities, brands or teams with conflicting requirements, separate installs keep the boundaries honest.

How much software do the sites genuinely share? High overlap in plugins and themes favors a network. Low overlap means you are paying the network’s complexity cost without collecting its main benefit.

Do the sites need to share content or users with each other? Counterintuitively, if the answer is yes, that argues against multisite, because sites in a network are deliberately independent. Cross-site data sharing in a network means custom development.

How many sites, and what trajectory? Consolidating three sites saves little; consolidating twenty saves an administrator. If the organization will plausibly spin up sites on demand, the network’s instant provisioning matters. If the count is stable and small, it does not.

Who runs it day to day? A network needs someone comfortable with the Network Admin layer, the htaccess or nginx rules multisite requires, and debugging that spans the network. If that person does not exist, the honest comparison is between independent installs and hiring or contracting that capability — which changes the cost equation considerably, in the same way hidden labor distorts the budgets we broke down in our article on website total cost of ownership.

The middle ground most organizations actually want

Frequently, the answer is neither. What the organization wanted was not “one WordPress” but “less repetitive work across several WordPresses” — and that problem has cheaper solutions than re-architecting.

Multiple independent installs can be run with shared tooling: a single maintenance schedule driven from the command line instead of twelve dashboards, which is exactly the workflow we describe in our guide to updating WordPress safely with WP-CLI. A managed host that supports staging and automated updates across sites removes most of the click-work that motivated consolidation in the first place. Backups and security monitoring can be centralized per server rather than per site.

This middle ground keeps the property that multisite gives up: each site can still be updated, rolled back, migrated or debugged on its own. For a portfolio of sites that are similar but not identical, that independence is usually worth more than the network’s elegance — a tradeoff that is really a specific case of the platform-selection principles in how to choose a CMS for a business.

Decide on structure, not enthusiasm

Multisite is a well-built feature for the problem it was designed for: many similar sites, one owner, one standard, centrally administered. It is a poor fit for what it is often asked to do: make dissimilar, independently governed sites “simpler” by welding them together.

The decision deserves the same rigor as a platform migration, because in practice it is one — a structural change to URLs, hosting, administration and update strategy, with one-way doors along the path. Ask the five questions above before touching a database, and if the answer points to a network, plan it deliberately: on a fresh install decision window, with wildcard DNS if subdomains are involved, with the plugin stack tested in a network environment first. If it points to independent installs with better tooling, that is not a lesser outcome. It is frequently the more resilient one.