Free Guides 6 min read

WordPress Multisite Setup Guide - When to Use It and How to Configure It

WordPress Multisite runs multiple sites from one installation. When it makes sense, how to set it up, and what ongoing management looks like.

Dobromir Dechev
Dobromir WordPress agency owner
Quick answer

Multisite is right when many sites share one codebase and one administrator, and wrong when clients need independent control, separate backups, or separate hosting. Decide subdomain versus subdirectory before enabling it — changing later is painful.

WordPress Multisite is a powerful feature that many agencies either overuse (applying it when separate installs would be better) or underuse (not knowing it exists). This guide explains the genuine use cases, how to set it up, and what to expect when managing it.

When to use WordPress Multisite

Multisite is the right choice when:

You manage a network of related sites with shared plugins and themes. A university with department sites, a media company with multiple publications, a franchise business with location sites - all benefit from centrally-managed plugins and a shared codebase.

You need users to access multiple sites with one account. Multisite shares the user database across the network. A user can have different roles on different subsites without needing separate accounts.

You want consistent branding with site-specific content. Each subsite can have its own theme, domain, and content while sharing the same WordPress installation and plugin set.

You are building a SaaS-style product on WordPress. Many WordPress-based multi-tenant applications use Multisite as their foundation (course platforms, membership networks, review sites).

When NOT to use Multisite

Independent client sites. Separate WordPress installs are better for client sites that should be isolated - if one client's site has a problem, it should not affect others.

Sites with different hosting requirements. All sites on a Multisite network must use the same hosting account, server configuration, and WordPress version.

Sites with conflicting plugin requirements. If two subsites need different versions of the same plugin, Multisite does not accommodate this.

High-traffic production sites on shared hosting. Multisite on shared hosting is risky - all sites compete for the same resources and any site's traffic spike affects the others.

Multisite architecture options

Subdomain network

Each subsite gets its own subdomain:

  • site1.yourdomain.com
  • site2.yourdomain.com
  • site3.yourdomain.com

Requires a wildcard DNS record (*.yourdomain.com pointing to the server) and a wildcard SSL certificate.

Subdirectory network

Each subsite gets its own subdirectory:

  • yourdomain.com/site1/
  • yourdomain.com/site2/
  • yourdomain.com/site3/

Simpler DNS and SSL setup than subdomain. Slightly less clean URLs.

Domain mapping

Each subsite maps to a separate domain:

  • site1.com
  • site2.com
  • site3.com

