WordPress Multisite: The Complete Guide to Managing Multiple Sites in 2026

Emnes April 17, 2026

Network diagram showing a central hub connected to multiple WordPress sites

WordPress Multisite lets you run an unlimited number of WordPress sites from a single installation, sharing the same core files, plugins, themes, and user database. It powers some of the largest WordPress deployments on the internet — WordPress.com itself, university networks with hundreds of departmental sites, media companies with a site per publication, and SaaS products that give every customer their own subdomain.

But multisite is also one of the most misunderstood features in WordPress. People turn it on for the wrong reasons, hit operational problems they didn’t anticipate, and end up running a fragile network that would have been easier to manage as separate installs. Others skip multisite when it would have saved them hundreds of hours of maintenance and never realize what they missed.

This guide is a complete, practical look at WordPress Multisite in 2026 — when to use it, when to avoid it, how to set it up correctly, and how to manage a multisite network day-to-day. Whether you’re running a small family of 5 sites or a network of 500, the principles are the same, and getting them right at the start is much cheaper than fixing them later.

What Is WordPress Multisite, Exactly?

WordPress Multisite is a built-in feature (since WordPress 3.0, released 2010) that converts a standard WordPress install into a network of sites. Each site has its own URL, its own content, its own admins, and its own theme customization — but they all share:

One WordPress core installation — one set of files to update, one version to keep in sync
One plugins directory — plugins can be activated per-site or network-wide
One themes directory — themes available to the network, activated per-site
One user database — users exist at the network level and are granted roles on individual sites
One database, separate tables per site — site #2’s posts live in wp_2_posts, site #3’s in wp_3_posts, and so on

The network has a Super Admin role that can access every site and manage network-level settings. Individual site admins can manage their own site but can’t install plugins or themes (only the Super Admin can).

Subdomains vs Subdirectories: Pick Once, Live With It

When you set up multisite, WordPress asks one big structural question: do you want sites on subdomains (site1.example.com, site2.example.com) or subdirectories (example.com/site1/, example.com/site2/)?

This is not a cosmetic choice. It affects URL structure, SSL certificate management, SEO, cookie handling, and whether you can map custom domains later.

Subdomains — Best for Independent Sites

Choose subdomains when sites are editorially independent: different brands, different departments, different tenants in a SaaS product. Each subdomain reads as its own property to search engines and users. Requires a wildcard DNS record (*.example.com) and a wildcard SSL certificate (*.example.com), both of which Let’s Encrypt supports for free.

Subdirectories — Best for Related Content

Choose subdirectories when sites are editorially related: a company’s regional sites, a university’s departmental pages, a publication’s section sites. Google treats subdirectories as part of the parent domain for SEO purposes, so the content contributes to the root domain’s authority. Simpler DNS (no wildcard needed), simpler SSL (one certificate covers everything).

The decision is permanent without a migration. Switching after launch is possible but involves database search-and-replace and risks broken URLs. Pick deliberately the first time.

When WordPress Multisite Is the Right Choice

Multisite saves real time when:

You manage 5+ sites that share infrastructure — one core update covers all of them instead of 5 separate update runs
Sites share users — a university with 50 departmental sites where faculty log in once and access their departmental pages
Sites share content templates — a franchise with 100 local pages that all use the same theme and structure, differing only in regional content
You run a SaaS giving each customer a site — a tenant per site, isolated content, shared code
You have central editorial control — a media company where one editorial team runs multiple publications

When to Avoid WordPress Multisite

Multisite adds complexity, and that complexity bites you in specific situations:

Sites need different plugins or themes — if site A needs WooCommerce and site B cannot have WooCommerce loaded for performance reasons, single installs are cleaner
Sites need different WordPress versions — multisite forces every site to the same core version. Sometimes a single site can’t upgrade because a critical plugin isn’t ready.
Sites have different hosting requirements — one site needs high-traffic infrastructure, another is a low-traffic internal wiki. Multisite puts them on the same server and they share fate.
Sites belong to different owners — selling a site on multisite is painful because it’s just a set of database tables inside a bigger install. A single-site install can be handed over as a ZIP.
Sites have strict data isolation requirements — regulated industries where one tenant’s data must physically never touch another’s. Separate installs remove the question.
You have 2–3 sites total — the overhead of multisite rarely pays off below 5 sites

How to Enable Multisite in 4 Steps

Step 1 — Back Up Your Site

Converting to multisite modifies wp-config.php and adds database tables. If something goes wrong, you want to roll back instantly. Use Backup Migrate Reset or any full-site backup tool.

Step 2 — Enable Multisite in `wp-config.php`

Add this line above the “stop editing” marker in wp-config.php:

define( 'WP_ALLOW_MULTISITE', true );

Save, then go to Tools → Network Setup in the admin. Choose subdomains or subdirectories, name your network, and proceed.

Step 3 — Add the Network Configuration Block

WordPress will give you a block of code to add to wp-config.php and a set of rules to add to .htaccess (Apache) or your nginx config. The config block looks roughly like this:

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

Step 4 — Log Back In and Add Sites

After saving the config, log out and back in. You’ll see a new My Sites → Network Admin menu in the admin bar. From Network Admin → Sites → Add New, create your first additional site.

