WordPress Multisite lets you run multiple WordPress websites from a single WordPress installation. Instead of installing WordPress separately for each site, you activate Multisite and manage all sites through a shared codebase, a shared database, and a single admin dashboard called the Network Admin.
It is a powerful feature that has been part of WordPress core since version 3.0. It is also one of the most misunderstood features in the WordPress ecosystem. Many site owners set up Multisite because it sounds convenient without understanding the architectural tradeoffs, the hosting requirements, and the scenarios where separate WordPress installations would serve them better.
This post explains how Multisite works technically, what it requires from a hosting environment, the tradeoffs you should understand before committing to it, and when the alternatives make more sense.
How WordPress multisite works
A standard WordPress installation has one set of core files, one database with one set of tables (prefixed with
wp_
by default), and one admin dashboard. It runs one website.
WordPress Multisite converts this into a network. The core files remain shared across all sites. The database gets additional tables (
wp_blogs
,
wp_site
,
wp_sitemeta
) that track the network, and each site in the network gets its own set of database tables (like
wp_2_posts
,
wp_2_options
,
wp_3_posts
,
wp_3_options
, and so on). The
wp-content/uploads
directory is shared, with subdirectories per site.
All sites share the same WordPress core version, the same
wp-config.php
, and the same PHP process. Plugins and themes are installed once and can be activated per-site or network-wide by the Network Admin (sometimes called the Super Admin).
Subdomain vs subdirectory
Multisite supports two URL structures:
Subdirectory (path-based): Sites live under the main domain as paths.
example.com/site-a/
example.com/site-b/
example.com/site-c/
Subdomain: Each site gets its own subdomain.
site-a.example.com
site-b.example.com
site-c.example.com
The choice is made during Multisite activation and cannot be changed later without significant effort. Subdirectory mode is simpler to configure (no wildcard DNS needed), but it limits sites to being “under” the main domain. Subdomain mode supports a more natural URL structure and, with domain mapping, can give each site its own independent domain name.
There is an important caveat: if WordPress has been installed for more than a month, WordPress only allows subdomain mode. This is because existing permalink structures for the main site would conflict with subdirectory paths for network sites. If you are considering Multisite, decide early.
Server requirements
Multisite has specific requirements beyond a standard WordPress installation. Not all hosting environments support these, and some that technically support them do not handle them well.
Wildcard DNS (subdomain mode)
Subdomain mode requires a wildcard DNS record:
*.example.com A 203.0.113.50
This tells DNS to route any subdomain of
example.com
to your server. Without this, new sites in the network will not resolve until you manually create a DNS record for each one.
Most DNS providers support wildcard records. The complexity comes on the hosting side – the server needs to handle requests for any subdomain, route them to the correct site in the Multisite network, and serve the appropriate content.
Wildcard SSL (subdomain mode)
If you are using HTTPS (and you should be), subdomain mode requires SSL coverage for all subdomains. This means either:
- A wildcard SSL certificate covering
*.example.com - Individual certificates per subdomain, issued as sites are created
Wildcard certificates from Let’s Encrypt require DNS validation (HTTP validation does not work for wildcards), which adds configuration complexity. If your sites use domain mapping with independent custom domains, each mapped domain needs its own SSL certificate.
Server block configuration
The web server needs to accept requests for all subdomains and route them to the single WordPress installation. In Nginx:
server {
listen 443 ssl;
server_name example.com *.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www/example.com;
index index.php;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php-fpm/example.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
In Apache, the equivalent uses
ServerAlias
:
<VirtualHost *:443>
ServerName example.com
ServerAlias *.example.com
DocumentRoot /var/www/example.com
# ...
</VirtualHost>
wp-config.php changes
Activating Multisite requires adding constants to
wp-config.php
:
/* Multisite */
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true); // false for subdirectory mode
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
And modifying
.htaccess
(Apache) or Nginx rules to handle the network routing.
Database capacity
Each site in the Multisite network creates its own set of database tables. A network with 100 sites has approximately 1,200 database tables (12 per site plus the shared tables). This is not inherently a problem, but it affects:
- Backup size and time: A single database dump includes all sites. You cannot selectively back up one site without additional tooling.
- Migration complexity: Moving a single site out of a Multisite network requires extracting its tables and uploads, which is more involved than migrating a standalone WordPress installation.
- Query performance: The shared database means all sites compete for the same MySQL connection pool, buffer pool, and query cache.
When multisite makes sense
Multisite is designed for specific organizational patterns. Understanding these helps you decide whether it fits your situation.
University or school networks
A university running department sites (
biology.university.edu
,
admissions.university.edu
,
library.university.edu
) benefits from centralized management. One IT team manages WordPress core updates, approves plugins, and controls which themes are available. Department staff manage their own content without worrying about infrastructure.
Franchise or chain businesses
A franchise where each location has its own site (
chicago.franchise.com
,
denver.franchise.com
) but all sites share branding, functionality, and management oversight. The corporate team controls the template and plugin set; location managers update their own content.
Corporate intranets
Internal company sites where different departments need separate WordPress sites but IT wants centralized control over updates, plugins, and user management. Multisite’s shared user table means employees can access multiple sites with one set of credentials.
Development agencies managing client sites
Some agencies use Multisite to host multiple client sites from one installation, simplifying updates and maintenance. This works when all sites share similar functionality and the agency controls the hosting environment.
Blog networks
A publishing organization running multiple themed blogs from one editorial team. Shared user management and centralized plugin control are genuine advantages.
The common thread is centralized administration with distributed content management. If that describes your situation, Multisite may be a good fit.
When multisite does not make sense
Multisite introduces constraints that matter in scenarios where its benefits do not apply.
Independent sites that share nothing but an owner
If you run a personal blog, a small business site, and an online store, and these sites have nothing in common except that you own them, Multisite adds complexity without benefit. Each site would be better served by its own WordPress installation where you can choose plugins, themes, and PHP versions independently.
Sites with different performance profiles
A high-traffic WooCommerce store and a low-traffic informational site have very different resource needs. In Multisite, they share the same PHP process pool, the same database, and the same caching layer. A traffic spike on the store affects the informational site. With separate installations, each site has its own resource allocation and one site’s load does not affect the other.
Sites that need different plugin sets
In Multisite, plugins are installed network-wide. Individual site admins can activate or deactivate plugins for their site, but they cannot install new plugins. Only the Network Admin can install plugins, and any installed plugin is available to every site in the network. If one site needs WooCommerce and another needs a learning management system, both plugins are installed in the shared codebase even though each site only uses one.
This has security implications. A vulnerability in WooCommerce affects the entire network, even sites that do not use WooCommerce, because the vulnerable code is present in the shared filesystem. See why WordPress plugin vulnerabilities are out of control for why this matters.
Sites that need different PHP versions
Some plugins require specific PHP versions. An older site might need PHP 7.4 while a newer site works best on PHP 8.3. Multisite runs all sites on a single PHP installation – you cannot run different PHP versions per site.
Sites you might need to migrate independently
Extracting a single site from a Multisite network is significantly more complex than migrating a standalone WordPress installation. The site’s database tables need to be extracted and renumbered. Uploads need to be reorganized. References to the network URL structure need to be updated. Domain mapping settings need to be reconfigured. If there is any chance you will need to move a site to a different host, separate it from the network, or hand it off to someone else, standalone installations are easier to work with.
The shared database problem
The most significant technical constraint of Multisite is the shared database. All sites in the network use the same MySQL database, the same connection credentials, and the same database server resources.
This creates several issues:
No per-site database isolation. A SQL injection vulnerability in any site’s plugin can potentially access data from every other site in the network. The table prefixes provide namespacing, not security. An attacker who can execute arbitrary SQL against
wp_2_users
can just as easily query
wp_3_users
.
Shared performance ceiling. MySQL’s InnoDB buffer pool, query cache, and connection pool are shared across all sites. A poorly optimized query on one site fills the buffer pool with its data, evicting cached data from other sites. During traffic spikes, all sites compete for database connections.
Backup and restore granularity. You back up the entire database or nothing. Restoring a single site from backup while leaving others untouched requires surgical table extraction and reinsertion.
Schema changes affect everyone. A plugin that modifies database tables (adding columns, creating new tables) during activation does so in the shared database. If the change causes issues, every site is affected.
Hosting requirements for multisite
If you decide Multisite is the right choice for your use case, here is what the hosting environment needs:
Managed hosting support
Not all managed WordPress hosts support Multisite. Some explicitly exclude it. Others support it but with limitations (no subdomain mode, no domain mapping, limited number of network sites). Check before signing up.
Resource allocation
Multisite is more resource-intensive than a single WordPress installation because every network site shares the same PHP and MySQL resources. A Multisite network with 20 active sites needs significantly more PHP workers, more database connections, and more memory than a single site.
Ensure the hosting plan provides enough PHP workers for concurrent requests across all sites, sufficient MySQL connections for parallel queries from multiple sites, and enough memory for the combined working set.
Caching configuration
Caching for Multisite requires per-site cache separation. Page caching, object caching, and OPcache all need to correctly differentiate between sites in the network. A misconfigured cache can serve Site A’s content to visitors requesting Site B.
Most caching plugins support Multisite, but server-level caching (Nginx FastCGI cache, Varnish) requires explicit configuration to include the domain or site identifier in the cache key.
SSL management
Subdomain mode with many sites means managing many SSL certificates. If you use Let’s Encrypt, the certificate issuance and renewal process needs to handle new subdomains as they are created. Some hosts automate this; others require manual intervention.
Domain mapping (where each site uses its own custom domain) adds further complexity – each mapped domain needs its own certificate, its own DNS configuration, and its own server block or virtual host entry.
The alternative: separate WordPress installations
For many multi-site scenarios, running separate WordPress installations – each with its own database, document root, PHP configuration, and caching – is simpler, more secure, and more flexible than Multisite.
The tradeoff is management overhead. Each installation needs its own updates, its own backups, and its own plugin management. On a VPS where you manage the server yourself, this scales linearly with the number of sites. On managed hosting where the platform handles updates and security, the overhead is minimal because the platform manages each site independently.
Separate installations give you:
- Per-site database isolation. A vulnerability in one site cannot access another site’s data.
- Per-site PHP versions. Different sites can run different PHP versions based on their plugin requirements.
- Per-site resource allocation. Traffic spikes on one site do not affect other sites.
- Per-site caching. No cache separation issues because there is nothing to separate.
- Independent migration. Moving a site to a different host is a standard WordPress migration.
- Independent security controls. Each site can have its own rate limiting, bot detection rules, and security settings.
The management convenience that Multisite provides (one dashboard, one update process, centralized plugin control) can be replicated through other means: WP-CLI scripts that update multiple installations, management tools like ManageWP or MainWP, or a hosting platform that handles updates per-site automatically.
Where Hostney stands
Hostney does not support WordPress Multisite. This is a deliberate architectural decision, not a missing feature.
Hostney’s container isolation model runs each site in its own PHP container with its own process namespace, its own filesystem, and its own resource limits enforced at the kernel level. Each subdomain gets an independent WordPress installation with its own database, its own PHP version, its own caching configuration, and its own security settings. For background on how this isolation works, see how Hostney isolates websites with containers.
WordPress Multisite requires a shared database, shared PHP process, and shared codebase across all sites in the network. This conflicts with per-site container isolation. Supporting Multisite would mean running all network sites in a single container with a single database – giving up the isolation, per-site resource allocation, and per-site security controls that the architecture is built around.
If your use case is running multiple WordPress sites, Hostney’s per-subdomain model provides per-site isolation that Multisite cannot match. Each site is fully independent: separate database, separate PHP container, separate SSL certificate, separate caching, separate bot detection rules. You manage them individually through the control panel, and each site can be migrated, backed up, or scaled independently. For a broader view of how this fits into the managed cloud hosting model, see cloud WordPress hosting explained.
If you specifically need Multisite for its centralized network administration – shared user management, network-wide plugin control, single-dashboard management of many sites – you will need a host that supports Multisite’s shared architecture. Consider whether the centralized management benefit outweighs the isolation, security, and flexibility tradeoffs before committing.
Summary
WordPress Multisite is a specific tool for a specific pattern: centralized administration of multiple sites that share a codebase, database, and management dashboard. It works well for universities, franchise networks, corporate intranets, and publishing organizations where central IT control is a requirement.
It introduces real constraints: shared database (no per-site isolation), shared PHP process (no per-site version or resource control), shared codebase (plugin vulnerabilities affect every site), complex migrations, and hosting requirements that many providers do not fully support.
For site owners who need multiple WordPress sites but do not need centralized network administration, separate WordPress installations provide stronger isolation, more flexibility, and simpler management – especially on hosting platforms that handle per-site updates, security, and backups automatically. The management convenience of Multisite can be replicated through WP-CLI automation and management tools without the architectural constraints.