Requires separate DNS A records for each domain pointing to the Multisite server, and SSL certificates for each domain (Let's Encrypt wildcard or multi-domain certificate).

WordPress built-in Multisite supports domain mapping since WordPress 4.5. Earlier versions required the Domain Mapping plugin.

Setting up WordPress Multisite

Step 1 - Enable Multisite in wp-config.php

Add before the /* Stop editing */ line:

define( 'WP_ALLOW_MULTISITE', true );

Step 2 - Run Network Setup

Go to Tools > Network Setup. Choose subdomain or subdirectory. Enter your network title and admin email.

WordPress generates configuration code. Copy both the wp-config.php additions and the .htaccess rules (for Apache) or Nginx configuration.

Step 3 - Update wp-config.php

Add the generated constants to wp-config.php (before wp-settings.php):

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false ); // false = subdirectory, true = subdomain
define( 'DOMAIN_CURRENT_SITE', 'yourdomain.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Step 4 - Update Nginx configuration (or .htaccess for Apache)

For Nginx, add to the server block for the main site:

# Multisite subdirectory configuration
if (!-e $request_filename) {
    rewrite /wp-admin$ $scheme://$host$uri/ permanent;
    rewrite ^(/[^/]+)?(/wp-.*) $2 last;
    rewrite ^(/[^/]+)?(/.*\.php) $2 last;
}

For subdomain Multisite with Nginx:

server_name yourdomain.com *.yourdomain.com;

And ensure the wildcard DNS is set:

*.yourdomain.com  A  [server IP]

Step 5 - Log back in

After saving the configuration, log back in. You will see a new "My Sites" link in the admin bar and a Network Admin dashboard.

Network Admin vs Site Admin

Multisite has two levels of admin:

Network Admin (/wp-admin/network/): The super admin area. Controls:

  • Which plugins are available network-wide
  • Which themes are available network-wide
  • Adding, removing, and archiving subsites
  • Network-wide settings (registration, upload limits)
  • User management across the network

Site Admin (/wp-admin/ for each subsite): Standard WordPress admin. Site admins can:

  • Activate themes and plugins from those network-activated
  • Manage content, users, and settings for their specific subsite
  • Not install new plugins or themes (only super admins can)

This permission model is a key Multisite feature: you control what plugins site admins have access to. They can activate from the approved list, not from the entire plugin repository.

Plugin and theme management

Network activation vs site activation

Network activation: Plugin is active on all subsites. Cannot be deactivated by individual site admins. Use for essential plugins (security, caching, backup).

Site activation: Plugin is available to site admins who choose to activate it. Use for optional functionality that some subsites need and others do not.

To network-activate a plugin: Network Admin > Plugins > Click "Network Activate"

Plugins that do not work well with Multisite

Some plugins are not Multisite-compatible:

  • Plugins that assume a single site database (some page builders, some SEO plugins in older versions)
  • Plugins that write to the database without accounting for blog prefixes
  • Some caching plugins (verify Multisite compatibility in the plugin's documentation)

Rank Math, Yoast, WP Rocket, and most major plugins handle Multisite correctly. Smaller or older plugins may not.

Domain mapping on Multisite

To point a separate domain at a subsite:

  1. Add the domain's A record in DNS pointing to the Multisite server IP
  2. In Network Admin > Sites > Edit the subsite
  3. Change the Domain field to the custom domain (e.g., customdomain.com)

SSL for custom domains: Let's Encrypt handles this with the DNS challenge or HTTP challenge. Most managed hosts (Kinsta, Cloudways) handle Multisite domain mapping with automatic SSL.

For self-managed servers, use certbot with the --expand flag to add the new domain to the certificate, or provision a separate certificate for each mapped domain.

Managing uploads on Multisite

Each subsite gets its own upload directory:

wp-content/uploads/sites/2/   (subsite ID 2)
wp-content/uploads/sites/3/   (subsite ID 3)
wp-content/uploads/            (main site)

This keeps each site's media separate. The network admin can set upload limits per site: Network Admin > Sites > Edit > Settings > Upload Space.

Backing up a Multisite network

Standard backup plugins work differently on Multisite:

  • UpdraftPlus backs up the entire network (all sites) as one backup
  • Individual subsite backups require exporting via XML or WP-CLI: wp export --path=/var/www/html --url=site2.yourdomain.com
  • For granular control, the ManageWP or MainWP approach (external management dashboard) handles per-site backup more cleanly

Consider the restore complexity before choosing Multisite for any project where granular backup/restore is important.

Frequently Asked Questions

When should I use WordPress Multisite?
When you genuinely have many sites sharing one codebase under one administrator — a university department network, a franchise chain, or a set of language variants. It suits shared plugins, shared themes and central control. It does not suit unrelated client sites that need independent updates, backups and billing.
Should I use subdomains or subdirectories for Multisite?
Decide before you enable it, because changing afterwards is painful. Subdirectories are simpler and inherit the parent domain's authority. Subdomains suit sites that should feel independent or need genuinely separate identities, and are required if sites will later be mapped to their own domains.
Can each site on Multisite have different plugins?
Plugins are installed network-wide and then activated per site, so a site can run a different set — but it cannot run a different version. One site needing an older or conflicting version of a plugin is a common reason a Multisite plan turns out to be the wrong architecture.
Is Multisite good for managing client sites?
Usually not. A shared codebase means a single plugin update affects every client simultaneously, one compromised site can expose the network, and separating a client onto their own hosting later is a migration rather than a handover. Independent installs plus a management tool is the safer agency pattern.
Does Multisite hurt performance?
Not inherently, but it concentrates risk. All sites share the same server resources and the same database, so a traffic spike or a heavy query on one site affects the others. The database also grows quickly, since each site adds its own set of tables.

Was this article helpful?