How to Set Up Multisite in WordPress (And When You Actually Need It)

WordPress Multisite lets you run multiple websites from a single WordPress installation. One admin panel, one database, one set of core files. That sounds powerful, and it is. But it is also one of the most misunderstood features in WordPress. People enable it for the wrong reasons, run into surprising limitations, and spend hours undoing what took minutes to set up. This guide walks you through exactly when Multisite makes sense, how to configure it from scratch, and what to watch for once your network is live.

What WordPress Multisite Actually Is

WordPress Multisite is a built-in feature that transforms a single WordPress install into a network of sites. Each site in the network shares the same WordPress core files and the same database (in separate tables), but has its own content, settings, themes, and plugins. You manage everything from a single Network Admin dashboard.

Introduced in WordPress 3.0 (previously a separate product called WPMU), Multisite is fully supported and maintained by the core team. It is not a plugin. It is not a third-party add-on. It is native WordPress behavior unlocked by a few constants and a rewrite rule change.

The network can be configured two ways:

• Subdomains: each site gets its own subdomain: site1.yournetwork.com, site2.yournetwork.com
• Subdirectories: each site lives in a folder: yournetwork.com/site1, yournetwork.com/site2

A third option, custom domain mapping, lets you point any domain to any site in the network. More on that later.

When Multisite Makes Sense (And When It Does Not)

This is the question most tutorials skip. Before you touch a single config file, you need to know whether Multisite is the right tool for your situation.

Good use cases for Multisite

A network of related sites you own and manage. A university with a department site for each faculty. A news publisher with regional editions. A franchise with a location page per city. These scenarios benefit from shared plugins, centralized updates, and a single login for all sites.

A SaaS or membership platform where each user gets their own site. Tools like WordPress.com, Edublogs, and BuddyBoss Platform are built on Multisite. When you want to give each customer a site under your domain, Multisite is the standard approach.

A white-label web agency managing many client sites under one umbrella. You maintain one set of approved plugins and themes, push updates once, and manage user access per site. This works well when clients do not need separate hosting accounts.

When you should not use Multisite

Multilingual sites. If you want the same content in English, Spanish, and French, use a multilingual plugin like WPML or Polylang on a standard install. Multisite can technically host one language per site, but it creates a maintenance burden without real benefits.

Staging environments. Do not use a Multisite subsite as your staging environment. Staging should be a separate install with its own database, isolated from production. A staging subsite shares the database and can cause data conflicts.

Completely unrelated client sites. If two clients have nothing to do with each other, separate installs give you true isolation. A security incident on one site in a Multisite network can affect all sites in the network.

Sites that need wildly different plugin sets. Multisite allows network-wide plugin activation, but also per-site plugin activation (if the Network Admin allows it). If every site needs a completely different plugin stack, the shared infrastructure becomes a constraint rather than a benefit.

Prerequisites Before You Enable Multisite

You cannot enable Multisite on a WordPress install that already has existing content and then easily reverse it. Before you start:

• Take a full backup of both your files and your database. This is not optional. Multisite modifies your database schema and your config file.
• Make sure you are on a fresh install if possible. Adding Multisite to an existing site works, but the original site becomes “Site 1” in the network.
• Check your hosting supports Multisite. Shared hosts sometimes restrict the wildcard DNS subdomains needed for subdomain networks. Ask your host before you start.
• Confirm PHP and WordPress versions. You need WordPress 4.5 or higher (current is 6.x). PHP 7.4+ is recommended.

Step 1: Edit wp-config.php to Enable Multisite

Open your wp-config.php file. Find the line that reads:

/* That's all, stop editing! Happy publishing. */

Add the following line above that comment:

define( 'WP_ALLOW_MULTISITE', true );

Save the file. Log back into your WordPress admin. You will now see a new menu item under Tools > Network Setup.

Step 2: Run the Network Setup Wizard

Go to Tools > Network Setup in your WordPress admin. You will be asked to choose between subdomains and subdirectories.

Subdomain networks require wildcard DNS on your hosting. This means your host needs to route *.yoursite.com to your server. If you are on a fresh install, this is the preferred option for production networks.

Subdirectory networks do not require any DNS changes. They work everywhere, including shared hosting. If you already have posts on Site 1 at the root, WordPress may require you to use subdirectories.

Fill in the Network Title and Network Admin Email. Click Install.

WordPress will display two blocks of code you need to add manually. Do not skip this step.

Step 3: Add the Required Constants to wp-config.php