Network-Level vs Site-Level: What Goes Where

Understanding the split between network and site is critical for managing multisite well:

Network Admin controls:

Installing and updating plugins
Installing and updating themes
Updating WordPress core
Network-wide plugin activation
Creating, editing, deleting sites
Managing users across the entire network
Network-wide settings (site registration, upload limits, banned email domains)

Site Admin controls:

Activating and deactivating plugins on their own site (if the Super Admin allows it)
Choosing a theme from network-enabled themes
Managing their site’s content, users, and settings
Site-specific menus, widgets, customizer settings

Plugin and Theme Strategy for Multisite

Plugins in multisite have three states:

Not installed — plugin files aren’t present
Installed, not network-activated — site admins can activate on their own sites
Network-activated — forced on for every site, visible everywhere

Rules of thumb:

Network-activate infrastructure plugins — security (e.g., Emnes Oversight), backups (Backup Migrate Reset), SEO tools, caching. These should run on every site.
Per-site activate content-specific plugins — ecommerce, forums, portfolios. Activate only on sites that need them.
Test plugin multisite compatibility — not every plugin handles multisite gracefully. Check the plugin page for a “Multisite compatible” note, or test on a staging network first.

Domain Mapping: Custom Domains per Site

By default, subdomain multisite gives you site.example.com and subdirectory gives you example.com/site/. Most real networks want real domain names — clientone.com, clienttwo.com, etc., each pointing at a different site in the network.

Since WordPress 4.5, domain mapping is built into core. The steps:

Point the custom domain’s DNS (A record) at your multisite server’s IP
Add the domain to the site in Network Admin → Sites → Edit Site
Install SSL certificate for the new domain (Let’s Encrypt works fine)
Update your web server config to serve the new domain to WordPress

Agencies running client networks use this to give each client their own branded domain while managing everything centrally.

Multisite Backup, Security, and Performance

Backups

Backing up multisite is not the same as backing up one site times N. You need to back up: all wp_*_posts, wp_*_postmeta, wp_*_options tables; the network tables (wp_blogs, wp_site, wp_sitemeta); and the shared wp_users and wp_usermeta. A backup plugin that’s not multisite-aware will miss some of these.

Security

A security breach on one site in a multisite network potentially exposes every site. A malicious plugin activated network-wide runs on every tenant. Harden multisite networks more aggressively than single sites:

Restrict plugin and theme installation to Super Admin only (the default)
Enforce strong passwords and 2FA for every Super Admin account
Log login attempts and admin actions across the network
Audit network-activated plugins regularly; an unused plugin is an unnecessary attack surface

Performance

Multisite scales surprisingly well if you follow a few rules:

Use a persistent object cache (Redis or Memcached) — options lookups multiply across sites
Enable page caching at the server level (nginx, Varnish) — WordPress-level caching plugins are fine but slower
Offload media to object storage (S3, Cloudflare R2) if your network grows large — a single multisite uploads folder with millions of files is hard to back up
Monitor query counts per request — multisite’s site-switching (switch_to_blog()) is expensive if overused in templates or plugins

Frequently Asked Questions

Can I use WooCommerce with WordPress Multisite?

Yes. WooCommerce works on multisite, with each site having its own products, orders, and customers. Activate WooCommerce per-site, not network-wide, to keep performance reasonable on sites that don’t need it. Shared customer accounts require additional plugins; by default, customers are per-site.

Can I convert a single-site WordPress install to multisite?

Yes, though the existing site becomes the first site in the network. Follow the standard multisite enable process; your existing content, users, and settings are preserved as “site 1.”

Can I convert multisite back to a single site?

Technically yes, but it’s manual: export the content you want to keep, spin up a fresh single-site install, import, and verify. There’s no “disable multisite” button.

How many sites can a multisite network handle?

Tens of thousands, with proper infrastructure. WordPress.com runs on a heavily customized multisite codebase with hundreds of millions of sites. The bottleneck is rarely WordPress itself — it’s the database, the web server, and the caching layer. Most agencies run networks of 10–500 sites comfortably on standard LEMP stacks.

Does each multisite site get its own database?

No — all sites share one database. Each site gets its own set of tables with a numeric prefix (wp_2_posts, wp_3_posts, etc.) but they live alongside each other. Some large networks split into multiple databases via HyperDB, but that’s advanced territory.

Pick Multisite for the Right Reasons

WordPress Multisite is a powerful feature that solves a specific class of problems extremely well. It’s not a shortcut or a cost-saving trick — it’s a structural decision that affects how you manage content, users, updates, and infrastructure for years.

Use it when you have many related sites that share infrastructure and benefit from central management. Avoid it when sites need genuine independence, different WordPress versions, or separate ownership. When in doubt, start with separate installs — you can always consolidate into multisite later, but splitting a multisite network back into separate installs is painful.

Our plugins are designed to work cleanly on both single-site and multisite. Backup Migrate Reset handles network-wide backups. Emnes Oversight logs and alerts across the entire network. Custom Meta Box Builder lets you share field definitions across sites or keep them per-site. Get in touch if you’d like help planning a multisite rollout or migrating an existing network.