Multisite in WordPress | WordPress Series

Introduction

If you're managing multiple WordPress sites and finding yourself repeating the same setup, plugin updates, and theme maintenance across installations, you're not alone—and WordPress multisite might be the answer. Multisite in WordPress: a practical guide for developers covers one of the platform's most powerful yet often misunderstood features, allowing you to run dozens or even hundreds of sites from a single WordPress installation and database.

We've deployed multisite across e-commerce networks, SaaS platforms with per-tenant sites, and agency portfolios where each client gets their own branded space. The appeal is real: centralized updates, shared plugins, unified user management, and dramatic resource savings. But multisite isn't a silver bullet. It introduces complexity in ways that single-site installations never do, and a wrong choice early—like picking subdomains when you need subdirectories—can force a painful migration later.

In this guide, we'll walk through when multisite makes sense, how to choose your URL structure, how to manage shared functionality with network plugins, and the trade-offs you'll live with once you've committed to the model.

Multisite shines when you have multiple WordPress sites that share governance, branding elements, or core functionality, and you want to manage them as a network rather than as separate installations.

Common use cases

Agency or freelancer portfolios: Each client gets their own site, but you deploy theme updates and security patches once across the network.
Regional or language variants: One brand, multiple markets. Each site can have its own language, currency, and regional plugins, but core branding and policies flow from the network level.
Tenant-based SaaS: Each customer gets an isolated site environment with their own posts, pages, users, and settings, but all running on shared infrastructure.
Large organizations with departments: Corporate groups, universities, or media companies where each department or school runs its own site but needs unified user directories and compliance tooling.

The key question: do these sites share enough that managing them separately would be a pain, but differ enough that a single site with multiple post types or custom taxonomy won't work? If yes, multisite is worth investigating.

When multisite is a poor fit

Multisite adds operational overhead. If you're running just two or three sites, or if each site is completely independent with its own hosting needs, separate installations are simpler and more flexible. Multisite also couples all sites to the same WordPress version, plugin compatibility baseline, and uptime—if you need to run different versions or take one site offline independently, you've lost that option.

Subdomains vs Subdirectories: Decide Early

This is the most consequential decision you'll make. Once you've picked your URL structure and loaded content into your sites, switching between subdomains and subdirectories is a migration that touches database records, .htaccess or Nginx configuration, SSL certificates, and DNS. Get it right the first time.

Subdomains

Each site gets its own domain: site1.example.com, site2.example.com, etc.

Pros: Each site looks and feels independent. Search engines often treat subdomains as separate domains, which can be good if you want each site's SEO to stand alone. Easier to isolate third-party services or custom infrastructure per subdomain.
Cons: Wildcard DNS setup required. SSL certificate complexity (unless you use a wildcard cert). More network calls in some monitoring and logging scenarios.

Subdirectories

Each site lives under a path: example.com/site1, example.com/site2, etc.

Pros: Single domain, single SSL certificate, simpler DNS. Search engines treat subdirectories as part of the same domain—link equity and authority flow to the main site.
Cons: All sites appear to belong to the same entity, which may not match your branding goals. Slightly more complex URL rewriting in the web server config. If you ever want a site to be truly independent, you'll have a harder time moving it out.

Which to choose?

Default to subdirectories unless you have a specific reason not to. They're simpler to set up and maintain, and they keep all your sites under one roof. Use subdomains if each site needs to feel like a completely independent brand, or if you're running a platform where isolation is a feature (like a marketplace where users can create their own storefronts).

Configuration snippet

During network setup in WordPress admin, you'll answer one question: subdomains or subdirectories. The wp-config.php constants tell WordPress which structure you're using:

php

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false); // false = subdirectories, true = subdomains
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

If you use subdomains, set SUBDOMAIN_INSTALL to true and update DOMAIN_CURRENT_SITE accordingly. Changing this constant alone won't migrate you—the database structure and URLs of existing content stay put—so make this decision before publishing content.

Network Plugins: Network-Activate Shared Functionality

One of multisite's biggest wins is plugin management. Install a plugin once in the plugins directory, and you can activate it network-wide for all sites, or let individual site administrators choose whether to activate it on their own site.

Network-only plugins

Some plugins are designed to work only when network-activated. They often hook into multisite-specific actions like wp_initialize_site, manage user roles across the network, or provide network-level settings. A plugin declares itself as network-only by adding a header:

php

/**
 * Plugin Name: My Network Plugin
 * Network: true
 */

Once you add the Network: true header, the plugin only appears in the Network Admin (wp-admin/network) and individual site admins can't install or activate it on their own.

Plugins available to sites but activated per-site