WordPress gives you a block of constants to paste into wp-config.php. It looks like this (your values will differ):

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

Paste this block above the “stop editing” comment in wp-config.php, replacing the WP_ALLOW_MULTISITE line you added in Step 1.

A few constants worth knowing beyond the defaults:

• define( 'NOBLOGREDIRECT', '%siteurl%' );: Redirects visitors hitting non-existent subsites to the main site instead of showing a WordPress error.
• define( 'WPMU_ACCEL_REDIRECT', true );: Improves file serving on some server setups.
• define( 'MS_FILES_REWRITING', false );: Relevant if you have a shared uploads folder concern.

Step 4: Update .htaccess (Apache) or Nginx Config

WordPress also provides updated rewrite rules. For Apache, replace your entire .htaccess with the block WordPress shows you. A subdirectory network looks like this:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

For Nginx, there is no .htaccess. Instead, you need to add the multisite rules directly to your server block config. A subdirectory example:

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

Reload Nginx after making changes: sudo nginx -s reload

After updating both files, log back into WordPress. You will land in the Network Admin dashboard.

Step 5: Network Admin Overview and Adding Your First Site

The Network Admin is a new layer on top of your regular admin. You access it via My Sites > Network Admin in the top bar.

From the Network Admin you can:

• Add new sites to the network
• Activate plugins network-wide (or allow per-site activation)
• Activate themes network-wide
• Manage all users across all sites
• Update WordPress core for the entire network at once

To add your first subsite, go to Sites > Add New. Fill in the site address (subdomain or subdirectory slug), site title, admin email, and language. Click Add Site.

You can then visit the site’s individual admin via Sites > All Sites > Edit or by switching sites from the top bar.

Plugin and Theme Activation on a Multisite Network

This is where Multisite behaves differently from a single install, and it surprises many people.

Plugins

In a Multisite network, plugins can be activated at two levels:

• Network Activated: The plugin is active on every site in the network. Site admins cannot deactivate it. You do this from Network Admin > Plugins.
• Site Activated: The plugin is only active on that specific site. Site admins can manage it if the Network Admin has given them plugin management permissions.

By default, site admins cannot install new plugins. Only the Network Super Admin can install plugins. This is intentional. You control the approved plugin list. Before you push a plugin update to the whole network, test it on a single site first.

To allow site admins to activate (but not install) plugins, add this to wp-config.php:

define( 'DISALLOW_FILE_MODS', false );

Or from Network Admin, go to Network Settings and check “Enable administration menus” for plugins.

Themes

Themes follow the same two-level activation pattern. You enable a theme for the network from Network Admin > Themes. This does not activate it everywhere; it just makes it available for site admins to activate on their own sites. To force a theme on every site, you would need a custom must-use plugin or a switch_theme call on site creation.

User Roles and Network-Wide Access

Multisite adds a role that does not exist in single installs: Super Admin. The Super Admin can manage all sites, install plugins and themes, and change network settings. Regular admins only have authority over their own site.

Understanding how WordPress user roles work is important before you start adding people to a network. In Multisite, a user exists at the network level but is assigned a role per site. The same person can be an Editor on Site A and an Administrator on Site B.

Key points to keep in mind:

• Users register once and can be added to multiple sites with different roles.
• Adding someone as a Super Admin should be rare. Most site owners only need the Administrator role on their own site.
• Site admins in Multisite have fewer capabilities than a regular WordPress Administrator. They cannot install plugins or themes unless the Network Admin explicitly allows it.

Domain Mapping: Pointing Custom Domains to Subsites

By default, your subsites are at yournetwork.com/site1 or site1.yournetwork.com. Domain mapping lets you point a completely different domain, like clientsite.com, to a subsite.

Since WordPress 4.5, domain mapping is built into core. You do not need the old WordPress MU Domain Mapping plugin.

To map a domain:

1. Point the domain’s DNS A record to your server’s IP address.
2. In Network Admin, go to Sites > All Sites.
3. Click Edit on the site you want to map.
4. Under the Settings tab, change the Siteurl and Home fields to the custom domain.

If you are using Nginx, also add a server_name entry for the new domain in your Nginx config and reload. For Apache with shared hosting, the host usually handles this via cPanel’s addon domains feature.

Some hosts need an SSL certificate per mapped domain. If you use Cloudflare, the proxied SSL handles this automatically. If you manage your own server, Certbot with a wildcard certificate covers all subdomains in one certificate.

WP-CLI Multisite Commands

WP-CLI makes managing a Multisite network dramatically faster than clicking through the admin. Here are the commands you will use most often.

