WordPress Multisite: what it is, when to use it, and how to set it up

WordPress Multisite is the feature that lets one WordPress installation serve many distinct sites from a single set of core files, themes, and plugins. It has been in core since WordPress 3.0 in 2010, it powers wordpress.com, and it is one of the more powerful features WordPress ships with. It is also one of the most often misunderstood. People reach for Multisite assuming it is the obvious answer for "I have more than one WordPress site", run into the trade-offs after they have already migrated, and then need to dig themselves back out.

This article does two things. First, it gives you a clear mental model of what Multisite is, when it actually fits, and when separate installs are the better choice. Then it walks you through the full enabling process for a fresh install and an existing site, with the gotchas at each step. The reasoning sections come before the steps on purpose: turning Multisite on is easy, turning it off is not, and the most common Multisite mistake is the decision to use it in the first place.

What WordPress Multisite is and when it makes sense

Multisite is a mode you enable in wp-config.php. Once enabled, the WordPress dashboard gains a new layer called the Network Admin, and a new role called Super Admin sits above the standard Administrator. Each site in the network has its own URL, its own content, its own users and options, and its own set of database tables, but all sites share the same WordPress files on disk: one wp-content/, one set of installed themes, one set of installed plugins, and one shared wp-content/uploads/ parent directory with per-site subfolders.

The official Multisite documentation in the Advanced Administration Handbook describes the architecture in detail. The short version: Multisite is one WordPress installation pretending to be many, with the routing decision (which site is being requested) handled at the very start of the bootstrap based on the request domain and path.

Multisite is a genuinely good fit when all of the following are true:

• The sites are owned and operated by the same organisation or person.
• They share the same plugin stack and codebase, and you actually want changes to roll out to all of them at once.
• Hosting, backups, and updates are managed centrally rather than per-site.
• The clients or editors of each site do not need to install their own plugins or themes.

Classic examples are university departmental sites under one umbrella, regional editions of a single brand, franchise location pages, internal intranets with one site per team, and SaaS-style products like wordpress.com itself. The common thread is one operator, one stack, many sites that look and feel similar.

When NOT to use Multisite

This is the section the WordPress documentation does not write, and it is the most important part of the article. Multisite has real drawbacks that make separate installs the better answer in a lot of cases:

Single point of failure. All sites share one PHP process pool, one database connection limit, one filesystem, and one set of plugin code. A plugin bug, a memory leak, a runaway query, or a compromised plugin affects every site at once. Krystal made the same case bluntly: one bad plugin and the whole network goes down.

Site admins cannot install plugins or themes. Only the Super Admin can install plugins and themes; site admins can only activate ones that are already installed network-wide. For agencies whose clients expect the same control they get on a normal WordPress site, this is a workflow killer that does not show up until after the migration.

Plugin compatibility is not guaranteed. Plenty of plugins were never written with Multisite in mind, and they store options in wp_options without scoping them per site, hook into user creation in ways that misbehave at network scope, or assume there is exactly one set of wp_users rights to check. The compatibility issue is not theoretical, it shows up the first time you try to network-activate something that looked harmless.

Subsite migration is hard. Pulling one subsite out of a network into its own standalone WordPress install is a painful, manual process: dump the per-site tables, rename the prefix, fix serialised data, deal with shared users, and reconcile the uploads directory. Separate installs migrate independently and trivially.

Performance is shared. A traffic spike on one subsite consumes PHP workers and database connections that the other subsites also need. There is no isolation. Kinsta's comparison makes the same point: Multisite trades operational simplicity for shared blast radius.

Separate installs are usually the right answer when the sites are independently owned, when each client needs their own plugins, when the sites have meaningfully different uptime requirements, or when you want backups and migrations to be one-site operations. If the sites have nothing in common except that they happen to all run WordPress, you almost certainly want separate installs.

Subdomain vs subdirectory, and why the choice is hard to undo

When you enable Multisite, WordPress asks you to pick one URL structure, and that choice is locked in unless you do significant database work later. The two options are:

• Subdomain mode: each site lives at its own subdomain, like marketing.example.com and support.example.com.
• Subdirectory mode: each site lives at a path under the main domain, like example.com/marketing and example.com/support.

Both modes can map subsites to entirely separate custom domains later, so the subdomain-vs-subdirectory choice is mostly about the default URL shape, not whether you can have custom domains.

Subdomain mode is the more flexible choice when you do not yet know how many sites you will have, when subsites will be operated by different teams under their own brand, and when you may eventually want to migrate one out. Subdirectory mode is the more SEO-friendly choice when all subsites share one brand and you want them to consolidate domain authority on the parent domain.

