Running multiple websites from a single WordPress installation — each with its own domain, content, users, and theme — is exactly what WordPress multisite is designed for. Agencies managing dozens of client sites, universities with department-specific sites, franchise networks with location pages, and media groups with distinct publication brands all use WordPress multisite to reduce hosting costs, centralise updates, and share plugins across the entire network. This guide covers creating a multisite network, managing it correctly, and avoiding its common pitfalls. This fits into the wider topic we cover in our Complete Guide to WordPress How.
WordPress Multisite — Understanding the Network Architecture
WordPress multisite transforms a standard WordPress installation into a network where the main site is the “super admin” hub and any number of subsites can be created, each with their own URL, content, and user base. The database tables for all sites share the same database — subsites get their own prefixed tables (wp_2_posts, wp_3_posts, etc.) while sharing global tables (wp_users, wp_usermeta) for network-wide user management.
Two URL structures are available for WordPress multisite networks: subdomain (site1.network.com, site2.network.com) and subdirectory (network.com/site1/, network.com/site2/). The choice is permanent once the network is created — switching between structures requires migrating the entire network. Subdomain structure requires a wildcard DNS record pointing all subdomains to the server; subdirectory structure works with a single domain and no wildcard DNS. For networks hosting entirely different brands, subdomains with domain mapping (each site gets its own custom domain) is the professional standard. For content hubs where subsites represent sections of the same brand, subdirectory structure is simpler to configure and manage.
The WordPress multisite network has two distinct administration levels: the Network Admin (accessible only to Super Admins) which manages plugins, themes, site creation, and network settings; and each individual site’s admin which manages that site’s content, users, and configuration within the bounds the Network Admin allows. Super Admins have full access to every site and the network. Site Admins manage only their assigned site — they can activate themes and plugins the Network Admin has permitted, but cannot install new ones. This permission hierarchy is critical for client or member-owned networks where site owners need full control of their site without the ability to affect the overall network or other sites. According to the WordPress developer documentation, Super Admin capabilities are additive to the standard Administrator role — a Super Admin can do everything a site Administrator can do on any site, plus network-level actions unavailable to site admins.
Enabling and Configuring WordPress Multisite
Enabling WordPress multisite requires adding a constant to wp-config.php, running the network setup wizard, and configuring the web server. The process is straightforward but any mistake during initial configuration requires careful cleanup to reverse.
Enable multisite: edit wp-config.php → add define('WP_ALLOW_MULTISITE', true); above the “That’s all, stop editing!” comment → save → refresh the WordPress admin → navigate to Tools → Network Setup. Choose the network type (subdomains or subdirectories) → fill in the network title and admin email → click Install. WordPress displays two configuration blocks to add: a block for wp-config.php (additional constants defining the network) and a block for .htaccess (rewrite rules for subsite URL routing). Add both blocks to their respective files → log out → log back in. The Network Admin menu appears in the admin bar, confirming WordPress multisite is active.
For subdomain networks, add a wildcard DNS record at the registrar: create an A record with the host value * pointing to the server’s IP address — this routes all subdomains (existing and future) to the same server where WordPress handles the routing. Without the wildcard DNS record, new subsites return DNS resolution errors. Verify wildcard DNS is working: create a test subsite in Network Admin → Sites → Add New → confirm the test subsite’s URL resolves in the browser before creating production subsites. The wildcard DNS propagation takes up to 48 hours but is usually complete within 2–4 hours — test from a different network or DNS checker rather than the local browser which may cache the previous DNS resolution.
Managing Plugins, Themes, and Users Across the Network
WordPress multisite manages plugins and themes at the network level — a plugin installed in Network Admin → Plugins can be either Network Activated (active on all sites automatically) or available for individual site admins to activate on their own sites. The distinction matters: security plugins, caching plugins, and must-use plugins that apply network-wide should be Network Activated; site-specific functionality plugins should be available but not network-forced.
Network Activate a plugin: Network Admin → Plugins → activate the plugin → the “Network Deactivate” action replaces the individual site “Deactivate” action for network-activated plugins. Site admins see network-activated plugins as active but cannot deactivate them. This means a poorly configured network-activated plugin that conflicts with a specific site’s theme or other plugins cannot be resolved by that site’s admin — only the Super Admin can deactivate or troubleshoot it. In a well-managed WordPress multisite, reserve network activation for truly universal plugins (security, performance) and allow site-level activation for everything else. Must-use plugins (placed in /wp-content/mu-plugins/) are always network-active and cannot be deactivated by anyone — use this location for network-critical code only.
User management across a WordPress multisite network is centralised: a single user account can have different roles on different sites. A person who is an Editor on Site A may be a Subscriber on Site B — the roles are stored per-site in wp_usermeta. Add an existing network user to a site: the site’s Users → Add Existing User → enter the user’s username or email → select the role for that site → Add User. The user does not need a new account — they log in with their existing credentials and see whichever sites they have access to. New user registration can be configured network-wide: Network Admin → Settings → Registration → “User accounts may be registered” (any visitor can register), “Logged in users may register new sites” (existing users can create subsites), “Both” (open network), or “Registration is disabled.” Correctly configuring registration prevents unwanted user or site creation on networks that should be invite-only. Our guide on managing WordPress user roles covers the role and capability management that applies to multisite per-site role assignments.
Domain Mapping and Custom Domains for Subsites
The most powerful WordPress multisite feature and network operators is domain mapping — assigning a unique custom domain to each subsite so it appears completely independent to visitors, while all sites are managed from a single WordPress installation.
Configure domain mapping — the flagship WordPress multisite feature: WordPress 4.5+ supports it natively. In the subsite settings: Network Admin → Sites → select the site → Settings → Domain → enter the custom domain (e.g., client-domain.com). Point the custom domain’s DNS A record to the server’s IP at the domain registrar. Configure the web server to accept the custom domain: on Apache, add a ServerAlias in the VirtualHost config; on Nginx, add the domain to the server_name directive. The subsite now loads at the custom domain, with WordPress handling the URL mapping internally. Visitors at client-domain.com see the subsite’s content without any indication they are on a multisite network.
SSL certificates for domain-mapped WordPress multisite subsites require coverage for each mapped domain separately. Let’s Encrypt (via cPanel or Certbot) can generate individual certificates per domain, or a wildcard certificate covers all subdomains of the main domain. For custom-mapped domains (client-domain.com on a site1.network.com subsite), each custom domain needs its own Let’s Encrypt certificate — Certbot handles this automatically when run with the domain as a parameter. Managing SSL renewal for dozens of custom-mapped domains is a significant operational overhead compared to a subdomain-only network where a single wildcard certificate covers all subsites. Cloudflare’s Universal SSL covers the main domain and its subdomains; custom mapped domains on Cloudflare also require a dedicated Cloudflare account per custom domain or the use of Cloudflare’s “Custom Hostnames” feature (available on Business and Enterprise plans) that extends the main Cloudflare account’s SSL coverage to custom mapped domains. Our guide on setting up WordPress Cloudflare covers the SSL configuration that intersects with domain-mapped multisite network SSL management.
WordPress Multisite Performance and Troubleshooting
WordPress multisite performance scales differently from single-site WordPress because all subsites share the same database, plugins, and server resources. A traffic spike on one subsite consumes server resources that affect all other subsites simultaneously — isolation between sites exists at the content level but not at the server resource level on shared hosting.
Caching is more critical on multisite than on single-site WordPress. Each subsite generates its own set of pages, and without caching, a network with 20 subsites requires 20× the server’s single-site PHP capacity to handle the same per-site traffic level. Configure the caching plugin to cache each subsite independently: WP Rocket and LiteSpeed Cache both support multisite with per-subsite cache directories and purge mechanisms. Verify the cache is operating for each subsite individually — log out of all sites → visit each subsite’s homepage → check the response headers for cache hit indicators. A missed cache on even one high-traffic subsite creates bottlenecks that degrade the entire network’s performance.
Common WordPress multisite troubleshooting scenarios: subsites returning 404 (rewrite rules not correctly configured — regenerate .htaccess or Nginx config for the multisite network structure); plugins not appearing on subsites (plugin is installed but not network-activated and not permitted for site activation — check Network Admin → Plugins); user cannot log in to a specific subsite (user account exists at the network level but is not added to that subsite — use Network Admin → Sites → Users → add the user to the specific site). The “Too many redirects” error on a new subsite almost always indicates the WordPress site URL and WordPress address URL settings for that subsite do not match the subsite’s actual URL — fix in Network Admin → Sites → select the site → Settings → correct both URL fields. Reviews from the WordPress developer community confirm that wildcard DNS misconfiguration and incorrect URL settings together cause the majority of WordPress multisite subsite access failures during and after initial network setup.
Migrating a single WordPress site to become a subsite in an existing WordPress multisite network — or creating a new network from an existing single site — is one of the most technically challenging WordPress migration operations. Tools that assist this process: the Move Subsite plugin migrates a multisite subsite to a standalone installation; the WP Site Cloner plugin creates a new subsite from an existing subsite template; and WP-CLI provides wp site import and wp site export commands for migrating subsite data between networks. The key technical challenge in all these migrations is correctly updating all URLs in the database from the old site’s domain to the new location, and ensuring the serialised PHP data in the database is correctly updated rather than simple string replacement that would break the PHP serialisation format. The wp search-replace WP-CLI command handles serialised data correctly and is the recommended tool for any WordPress multisite URL migration operation.
Automatic update management across a WordPress multisite network requires Network Admin privileges and careful sequencing. WordPress core updates apply to the entire network simultaneously — when the network’s WordPress is updated, all subsites update at once. This makes staging-first testing even more important than on single-site installations: a core update that breaks one plugin breaks that plugin on every subsite simultaneously. Configure network update notifications: Network Admin → Updates → verify the network’s auto-update setting. For critical production networks, disable auto-updates and schedule manual updates after testing on a staging network clone. Plugin updates in a WordPress multisite network follow the same pattern — a network-activated plugin updated on the network is updated for all sites at once, while site-level plugins are updated per-site by each site’s admin. Our guide on fixing themes broken after updates covers the update testing process that is equally critical for multisite networks where a bad update affects every subsite simultaneously.
Storage allocation in a WordPress multisite network is managed per-subsite: Network Admin → Sites → select a site → Settings → Site Info → “Upload space allowed” sets the maximum media upload storage for that specific subsite in megabytes. Setting a realistic limit per subsite prevents any one site from consuming the entire hosting account’s storage, particularly important on networks where site administrators may upload large media files without awareness of shared storage constraints. The network-wide default is set in Network Admin → Settings → “Site upload space” — sites without individual overrides inherit this default. Monitoring total network storage usage requires checking the hosting account’s total disk usage rather than WordPress’s per-site tracking, since database size and plugin files are shared across all sites and are not reflected in the per-site upload space accounting.