List all sites in the network

wp site list --fields=blog_id,url,last_updated,deleted,archived

Create a new site

wp site create --slug=newsite --title="New Site Title" [email protected]

Archive (soft-delete) a site

wp site archive --url=yournetwork.com/site1

Delete a site permanently

wp site delete --url=yournetwork.com/site1

Run a command on every site in the network

wp site list --field=url | xargs -I % wp --url=% plugin activate your-plugin-slug

That last pattern is powerful. You can flush caches, regenerate thumbnails, update options, or run database repairs across every site with a single command.

Activate a plugin network-wide via CLI

wp plugin activate your-plugin --network

Export the user table for a specific site

wp user list --url=yournetwork.com/site1 --format=csv > site1-users.csv

Backup Strategy for Multisite Networks

Backing up a Multisite install is different from backing up a single site because one database serves all sites. You cannot just export one site’s tables and call it done.

Database backup

Use WP-CLI to dump the entire database:

wp db export network-backup-$(date +%Y-%m-%d).sql

If you need to back up just one site’s content, you can export specific tables. Each subsite has its own table prefix. Site 2 uses wp_2_posts, wp_2_options, and so on. You can export just those tables:

mysqldump -u dbuser -p dbname wp_2_posts wp_2_postmeta wp_2_options > site2-tables.sql

Files backup

The uploads folder is shared but partitioned by blog ID. Uploads for Site 2 are in wp-content/uploads/sites/2/. A full network file backup needs the entire wp-content directory, not just the root uploads folder.

tar -czf wp-content-backup-$(date +%Y-%m-%d).tar.gz /var/www/html/wp-content/

Per-site restoration

If a single subsite gets corrupted, you can restore its tables and uploads folder without touching other sites in the network. This is one of the underrated benefits of the partitioned structure.

Performance Considerations for Multisite Networks

A Multisite network shares server resources across all sites. One site getting a traffic spike affects the others. Here is what matters for performance:

Object caching is non-negotiable

Without a persistent object cache, every page load on every site queries the database independently. With Redis or Memcached and the corresponding WordPress plugin (like Redis Object Cache), cached objects are shared across sites where appropriate and each site’s cache is namespaced by blog ID. This is the single biggest performance improvement for a Multisite network.

Shared database load

All sites write to the same database. On high-traffic networks, a single large site can starve the others of database connections. A read replica and connection pooler (like ProxySQL or HyperDB) helps spread the load.

Plugin count matters more

Each network-activated plugin loads on every page request across every site. A plugin that adds 20ms of overhead on a single site adds 20ms across 50 sites on every single request. Be conservative about network-activating plugins you do not need everywhere.

CDN configuration

Static assets (images, CSS, JS) for each subsite live under different paths. Your CDN configuration needs to cache the subdirectory or subdomain correctly per site. Cloudflare handles this automatically if each domain is proxied. Custom CDN setups need URL rewrite rules per site.

Common Multisite Problems and How to Fix Them

New sites show a “Site not found” error

This usually means the rewrite rules in .htaccess or Nginx are not correct, or the wildcard DNS for subdomains is not set up. Double-check the exact block WordPress gave you in Step 3 and make sure you replaced (not appended to) the existing rules.

Plugins installed but not available on subsites

Plugins installed but not network-activated only appear in the admin of the site where they were installed. To make a plugin available on subsites, either network-activate it or enable per-site plugin management in Network Settings.

Upload limit is very low

Multisite defaults to a 1.5MB upload limit per site. You can change this in Network Admin > Network Settings > Upload Settings. To override at the PHP level, add to php.ini or .htaccess: upload_max_filesize = 64M and post_max_size = 64M.

The main site’s permalink structure changes

When you add Multisite to an existing site, WordPress sometimes resets the permalink structure. Go to Settings > Permalinks on Site 1 and click Save without changing anything to regenerate the rewrite rules.

Should You Use Multisite? A Decision Framework

Ask yourself these questions:

1. Do you need to manage 3 or more related sites with a shared plugin/theme set? If yes, Multisite is worth it.
2. Are the sites completely unrelated, belonging to different clients with no shared content? If yes, separate installs are safer.
3. Do you need to give users a site on your domain as part of your product? If yes, Multisite is the standard architecture for this.
4. Are you trying to solve a multilingual problem? If yes, use a multilingual plugin on a single install instead.
5. Do you have staging or dev environments in mind? If yes, keep those as separate installs with their own databases.

