WordPress Multisite: When to Use It and How to Set It Up

WordPress Multisite lets you run a network of sites from a single WordPress installation. It's a powerful feature that's frequently misunderstood and often applied to situations where it creates more problems than it solves. Most sites don't need it. When the use case genuinely fits, it's an extremely effective architecture. This guide covers how to decide whether Multisite is right for your situation and how to set it up correctly if it is.

What Multisite does

With Multisite enabled, a single WordPress installation hosts a network of sub-sites. Each sub-site has its own content, URLs, users, and appearance, but all sites share a single WordPress codebase, a single set of plugin and theme files, and a single database (with site-specific table prefixes or shared tables with site ID columns, depending on the data type).

The network has two levels of administration: a Network Admin who manages the entire installation (installs plugins and themes, creates sites, manages network-wide settings), and individual Site Admins who manage their own site's content, settings, and users within whatever permissions the Network Admin grants them. Plugins are installed once at the network level but can be activated network-wide or per-site.

From an infrastructure standpoint, you're managing one WordPress installation regardless of whether you have 5 sub-sites or 500. Core updates, security patches, and server migrations happen once.

When Multisite is the right choice

Multisite excels when you're running multiple sites that share a common purpose, common functionality, and common ownership, and where centralised management is genuinely valuable. Classic use cases:

Universities and institutions managing department or faculty sub-sites. All sites share the same branding framework and base plugin set, but each department controls its own content. Updates and security patches deploy once across all sites.

Media companies and publishers running regional or topical editions of the same publication. Shared infrastructure, editors, and plugins, with per-site customisation of content and branding.

Franchise networks where each location needs its own site with local content but consistent brand functionality. One plugin set governs all sites; location managers only see their own site's admin.

WordPress-as-a-service platforms where users create their own blog or site under a shared domain. WordPress.com itself runs on a Multisite installation at massive scale. A membership community where each member gets their own subdomain is a smaller version of the same pattern.

The common thread: you control all the sites, the sites share significant infrastructure and functionality, and central management of updates and plugins is a genuine advantage rather than an incidental convenience.

When Multisite is the wrong choice

Don't use Multisite simply to manage multiple client sites from one dashboard. This is the most common Multisite misapplication. Sites belonging to different clients have independent business requirements, different update schedules, different plugin needs, and different acceptable-risk thresholds. Coupling them into a shared installation means a single bad plugin update, a security compromise, or a database corruption event can affect all of them simultaneously.

Separate WordPress installations managed through a central dashboard tool (MainWP, ManageWP, or InfiniteWP) gives you the convenience of centralised update management without the data coupling. If a plugin update breaks one client's site, only that site is affected, not all of them.

Also avoid Multisite when sites have very different plugin requirements. Because plugins are installed at the network level, having one sub-site that needs Plugin A while another sub-site specifically cannot have Plugin A active creates administrative headaches. Multisite works cleanly when all sites roughly share the same plugin ecosystem.

Subdomain vs subdirectory structure

Multisite networks are structured either as subdomains (site1.yourdomain.com, site2.yourdomain.com) or subdirectories (yourdomain.com/site1, yourdomain.com/site2). You choose the structure during setup and cannot change it afterward without migrating all sites.

Subdomain structure requires a wildcard DNS record (*.yourdomain.com pointing to your server IP) and web server configuration that allows wildcard subdomains. Not all shared hosting environments support this. Subdirectory structure works on any host that supports standard WordPress permalinks.

For most institutional and franchise use cases, subdomain structure is cleaner because each site has a distinct hostname. For simpler cases or environments without wildcard DNS support, subdirectory structure works equally well.

Setting up Multisite: step by step

Start with a clean, single-site WordPress installation. Multisite setup into an existing site with established content is riskier and requires care with URL mapping. Once you have your installation ready:

1. Add define( 'WP_ALLOW_MULTISITE', true ); to wp-config.php, above the "stop editing" line.
2. Go to Tools > Network Setup in wp-admin. Choose your structure (subdomain or subdirectory) and set a network name and admin email.
3. WordPress provides two blocks of code to add: additions to wp-config.php and replacement rules for .htaccess. Add both exactly as shown.
4. Log out and log back in. The Network Admin menu now appears under My Sites in the admin bar.
5. If using subdomain structure, create the wildcard DNS record at your domain registrar or DNS provider: an A record for *.yourdomain.com pointing to your server's IP address.
6. Under Network Admin > Sites > Add New, create your first sub-site. Assign a path (subdirectory) or domain prefix (subdomain) and an admin user.

Domain mapping for sub-sites

Sub-sites don't have to live under the main domain's subdirectory or subdomain, they can use completely separate domains. A network at yourdomain.com can host a sub-site accessible at clientdomain.com. This is called domain mapping.

WordPress 4.5+ includes basic domain mapping natively via the Site Address setting in Network Admin > Sites > Edit. For each sub-site, you can set a custom domain in the "Site Address" field. The external domain needs a DNS A record pointing to your server. LiteSpeed and Apache both handle this correctly via the wildcard vhost or additional ServerAlias configuration.

Performance and caching considerations

LiteSpeed Cache supports Multisite natively. Page cache entries are stored per-site, so each sub-site gets its own cache pool. Cache purging from one sub-site doesn't affect others. The network admin can also control which LSCache settings can be customised per-site versus enforced network-wide.

Because all sites share a single database, a poorly-performing sub-site (excessive queries, slow plugins) can impact the database performance for all other sub-sites. Monitor database performance at the network level, not just per-site, using Query Monitor or server-level slow query logging.

Backup strategy also changes with Multisite: you need to back up the entire database (which contains all sites), not individual databases per site. Ensure your backup solution supports Multisite database structure and that you've tested a restore on a sub-site basis as well as full-network restore.