The Pressable knowledge base has a clear write-up of how disruptive switching modes is later: you have to flip the constants in wp-config.php, rewrite the .htaccess rules, update the domain and path columns in wp_blogs for every subsite, and run a full URL search-replace across all per-site database tables. Treat the choice as permanent.

Prerequisites: wildcard DNS, hosting support, pretty permalinks

Before you enable Multisite, get the following in place:

• Pretty permalinks must already work. WordPress will refuse to enable Multisite if Settings → Permalinks is set to "Plain". Pick any structure other than Plain and confirm a normal post URL loads correctly.
• Wildcard DNS for subdomain mode (when needed). If you want on-demand subsites that get a working URL the moment they are created, you need an A record for *.example.com pointing at the same IP as example.com. If you only ever create a small known set of subsites, you can skip the wildcard and add their A records one by one. The official network creation page is explicit: "wildcard DNS is only needed for on-demand domain-based sites."
• Hosting that supports Multisite. Cheap shared plans sometimes restrict the number of inodes, the number of databases, or the wildcard DNS configuration in ways that make Multisite painful or impossible. Confirm with your host before you start.
• A working backup of files and database. Conversion edits wp-config.php and replaces parts of .htaccess. You want a rollback path.
• Apache with mod_rewrite enabled, or nginx with the equivalent rewrite block. The WordPress installer generates Apache rewrite rules; if you run nginx you have to translate them. The nginx recipe documentation covers a working subdomain Multisite block.
• All plugins deactivated. Multisite conversion can conflict with plugins that hook into the admin during setup. Deactivate everything before you turn it on, then reactivate selectively after.

For an existing site, also be prepared for the rule about published post age in subdirectory mode (covered in the next section), and accept that some plugins you currently use may not survive the conversion.

The wp_posts "1 month" rule explained: it is not site age

There is a long-standing piece of folk wisdom in the WordPress community that you "cannot use subdirectory mode on a WordPress installation older than one month". That description is wrong in a way that matters, and the actual rule is more useful to understand.

The check lives in allow_subdirectory_install() in wp-admin/includes/network.php. It runs a query that looks like this:

SELECT ID FROM wp_posts
WHERE post_date < DATE_SUB(NOW(), INTERVAL 1 MONTH)
AND post_status = 'publish'
LIMIT 1;

If that query returns any row, subdirectory mode is disallowed by default and the Network Setup screen tells you so with the message "Because your installation is not new, the sites in your WordPress network must use sub-domains."

The check has nothing to do with when WordPress was installed, when the database was created, or when you registered the domain. It only cares whether a published post exists with post_date more than 31 days in the past. The reason is permalink collision: if your site already has posts at URLs like /welcome-to-my-blog/ and you switch to subdirectory mode, a future subsite at /welcome-to-my-blog/ would conflict with the existing permalink in ways WordPress cannot reconcile cleanly.

This means a two-year-old WordPress install with no published posts older than a month (because all the posts are drafts, or because all posts have been re-dated, or because it is a fresh content reset) is allowed to use subdirectory mode. Conversely, a one-week-old WordPress install you backdated a post on is not.

You can override the check by adding a filter that returns true from allow_subdirectory_install, but doing so means you accept responsibility for the permalink conflicts: any pre-existing post URL that happens to match a future subsite slug will break. Use the override only on installs where the existing content URLs are well known and demonstrably do not collide with planned subsite slugs.

Enabling Multisite in wp-config.php

With prerequisites in place and all plugins deactivated, enabling Multisite is two phases. The first phase asks WordPress to prepare for network mode; the second phase actually flips the switch.

Step 1: turn on the network installer

Open wp-config.php in your hosting panel's file manager (or download it via SFTP) and add this line above the /* That's all, stop editing! Happy publishing. */ marker:

define( 'WP_ALLOW_MULTISITE', true );

Save the file and reload wp-admin. A new menu item appears under Tools → Network Setup.

Step 2: configure the network

Visit Tools → Network Setup. WordPress shows a form with the choice between subdomain and subdirectory mode (one of them may be greyed out if your install does not pass the wildcard or post-age checks), a network title, and a network admin email. Fill them in and submit.

WordPress now displays two blocks of code that you have to add manually. WordPress does not write these for you. Both go into existing files.

Step 3: extend wp-config.php

Add the second block of constants, also above the That's all, stop editing! marker, immediately after the WP_ALLOW_MULTISITE line:

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 );

Set SUBDOMAIN_INSTALL to true if you picked subdomain mode and false for subdirectory. Use the actual domain (without www., unless your install canonically uses www.) for DOMAIN_CURRENT_SITE. The two _CURRENT_SITE IDs both stay at 1 for a brand new network.