Multisite is a powerful tool that rewards the right use case. A university, a franchise network, a SaaS platform, a community with per-user sites: these are the scenarios Multisite was designed for. If your situation matches, the setup is straightforward and the ongoing management is genuinely easier than running separate installs. If your situation does not match, no amount of configuration will make Multisite feel natural.

Take the time to plan your network structure before you run the setup wizard. Changing from subdirectories to subdomains after sites are created is not a clean process. Decide up front, back up everything, and you will have a solid foundation for whatever your network grows into.

Migrating an Existing Single Site to a Multisite Network

If you already have a WordPress site with content and want to convert it into a Multisite network, the process is possible but needs careful planning. The original site becomes Site 1 (blog_id = 1) automatically. Nothing about its content changes during the conversion.

Here is the general migration sequence:

1. Back up everything before touching a single file.
2. Add WP_ALLOW_MULTISITE to wp-config.php.
3. Run the Network Setup wizard from Tools > Network Setup.
4. Add the constants and rewrite rules WordPress provides.
5. Verify Site 1 (your original site) is fully functional.
6. Add new subsites from Network Admin > Sites > Add New.

One thing to check: if your existing site has a complex permalink structure (custom post types, lots of rewrite rules), those rules may conflict with the new Multisite rewrites. Always test on a staging copy first.

If you need to import content from another WordPress site into a subsite, the standard WordPress export/import tool works at the per-site level. Export from the source site, log into the subsite, and run the importer. Images will be re-uploaded to that subsite’s dedicated uploads folder.

Must-Use Plugins in a Multisite Network

Must-use plugins (stored in wp-content/mu-plugins/) behave differently in Multisite. They are automatically active on every site in the network with no option to deactivate them at the site level. This makes them ideal for:

• Enforcing security policies network-wide (CSP headers, login lockouts)
• Custom user registration flows
• Network-wide analytics or logging
• Overriding specific capabilities for site admins

A common pattern is using an mu-plugin to restrict what site admins can change. For example, preventing them from switching themes or disabling specific network-activated plugins:

add_filter( 'user_has_cap', function( $caps, $cap ) {
    if ( in_array( 'switch_themes', $cap ) && ! is_super_admin() ) {
        $caps['switch_themes'] = false;
    }
    return $caps;
}, 10, 2 );

This kind of fine-grained control is one of the genuine advantages of Multisite for agency and SaaS use cases.

Network-Wide Updates and Maintenance

One of the biggest operational advantages of Multisite is centralized updates. When WordPress core releases a security patch, you update once and all sites are patched. When you update a network-activated plugin, every site gets the fix immediately.

The maintenance workflow for a Multisite network looks like this:

1. Check the updates screen in Network Admin (Dashboard > Updates).
2. Update WordPress core from there. It patches all sites at once.
3. Update network-activated plugins one at a time, checking each site after each update.
4. For themes, test on a staging subsite before network-wide rollout.

WP-CLI simplifies this further:

# Update all core, plugins, themes across the network
wp core update
wp plugin update --all --network
wp theme update --all

One caution: network-activated plugin updates affect every site immediately. If the update has a bug, every site breaks. Always keep a rollback plan. Most managed WordPress hosts with Multisite support let you roll back to the previous plugin version from their control panel. If you are self-hosted, keep a copy of the previous plugin zip before updating.

Security Hardening for Multisite Networks

A Multisite network is a larger attack surface than a single site. A vulnerability in one site’s theme or a weak admin password on one subsite can cascade across the network. Extra hardening steps are worth the effort.

Limit Super Admin accounts

Only the people who absolutely need full network control should be Super Admins. Give site owners the Administrator role on their own site. Super Admin should be limited to 1-2 people maximum.

Disable user registration if not needed

By default, user registration may be open at the network level. If your network is private (internal company sites, agency client sites), turn off open registration in Network Admin > Settings > Allow new registrations.

Restrict file editing

Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php. This prevents anyone, including Super Admins, from editing plugin or theme files from the admin dashboard. Code changes should go through version control, not the admin editor.

Two-factor authentication

Network-activate a two-factor authentication plugin (like Two Factor or WP 2FA) and enforce it for all Administrator and Super Admin accounts. One compromised admin account can affect every site in the network.

These steps do not make Multisite less secure than separate installs. A well-configured Multisite network can actually be more secure because updates happen centrally and security plugins are enforced consistently across all sites. The risk comes from neglect, not from the architecture itself.

Domain Mapping WordPress Multisite WordPress Networks WordPress Setup WP-CLI

Last modified: May 8, 2026