
WordPress Multisite is a built-in feature that lets you run multiple WordPress websites from a single WordPress installation. Instead of maintaining separate installations for each site, you manage everything from one dashboard, sharing core files, plugins, and themes across an entire network.
Think of it like an apartment building. Each tenant (site) has their own space and can decorate however they want, but they all share the same foundation, plumbing, and electrical systems. The building manager (Super Admin) handles the infrastructure while tenants focus on their individual spaces.
WordPress.com itself runs on a massive multisite network. Every free WordPress.com blog is actually a site within their multisite installation. It’s one of the largest multisite deployments in the world.
Discover the magic of video creation with Sora!
How WordPress Multisite Works
When you activate multisite, WordPress transforms your single installation into a network. Each site in the network gets its own set of database tables for posts, pages, comments, and settings, but they all share the same wp-content directory, plugins folder, and themes folder.

The network architecture breaks down into two URL structures:
- Subdirectory:
example.com/site1,example.com/site2 - Subdomain:
site1.example.com,site2.example.com
You can also map custom domains to individual sites, so site1.example.com could become completelydifferentdomain.com. This requires additional configuration but opens up powerful possibilities for agencies and businesses managing multiple branded properties.
The Role Hierarchy in Multisite
Multisite introduces a new role above the standard WordPress roles: the Super Admin. Here’s how the hierarchy works:
| Role | Scope | Key Capabilities |
|---|---|---|
| Super Admin | Entire Network | Install plugins/themes, create sites, manage all users, network settings |
| Administrator | Single Site | Manage site content, users, and settings (cannot install plugins/themes) |
| Editor | Single Site | Manage and publish all posts, moderate comments |
| Author | Single Site | Publish and manage their own posts |
| Contributor | Single Site | Write posts but cannot publish them |
| Subscriber | Single Site | Read content and manage their profile |
The key difference from standard WordPress: site-level Administrators lose the ability to install plugins and themes. Only the Super Admin controls what software runs on the network. This centralized control is both a feature and a limitation depending on your use case.
When WordPress Multisite Makes Sense
Multisite isn’t the right solution for every scenario. It shines in specific situations where centralized management and shared resources create genuine efficiency gains.
Ideal Use Cases
Universities and educational institutions often use multisite to give each department, faculty member, or student group their own website while maintaining consistent branding and centralized IT management. Harvard, Stanford, and countless other institutions run multisite networks.
Business with multiple brands or locations benefit when each branch needs a presence but the parent company wants unified control. A restaurant chain with 50 locations could have individual sites for each restaurant while sharing the same theme and core plugins.
Agencies managing client sites can streamline operations by running all client sites from a single installation. Plugin updates happen once instead of fifty times. Security patches deploy across all sites simultaneously.
Multilingual websites sometimes use multisite to handle different language versions, with each language living on its own site within the network. This approach gives more flexibility than some translation plugins.
Content networks and blog platforms where you want to offer users their own blog space, similar to WordPress.com’s model.
When to Avoid Multisite
If your sites need completely different plugins, multisite creates headaches. Since plugins are shared network-wide, you can’t install Plugin A on Site 1 but not make it available to Site 2. You can network-activate plugins (forcing them on all sites) or let individual site admins activate them, but the plugin files exist for everyone.
Sites with vastly different functionality requirements are better served by separate installations. If one site is an e-commerce store, another is a membership platform, and a third is a simple blog, the plugin conflicts and performance implications make multisite counterproductive.
Migrating away from multisite is significantly more complex than migrating a standard WordPress site. Once you commit to multisite, extracting individual sites later requires careful database surgery. Plan your architecture carefully before jumping in.
Setting Up WordPress Multisite
Before enabling multisite, you need a working WordPress installation. If it’s a fresh install, you can choose either subdirectories or subdomains. If your installation is older than one month, WordPress only offers subdomains (because existing permalinks would conflict with subdirectory paths).
Step 1: Edit wp-config.php
Add this line above the /* That's all, stop editing! */ comment:
define( 'WP_ALLOW_MULTISITE', true ); Save the file and refresh your WordPress dashboard. You’ll now see a new menu item under Tools > Network Setup.
Step 2: Run Network Setup
Navigate to Tools > Network Setup. WordPress will ask you to choose between subdomains and subdirectories (if available), name your network, and set the network admin email.
After clicking Install, WordPress gives you two blocks of code. One goes in wp-config.php and the other replaces your existing .htaccess rules (or nginx configuration).
Step 3: Add the Configuration Code
The wp-config.php additions will look something 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 ); The .htaccess rules for subdirectory installations:
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] After adding both code blocks, log out and log back in. You’ll now see a My Sites menu in the admin bar and a new Network Admin dashboard.
Managing Your Multisite Network
The Network Admin dashboard is your command center. From here you can create new sites, manage users across the network, install and activate plugins and themes, and configure network-wide settings.
Creating New Sites
Go to My Sites > Network Admin > Sites > Add New. You’ll enter:
- Site address (the subdirectory or subdomain name)
- Site title
- Site language
- Admin email (existing user or new account)
WordPress creates the site instantly with its own set of database tables. The site immediately inherits whichever theme is set as the network default.
Plugin and Theme Management
Plugins can be managed in two ways on a multisite network:
- Network Activate: Forces the plugin to be active on every site in the network. Individual site admins cannot deactivate it.
- Available for activation: The plugin is installed but site admins choose whether to activate it on their individual sites.
Themes work slightly differently. The Super Admin installs themes and then “Network Enables” them. Only network-enabled themes appear as options for individual site admins. You can also set a default theme that all new sites start with.
User Management Across the Network
Users in a multisite network have a single account but can have different roles on different sites. A user might be an Editor on Site A, an Administrator on Site B, and a Subscriber on Site C. The Super Admin manages this from the Network Admin dashboard.
By default, only Super Admins can create new user accounts. You can change this in Network Admin > Settings by enabling registration and choosing whether to allow both new users and new sites, or just new user accounts.
Database Structure in Multisite
Understanding the database structure helps when troubleshooting or customizing your network. WordPress creates shared tables and per-site tables:
| Table Type | Examples | Purpose |
|---|---|---|
| Network-wide | wp_users, wp_usermeta, wp_site, wp_sitemeta, wp_blogs | Shared user data, network configuration, site registry |
| Per-site (main) | wp_posts, wp_options, wp_comments, wp_postmeta | Content and settings for the main site |
| Per-site (site 2) | wp_2_posts, wp_2_options, wp_2_comments, wp_2_postmeta | Content and settings for site ID 2 |
| Per-site (site N) | wp_N_posts, wp_N_options, wp_N_comments, wp_N_postmeta | Content and settings for site ID N |
Each new site adds approximately 9 new tables to your database. On large networks with hundreds of sites, this means thousands of tables. Most database servers handle this fine, but it’s worth knowing for capacity planning.
Domain Mapping
Since WordPress 4.5, domain mapping is built into core. You no longer need a separate plugin for it. To map a custom domain to a network site:
- Point the custom domain’s DNS to your server (A record or CNAME)
- Add the domain to your server configuration (Apache virtual host or Nginx server block)
- In Network Admin, edit the site and change its URL to the custom domain
- Set up SSL for the new domain
The process requires server-level access, so it’s not something site admins can do themselves. It’s a Super Admin (and server admin) task.
Performance Considerations
Multisite can be more efficient than separate installations because the WordPress core files and plugin code load once into memory and serve multiple sites. However, there are performance factors to watch:
Object caching becomes critical on multisite networks. Without it, each site hits the database independently for the same types of queries. Redis or Memcached with a multisite-aware caching plugin dramatically improves performance.
Page caching needs to be multisite-compatible. Not all caching plugins support multisite correctly. WP Super Cache, W3 Total Cache, and WP Rocket all offer multisite support with varying configuration complexity.
Media uploads are stored in subdirectories within wp-content/uploads/sites/, organized by site ID. This means all media lives on the same server and filesystem. For large networks with heavy media usage, consider offloading to a CDN or cloud storage.
Database queries increase with each site because WordPress needs to determine which site is being accessed and load the correct tables. A well-configured server handles this efficiently, but cheap shared hosting may struggle with networks larger than a dozen sites.
Never run multisite on shared hosting for production networks with more than a handful of sites. The shared server resources and limited database connections will create bottlenecks that affect all sites on your network simultaneously. One site getting traffic spikes takes down everything.
Multisite vs. Multiple Installations
The decision between multisite and separate installations comes down to your specific needs. Here’s a direct comparison:
| Factor | Multisite | Separate Installations |
|---|---|---|
| Updates | One update covers all sites | Each site updated individually |
| Plugin flexibility | All sites share the same plugin pool | Each site has independent plugins |
| Theme flexibility | Network-enabled themes shared | Complete independence per site |
| User management | Single account across all sites | Separate account per site |
| Server resources | Shared core, potentially lighter | Duplicated core per installation |
| Isolation | Sites share database and files | Complete isolation between sites |
| Migration | Complex extraction process | Standard migration per site |
| Scalability | Limited by single server | Sites can be distributed across servers |
Common Multisite Plugins
Some plugins are particularly useful for multisite management:
- WP Ultimo: Turns your multisite into a SaaS platform where users can sign up and create their own sites with plans and billing
- MainWP: While technically for managing separate installations, it works alongside multisite for monitoring and maintenance
- Network Shared Media: Allows sites to access media uploaded to other sites in the network
- Jetrail for WordPress: Provides centralized logging for debugging issues across network sites
- User Switching: Especially useful on multisite to quickly test different user roles across different sites
Security Implications
Multisite introduces unique security considerations. Since all sites share the same codebase, a vulnerability in one plugin affects every site on the network. Conversely, security hardening at the network level protects all sites simultaneously.
The Super Admin role has enormous power. Compromising a Super Admin account gives an attacker control over every site in the network. Use strong passwords, two-factor authentication, and limit the number of Super Admin accounts to the absolute minimum.
Individual site admins cannot install plugins, which is actually a security benefit. It prevents less technical users from installing vulnerable or malicious plugins that could compromise the entire network.
Backup and Recovery Strategy
Backing up a multisite network requires backing up the entire database and the shared wp-content directory. You cannot easily back up individual sites in isolation because they share tables and files.
For individual site recovery, plugins like UpdraftPlus (premium version) support multisite and can back up and restore individual sites within the network. The free version of most backup plugins only handles network-wide backups.
Your backup strategy should include:
- Full database backups (all tables, including per-site tables)
- Complete wp-content directory backups (includes all sites’ uploads)
- Configuration files (wp-config.php, .htaccess)
- Regular testing of backup restoration on a staging environment
Troubleshooting Common Issues
A few issues come up repeatedly in multisite networks:
Cookie conflicts: If sites in your network share similar domains but have different cookie paths, users may experience random logouts. Define COOKIE_DOMAIN carefully in wp-config.php.
Upload file size limits: The network admin sets a per-site upload quota and maximum file upload size under Network Admin > Settings. If users report they can’t upload files, check these limits first.
Plugin conflicts: Since all sites share plugins, a conflict on one site might not manifest on another. Debug by deactivating plugins on the affected site and testing one by one. Use WP_DEBUG to catch errors that might be site-specific.
Subdomain SSL: If using subdomain multisite with SSL, you’ll need either a wildcard SSL certificate (*.example.com) or individual certificates for each subdomain. Wildcard certificates are the practical choice here.
You now have a solid understanding of WordPress Multisite, from how it works under the hood to when it makes sense and how to set it up. The key takeaway: multisite is a powerful tool for the right situations, but it adds complexity that isn’t justified if your sites don’t genuinely benefit from shared management.

Frequently Asked Questions
Yes, you can convert an existing WordPress installation to multisite. Your existing site becomes the main site in the network. However, if your installation is older than one month, you’ll only have the subdomain option available. Back up everything before making the conversion.
No, all sites share the same database. Each site gets its own set of tables within that database (prefixed with the site ID, like wp_2_posts), but they all live in one database. User tables are shared across the entire network.
Yes, WooCommerce works on multisite, but each site runs its own independent store. There’s no built-in way to share products, orders, or customers across sites. Each WooCommerce site needs its own payment gateway configuration. Some extensions like WooCommerce Multistore can bridge stores together, but it adds complexity.
There’s no hard-coded limit. WordPress.com runs millions of sites on multisite. The practical limit depends on your server resources, database performance, and how much traffic each site receives. Small VPS servers can comfortably handle dozens of sites. Dedicated servers or cloud infrastructure can handle hundreds or thousands with proper optimization.
Multisite itself doesn’t directly impact SEO positively or negatively. Search engines treat each site in the network as a separate website. Using subdirectories can keep authority consolidated under one domain, while subdomains are treated as separate entities by Google. Choose your URL structure based on your SEO strategy for each site.


