Step 4: replace the .htaccess rewrite block

WordPress also gives you a new .htaccess block to use in place of the default WordPress rewrite block. The exact contents differ between subdomain and subdirectory mode. The subdirectory version is:

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
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]

Open .htaccess in the same file manager or SFTP client and replace your existing # BEGIN WordPress ... # END WordPress block with the version WordPress shows you in the setup screen. Use the version the installer prints, not this one verbatim, because the exact rules differ slightly between subdomain and subdirectory mode.

Step 5: log back in and verify

After saving both files, the setup screen tells you to log out and log back in. Do so. The admin bar now contains a My Sites → Network Admin link. Click it, and you should land on the Network Admin dashboard at wp-admin/network/. Your original site is the first subsite in the network and uses the default wp_ table prefix; new subsites you create from here will get prefixes like wp_2_, wp_3_, and so on.

If Network Admin does not appear, the most common causes are: the new defines were placed below the That's all, stop editing! marker, the .htaccess block was appended instead of replacing the existing WordPress block, or pretty permalinks were not actually working before the conversion. Fix those and reload.

Adding sites to the network

Once the network is up, you create new subsites either through the dashboard or via WP-CLI. The dashboard route is Network Admin → Sites → Add New: enter a subsite address (a subdomain or a path slug depending on mode), a title, the language, and an admin email. WordPress creates the per-site database tables, registers the subsite in wp_blogs, and links the admin user.

For agencies and developers, the WP-CLI wp site command group is much faster:

# Create a new subsite at example.com/marketing
wp site create --slug=marketing --title="Marketing site" --email=admin@example.com

# List every site in the network
wp site list

# List just the URLs
wp site list --field=url

# Archive, deactivate, or delete a subsite by ID
wp site archive 3
wp site deactivate 3
wp site delete 3 --yes

The wp site commands accept the same arguments WordPress would set in the dashboard, and they are the right tool for any kind of bulk site management or scripted provisioning. They also work over SSH on shared hosts that ship WP-CLI, so they fit naturally into deploy pipelines.

Network-activating plugins and themes

Multisite changes how plugin and theme activation works. There are three plugin states to keep straight:

• Network active. The Super Admin activates the plugin from Network Admin → Plugins, and it becomes active on every site in the network. Subsite admins see it as "Network Active" with no deactivation option. This is the right choice for plugins that have to run on every site (security plugins, network-wide caching, anything that touches authentication).
• Site active. A plugin installed by the Super Admin but not network-activated. Whether subsite admins can activate it themselves depends on Network Admin → Settings → Network Settings → Menu Settings → Plugins. If you tick the box, subsite admins get a Plugins menu and can toggle the non-network plugins their site uses; if you leave it unticked, only the Super Admin can activate them per-site.
• Must-use. Files in wp-content/mu-plugins/ are automatically active on every site, do not appear in the dashboard plugin list, and cannot be deactivated through the UI. Use this for plugins you want guaranteed-on with no possibility of accidental deactivation, and for small drop-in customisations.

Themes work similarly: they are installed network-wide, and the Super Admin either network-enables them (making them available to every subsite) or enables them per-site through Network Admin → Sites → Edit → Themes. Each subsite then activates its own theme and customises it independently. Theme customiser settings are scoped per-subsite, so two sites running the same theme can look completely different.

The hard rule that surprises agencies: subsite admins cannot install plugins or themes. They can only activate ones the Super Admin has already installed. If your client expects to add their own plugins, Multisite is not the right architecture for them.

Domain mapping in WordPress 4.5 and later

Before WordPress 4.5 (April 2016), mapping a custom domain to a Multisite subsite required a third-party plugin called WPMU Domain Mapping. In 4.5 the WordPress core team added native UI support for setting a subsite's Site Address (URL) to any domain directly from Network Admin → Sites → Edit. The plugin was no longer necessary for basic one-domain-per-site setups. Plugin Republic walked through how the new UI works at the time.

What WP 4.5 actually changed is more limited than the common phrasing of "domain mapping was merged into core" implies. The dashboard now lets you assign any domain to a subsite, and WordPress's routing layer recognises the new domain and serves the right subsite for incoming requests. What WordPress did not take over is everything outside its own boundary:

• DNS. You still have to add an A record (or CNAME) at your DNS provider pointing the new domain at the server IP.
• TLS certificates. You still have to issue a certificate for the new domain, usually via Let's Encrypt and SNI on the web server.
• COOKIE_DOMAIN. If you use multiple top-level domains in one network, set COOKIE_DOMAIN to an empty string so login cookies are not pinned to a single domain: define( 'COOKIE_DOMAIN', '' );. Without this, logins on mapped domains break in subtle ways.

