A client came to me two years into running a WordPress Multisite network they had built themselves. Twelve sites across the network, all for different regional franchise locations. The setup looked clean on paper. One codebase, one server, centralized admin. Six months after launch, one site got hit with a traffic spike during a promotion. The entire network crawled to a halt. Every other location’s site went with it. Their network admin had also installed a caching plugin that worked perfectly for one site and quietly broke functionality on three others — because plugin activation worked differently across the network and nobody had accounted for it. They wanted to know how to fix it. The real answer was that they had built the wrong architecture from the start.
WordPress Multisite is one of those features that sounds like an obvious win until you’re the one maintaining it at 11pm on a Friday. This post is the guide I wish existed when I started working with multisite networks — the one that tells you clearly when it’s the right tool and when you’re about to make an expensive mistake.
What WordPress Multisite Actually Is
Multisite is a feature built into WordPress core that lets you run a network of separate sites from a single WordPress installation. All sites share the same codebase — the same wp-admin, the same wp-includes, the same theme and plugin files on disk. What differs is the data.
When you enable multisite, WordPress restructures the database. Instead of a single set of tables, each new site in the network gets its own prefixed table set. Site ID 2 gets wp_2_posts, wp_2_postmeta, wp_2_options, wp_2_terms, and so on. The root site keeps the original wp_posts structure. A few tables — wp_users and wp_usermeta — are shared across the entire network. That shared user table is one of the first things that causes real headaches, which we’ll get to.
You can run multisite in two modes: subdomain (site1.example.com, site2.example.com) or subdirectory (example.com/site1, example.com/site2). With domain mapping — either via a plugin or the built-in sunrise.php approach — you can also point entirely separate domains at individual sites in the network.
Enabling Multisite: The wp-config.php Side
Enabling multisite starts in wp-config.php. You add one constant before the line that says “That’s all, stop editing!”:
/* Enable WordPress Multisite */
define( 'WP_ALLOW_MULTISITE', true );After running through the Network Setup screen in wp-admin, WordPress generates a second set of constants and rules to paste into wp-config.php and .htaccess (or nginx.conf if you’re not on Apache). The full config block looks something like this:
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false ); // true for subdomain mode
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
/* Optional but useful constants */
define( 'SUNRISE', true ); // required for domain mapping via sunrise.php
define( 'WP_DEBUG', false );
define( 'NOBLOGREDIRECT', 'https://example.com' ); // redirect unknown domainsThat’s the easy part. The architecture decisions that come after are where things get complicated.
The Plugin Activation Model (And Why It Trips Everyone Up)
In a standard WordPress install, any administrator can activate a plugin. In multisite, there are two entirely separate activation contexts: network activation and site activation.
A network-activated plugin runs across every site in the network. Individual site administrators cannot deactivate it — only the network admin (super admin) can. This sounds useful for things like security plugins or shared functionality, but it means a plugin bug affects every site simultaneously. No isolation.
Site activation is closer to normal WordPress behavior — a plugin is active only on that specific site. But many plugins aren’t coded with multisite in mind. They assume a single database structure, write directly to wp_options without accounting for per-site prefixes, or create global database tables that stomp on each other when the plugin is active on multiple sites. Plugins that store data in the uploads directory sometimes collide. Licensing plugins — the kind that verify a license key against an API — often only account for one activation domain and start rejecting others.
The practical result: before installing any plugin on a multisite network, you need to audit it specifically for multisite compatibility. Most plugin authors don’t document this clearly, and the only reliable way to find out is to test it carefully in a staging environment or read the source code yourself.
Switching Between Sites Programmatically
One legitimate advantage of multisite is being able to write code that operates across multiple sites from a single context. WordPress provides switch_to_blog() for this:
<?php
// Switch to site with ID 3
switch_to_blog( 3 );
// Now wp_query, get_option(), etc. operate against site 3's data
$recent_posts = get_posts( array(
'numberposts' => 5,
'post_status' => 'publish',
) );
// Always restore the current site when done
restore_current_blog();
?>This is powerful for building dashboards, cross-site reporting, or aggregating content from across a network. But there are real costs. Each switch_to_blog() call resets a significant amount of WordPress’s global state. Inside tight loops over large networks, the performance impact adds up fast. Running a query across 50 sites by looping through switch_to_blog() calls is not a substitute for a properly structured direct database query.
For true cross-network queries, you’ll sometimes need to query the database directly using the $wpdb object with explicit table prefixes:
<?php
global $wpdb;
// Get the most recent post from every site in the network
$sites = get_sites( array( 'number' => 100 ) );
$results = array();
foreach ( $sites as $site ) {
$prefix = $wpdb->get_blog_prefix( $site->blog_id );
$post = $wpdb->get_row(
$wpdb->prepare(
"SELECT ID, post_title, post_date
FROM {$prefix}posts
WHERE post_status = 'publish'
AND post_type = 'post'
ORDER BY post_date DESC
LIMIT 1"
)
);
if ( $post ) {
$results[] = array(
'site_id' => $site->blog_id,
'post' => $post,
);
}
}
?>Code like this is maintainable when you have five sites. At fifty sites, you need to be thinking carefully about caching, query optimization, and whether this architecture still makes sense.
When Multisite Actually Makes Sense
There are real use cases where multisite is the right answer. The pattern they share: multiple sites that are meaningfully related, managed by a central team, running the same or similar functionality.
University or Large Organization Departments
A university where central IT manages the WordPress installation, themes are standardized, and each department gets its own site within the network is close to the ideal multisite scenario. The plugin set is controlled centrally, updates are applied once and propagate everywhere, and department editors only ever see their own site’s content. The shared user table works in their favor — a staff member can have appropriate roles on multiple department sites without maintaining separate accounts.
Franchise or Multi-Location Businesses
This works when the locations share the same theme, the same feature set, and the same basic content structure — and when someone central is responsible for the network. A franchise where head office controls the design and functionality, and local managers only update their hours and location-specific content, is a reasonable multisite candidate. Where it breaks down is when individual locations start wanting different plugins, different designs, or different checkout flows. That’s when you’re fighting the architecture.
Agency White-Label Networks
Some agencies run all their clients on a single multisite network. If the client base is homogeneous — similar site types, similar plugin needs, similar traffic patterns — this can reduce overhead significantly. One set of core updates to apply, one server to manage, standardized tooling. It only works if you’re willing to enforce strict constraints on what clients can and cannot customize. The moment one client needs something the others don’t, you’re building workarounds.
When Multisite Is the Wrong Choice
Multisite is overused. A large portion of the networks I’ve seen in production should have been separate WordPress installs. The people who built them chose multisite because it sounded efficient, and they’re still dealing with the consequences.
Unrelated Sites with Different Purposes
If the sites don’t share a common function, audience, or management team, they should not be on the same network. Putting a WooCommerce store, a blog, and a membership site together on one multisite network because they belong to the same company is not architecture — it’s convenience that becomes a liability. Their plugin needs will differ. Their performance profiles will differ. A problem on one will affect the others.
Sites with Different Plugin Requirements
This is where multisite fails most visibly in practice. Plugin A needs to be on sites 1, 2, and 3 but would break site 4. Plugin B conflicts with Plugin C, and different sites need one or the other. You can technically manage this with site-level activation, but you’re now tracking a compatibility matrix instead of running a network. The operational overhead eliminates the theoretical efficiency gains.
Separate Teams with Separate Admin Access Needs
The super admin permission model in multisite is blunt. Network admins can see and modify everything across every site. Individual site admins are restricted in ways that standard WordPress admins aren’t — they can’t install plugins themselves, can’t modify certain settings, and can’t access network-level configuration. If you have multiple clients or business units that need genuine administrative independence — their own plugin management, their own user management, full control over their own environment — multisite actively gets in the way. Separate installs with separate wp-admin credentials give each team clean ownership. Multisite gives you one network admin who becomes the bottleneck for everything.
The Real Problems Nobody Warns You About
Shared Resources, Shared Failure
Every site on the network shares the same PHP processes and the same database server. One site with a badly optimized query or an unexpected traffic spike degrades performance for every other site. You can mitigate this with object caching, page caching, and careful server configuration, but you cannot fully isolate sites from each other. On separate installs, a struggling site struggles alone.
The Shared User Table
Users exist at the network level, not the site level. When you create a user on one site, they exist across the network. Their roles are site-specific, but their account is not. This creates situations where a user created for one site can be added to another site by any network admin without that user’s involvement. For internal networks this is fine. For client sites or anything with distinct user populations, it’s a data boundary problem. You’re one permission misconfiguration away from a user from one client site gaining access to another.
Backup and Restore Complexity
Backing up a standard WordPress site is simple — the files and the database. Restoring it is equally simple. On multisite, restoring a single site from backup requires extracting only that site’s prefixed tables from the shared database while leaving the network tables intact, then reconciling any file uploads from the shared uploads directory structure. Most standard backup plugins handle single-site restore fine. Multisite partial restores often require manual database surgery. If you need to restore site 4 to last Tuesday’s state without affecting sites 1, 2, 3, and 5, you’ll find out quickly how much complexity was hiding underneath the “one installation” simplicity.
Core and Plugin Updates
One update, all sites. This is sold as an advantage, and it is — until it isn’t. A WooCommerce update that introduces a breaking change will break every site running WooCommerce on the network simultaneously. You cannot roll back just one site’s plugin version. You either update everything or you update nothing. For homogeneous networks where all sites run the same setup, this is manageable with proper staging. For heterogeneous networks, it’s a recurring source of incidents.
Questions to Answer Before You Decide
Before choosing multisite, answer these honestly:
- Will all sites in this network need the same plugins, or will they diverge over time?
- Is there one central team responsible for the network, or do separate teams need independent admin control?
- If one site goes down or performs badly, is it acceptable for all sites to be affected?
- Do you have a tested plan for restoring a single site from backup without touching the others?
- Are the sites you’re combining actually related in purpose and audience, or are you just grouping them because they’re owned by the same person?
If your answers reveal that the sites are independent in any meaningful operational sense, use separate installs. The management overhead of separate installs has gotten dramatically lower with modern hosting infrastructure, WP-CLI, and deployment pipelines. The argument that “multisite is easier to manage” made more sense in 2010. Today, with proper tooling, managing five separate WordPress installs is not significantly harder than managing a five-site network — and it’s considerably safer.
If You’re Already on Multisite
If you’ve inherited a multisite network that isn’t working well, the options are limited but real. You can migrate individual sites out of the network into standalone installs — WordPress itself doesn’t provide a clean export path for this, but plugins like Duplicator and custom WP-CLI scripts can handle it if you approach it methodically. It’s tedious, not impossible. The alternative is accepting the constraints and building tighter operational discipline around the network: enforced plugin standards, proper staging environments, documented runbooks for backup and restore, and clear policies about what site admins can and cannot do.
What doesn’t work is leaving a poorly structured multisite network in place and hoping it gets better. Without deliberate management, the number of exceptions and workarounds grows until the network is harder to manage than the separate installs you were trying to avoid.
The Bottom Line
WordPress Multisite is a legitimate tool with a narrow set of ideal use cases. University networks, franchise systems with centralized management, agency networks with homogeneous client sites — these are the environments where multisite delivers on its promise. For everything else, it adds complexity that doesn’t pay for itself.
The instinct to reach for multisite when managing multiple related sites is understandable. It looks elegant. One codebase, one update cycle, one place to log in. In practice, that elegance requires a level of architectural discipline most organizations don’t maintain, and the failure modes — shared resource exhaustion, plugin incompatibilities, permission model limitations, backup complexity — are significant enough that I recommend separate installs by default and multisite only when there’s a clear, specific reason.
If you’re evaluating multisite for a real project and want a second opinion on whether it fits your use case, or if you’re dealing with an existing network that’s become difficult to manage, get in touch. This is exactly the kind of architecture question worth spending an hour on before committing to months of implementation work.