Most plugins work in multisite without modification. They can be network-activated (so every site gets them by default) or left available for each site admin to opt into. This is useful when you want a shared library but let regional or departmental sites choose what they need.

Practical example: a custom authentication plugin

Suppose you want to sync user logins across all sites in the network—when a user logs into one site, they're logged in everywhere. That's a network-level concern:

php

/**
 * Plugin Name: Unified Network Auth
 * Network: true
 */

function my_network_auth_setup() {
    // Hook into login flow
    add_filter( 'wp_authenticate_user', 'sync_user_to_network', 10, 2 );
}
add_action( 'plugins_loaded', 'my_network_auth_setup' );

function sync_user_to_network( $user, $password ) {
    if ( is_wp_error( $user ) ) {
        return $user;
    }
    
    // Custom logic to ensure user exists on all sites
    $sites = get_sites();
    foreach ( $sites as $site ) {
        add_user_to_blog( $site->blog_id, $user->ID, 'subscriber' );
    }
    
    return $user;
}

This plugin makes sense only as a network-only plugin. Individual sites can't opt out, and it manages authentication across the entire network.

When to use network plugins

Network-activate plugins for infrastructure concerns: security, backups, analytics, user directory sync, update management. Let individual sites manage their own content and display plugins. This keeps the network stable while giving site managers autonomy.

Trade-offs: Shared Database and Updates for All Sites

Multisite's central database is both its strength and its constraint. All sites share the same WordPress tables, with a blog_id column to keep data separate. This makes it cheap to add new sites and easy to move users or content between them, but it also means every site is coupled to the same WordPress version and the same set of active network plugins.

The shared database model

In a single-site installation, you have tables like wp_posts, wp_postmeta, wp_users, and wp_options. In multisite, each site gets its own prefix: wp_posts for site 1, wp_2_posts for site 2, wp_3_posts for site 3. Users, however, are shared across the network by default; they live in wp_users without a site-specific prefix.

This design allows one user account to have different roles on different sites, which is powerful for federated organizations. It also means user data is centralized—if you need to sync user metadata across sites or enforce network-wide policies, you have one place to do it.

Updates and compatibility

All sites run the same WordPress core version. You can't run WordPress 6.4 on one site and 6.5 on another. When you update WordPress, every site updates together. This keeps things simple operationally but means you can't stagger rollouts or test updates on a staging site that's truly isolated.

Similarly, network-activated plugins affect all sites. If a plugin update breaks something, every site is broken until you either revert the plugin or fix the code. This is why extensive testing in a development multisite before pushing updates to production is critical.

Database size and performance

A single database with hundreds of sites and millions of posts will grow large. Backups, restores, and queries across all site data take proportionally longer. Most teams add a caching layer (Redis, Memcached) and optimize database indexes early. If you're running dozens of sites with moderate traffic each, this is manageable. If you're approaching thousands of sites, you may outgrow a single database and need to shard or move to a specialized multisite hosting provider.

Site independence and resource contention

One runaway site can affect others. If site A launches a broken cron job that fills the database with logs, site B's queries may slow down. There's no built-in resource isolation like you'd have with separate containers or VMs. You have to be disciplined about plugin quality, cron management, and monitoring to avoid one site dragging down the network.

Common Mistakes

Switching between subdomain and subdirectory after launch: Don't. Make this choice before you have content and users. Migration is painful.
Treating the network database as a free pass to share user data indiscriminately: Just because all users are in one table doesn't mean you should sync profile data or settings across sites that should be isolated. Respect site boundaries.
Network-activating too many plugins: Every network-activated plugin runs on every site. This bloats the backend and increases security surface area. Activate only what's truly needed network-wide.
Ignoring per-site customization until it's too late: Multisite provides hooks like wp_initialize_site to set up new sites with default content and settings. Don't rely on manual setup; automate it.
Assuming multisite will solve organizational chaos: Multisite is a technical tool, not a governance tool. If you don't have clear policies about what each site is for, who manages it, and what content belongs where, multisite will amplify the confusion.

Key Takeaways

Multisite works best for networks of related sites—agencies, regional variants, tenant-based platforms—where shared infrastructure and centralized management outweigh the need for independence.
Choose subdomains or subdirectories before launch. Subdomains feel more independent; subdirectories are simpler operationally. Switching later is expensive.
Network-activate plugins only for network-level concerns: auth, backups, compliance. Let sites manage their own content and display plugins.
All sites run the same WordPress version and share a database. Plan for this coupling upfront—it affects your release cycle, testing strategy, and how you scale.
Automate site provisioning and set clear boundaries between sites. Multisite is powerful but requires discipline to avoid becoming a bottleneck.

Multisite in WordPress: a practical guide for developers