For the simple case of one custom domain per subsite, the WP 4.5 native UI plus a DNS record plus an SSL certificate is all you need. For the complex case (multiple domains pointing at the same subsite, custom canonical redirect logic, regional aliases, vanity domains), you still want a sunrise.php drop-in.

sunrise.php is a special file that lives in wp-content/sunrise.php and runs extremely early in the WordPress bootstrap, before plugins and even before WordPress has decided which subsite is being requested. It is the right place to inject custom domain-mapping logic. Activate it by adding define( 'SUNRISE', true ); to wp-config.php, then drop a sunrise.php file in wp-content/. WordPress loads it automatically.

The constraint that catches people: code in sunrise.php runs before wpdb is initialised and before WordPress functions are available. It can only use raw PDO/mysqli queries and constants from wp-config.php. Keep it small. The reference implementation most people use is Human Made's Mercator, which builds a full multi-domain mapping layer on top of sunrise.php and is a useful read even if you do not adopt it. The WordPress VIP documentation on sunrise.php explains the load order in more detail.

How the database is structured

Multisite adds several network-level tables on top of the standard WordPress schema, then adds a per-site set of tables for every subsite past the first. With the default wp_ table prefix, the network tables are:

For each subsite past the first, WordPress creates a per-site set of tables using the prefix wp_{site_id}_: wp_2_posts, wp_2_postmeta, wp_2_options, wp_2_comments, and so on. The first site (ID 1) keeps the unprefixed wp_posts, wp_postmeta, etc. that were already there.

This structure has two consequences worth knowing about. First, a SELECT against wp_posts only sees the first subsite's posts, not all posts in the network. Network-wide queries have to iterate the subsites and switch context with switch_to_blog(), which is expensive and easy to misuse. Second, migrating one subsite out of the network is significantly harder than migrating a normal WordPress site, because you have to dump the per-site tables, rename their prefix, deal with the shared wp_users table, untangle wp_blogs and wp_blogmeta, and run a WordPress URL search-replace on the result. If you anticipate ever needing to extract subsites, consider whether a clean migration of the whole site to its own host onto separate WordPress installs is the cleaner architecture from the start.

For a deeper dive into the schema, Misha Rudrastyh's Multisite database tutorial walks through every table with realistic example queries.

Performance and hosting considerations for large networks

Multisite scales well operationally up to a point: one set of files to update, one backup pipeline, one set of plugins to maintain. The technical scaling story is more nuanced, and the failure modes for large networks are different from those of single-site installs.

A few things to plan for:

• Object cache becomes mandatory, not optional. Past about ten subsites, the database round trips for wp_blogs, wp_sitemeta, and wp_blogmeta lookups on every request start to add up. A persistent object cache (Redis or Memcached, configured with a Multisite-aware drop-in) absorbs that traffic and is what separates a network that runs and a network that crawls. The same logic that makes object caching matter for high-TTFB single-site installs applies tenfold here.
• Shared PHP worker pool. All sites compete for the same PHP-FPM workers. A traffic spike or an expensive plugin on one subsite throttles every other subsite. Hosting plans that allocate workers per "site" do not always scale them in proportion to the number of subsites in a network, so confirm with your host how their worker accounting handles Multisite.
• Database connection limits. The shared database user opens connections for every concurrent request across the whole network. A network of 200 sites can hit MySQL's max_connections limit much earlier than 200 separate installs would, because the connection pool is one pool, not 200.
• Network-wide upgrades have to run per-site. When WordPress updates, the database schema upgrade runs on each subsite the first time it is loaded. On a small network this is invisible; on a network with hundreds of sites, the first request to each subsite after an upgrade pays a one-off database migration cost. Schedule major WordPress updates at off-peak hours and consider proactively warming each subsite with a script that hits its admin URL.
• Backups need a per-site option. A whole-network database backup is one MySQL dump and is straightforward, but restoring one corrupted subsite from a network-wide backup means extracting just that subsite's tables. Better to script per-subsite database dumps in addition to the network-wide one. Tools like WP-CLI's wp db export --tables=wp_2_* handle this cleanly.
• The Super Admin role you assign matters. A compromised Super Admin account compromises every site in the network at once. Treat the Super Admin role with the same caution you would treat root on a server, audit it via the Super Admin section of the WordPress roles reference, and never use it as a daily editing account.

Multisite is genuinely powerful for the right shape of problem: a single operator running many similar sites, with a tolerance for shared blast radius and a clear plan for scaling the hosting underneath it. For everything else, the simpler architecture of separate WordPress installs is usually the better answer.