Why Multisite instead of N separate WordPress instances
An agency managing fifteen WordPress sites on fifteen separate installations faces a scaling problem: fifteen dashboards to monitor, fifteen update cycles to coordinate, fifteen web server configurations to maintain. If a critical plugin releases a security patch, it must be applied fifteen times — one by one, manually or via third-party orchestration tools.
WordPress Multisite solves this problem at the root. A single WordPress installation runs a network of sites. Each client has their own subdomain (client1.example.com, client2.example.com), their own content, their own users, and their own theme configuration. But the WordPress core files, plugins, and themes are shared and managed centrally by the network's super administrator.
On a dedicated VPS, this model makes complete sense: network isolation contains the attack surface, and you keep full control over PHP, MariaDB, and Nginx without going through a third-party control panel.
What you gain in practice
- A single update for WordPress core, plugins, and network themes — applied simultaneously to all sites in the portfolio.
- A single administration entry point: the network super admin supervises all sites from
/wp-admin/network/. - Optional shared media storage per site — pool resources or isolate according to your client contracts.
- Server resource savings: a single PHP-FPM process, a single object cache instance, a single MariaDB connection to tune.
- Faster onboarding: creating a subsite is just filling out a form in the network, not provisioning a server.
- Centralized backups: a single MariaDB dump covers all sites, schedulable with one cron rule.
Prerequisites: recommended VPS resources for 5 to 15 active sites
The resources needed depend on traffic and site complexity — not on the number of installations. For a network of 5 to 15 active WordPress sites (showcase sites or blogs with moderate traffic, without intensive WooCommerce), the editorial recommendation based on WordPress and Nginx/MariaDB documentation is:
- CPU: 2 vCPU minimum; 4 vCPU once you combine page caching and concurrent traffic.
- RAM: 4 GB as a baseline; 8 GB recommended if you enable a Redis object cache alongside PHP-FPM.
- Storage: SSD NVMe, 40 GB minimum for WordPress files + media + MariaDB logs; adjust based on client media volume.
- PHP: PHP 8.2 or 8.3 (PHP 8.1 reached end of active support at the end of 2024).
- MariaDB: 10.6 LTS or 10.11 LTS.
- Web server: Nginx with server blocks per subdomain and wildcard DNS.
If your portfolio exceeds 15 sites or includes WooCommerce stores, consider splitting the Multisite network into two partitions or starting with 8 GB / 4 vCPU.
Enabling WordPress Multisite and configuring Nginx for subdomains
Set up wildcard DNS
Before making any WordPress changes, add a wildcard DNS record on your main domain:
*.example.com A <YOUR_VPS_IP>This entry routes all subdomains to your VPS. Without it, the network's subsites will remain inaccessible from a browser, even if WordPress creates them correctly.
Allow network mode in wp-config.php
Edit
wp-config.phpat the root of your WordPress installation and add the following line before/* That's all, stop editing! */:define( 'WP_ALLOW_MULTISITE', true );This constant is the condition documented in the official WordPress documentation to enable the network installation wizard.
Create the network from the dashboard
Log in to
/wp-admin/, go to Tools → Network Setup. Choose Subdomains (wildcard DNS required). Enter the network title and administrator email address, then click Install.WordPress will provide two code blocks to insert into
wp-config.phpand into.htaccess(Apache) or your Nginx configuration file. Copy them exactly.Adapt the Nginx configuration for wildcard subdomains
On Nginx, the
.htaccessblock provided by WordPress is not read. Replace it with a dedicatedserverblock. Here is the minimal configuration for a subdomain network:server { listen 80; server_name example.com *.example.com; root /var/www/wordpress; index index.php; # Multisite subdomain rewrite if (!-e $request_filename) { rewrite /wp-admin$ $scheme://$host/wp-admin/ permanent; rewrite ^(/[^/]+)?(/wp-.*) $2 last; rewrite ^(/[^/]+)?(/.*\.php) $2 last; } location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { fastcgi_pass unix:/run/php/php8.3-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }Reload Nginx:
systemctl reload nginx. Then switch to HTTPS by generating a wildcard certificate with Certbot using the DNS-01 challenge — a*.example.comSAN certificate covers all subsites in the network.Finalize the WordPress Multisite configuration in wp-config.php
Add the constants provided by the wizard to
wp-config.php(adapt values to your installation):define( 'MULTISITE', true ); define( 'SUBDOMAIN_INSTALL', true ); define( 'DOMAIN_CURRENT_SITE', 'example.com' ); define( 'PATH_CURRENT_SITE', '/' ); define( 'SITE_ID_CURRENT_SITE', 1 ); define( 'BLOG_ID_CURRENT_SITE', 1 );Log out, then log back in. The dashboard now shows the Network menu in the admin bar. From Network → Sites → Add New, create your first client subsite:
client1.example.com.Activate network plugins and assign themes
In Network → Plugins, activate plugins for the entire network (Network Activate) or let subsite administrators activate them themselves. Themes work the same way: the super admin makes them available, and each subsite chooses its own.
Important note: some plugins do not support network mode. Check compatibility in the plugin documentation before activating it on the network — an incompatible plugin can block the dashboard of all subsites simultaneously.
Multisite vs separate WordPress instances: comparison table
Scroll the table
| Criterion | WordPress Multisite | Separate instances |
|---|---|---|
| WordPress core update | 1 operation for N sites | N manual operations |
| Plugin update | 1 network operation | N operations, risk of desynchronization |
| Client data isolation | Partial (same MariaDB database, distinct prefixes) | Complete (distinct databases, distinct PHP processes) |
| Media storage | Shared by default, isolatable with a plugin | Natively isolated |
| Server resources | Pooled — RAM and CPU savings | Additive — each instance consumes its share |
| Network-incompatible plugin | Potentially blocks all sites | Affects only one instance |
| Onboarding a new site | Form in the network — seconds | Full provisioning — minutes to hours |
| SSL wildcard certificate | 1 certificate `*.example.com` | 1 certificate per client domain |
Multisite security on a VPS: containing the impact of a vulnerability
The most common objection to WordPress Multisite is valid: if a vulnerable plugin is compromised, the potential attack surface covers the entire network, not just one site. On a dedicated VPS, several measures contain this impact:
Daily automated backups. A MariaDB dump scheduled each night (cron + mysqldump or mariabackup) gives you a recent restore point for every subsite. Store dumps off the VPS — on an S3-compatible bucket or a remote volume.
Application firewall. An Nginx WAF (ModSecurity or OWASP rules) filters malicious requests before they reach PHP. Combine it with fail2ban to ban IPs attempting brute force on /wp-login.php.
Timely updates. The strength of Multisite — one update for the entire portfolio — is also your best defense: apply WordPress and plugin security patches on the day they are published. Without Multisite, the update lag on a forgotten instance is the most exploited vulnerability.
Limited super admin. The network super administrator account has rights over all sites. Use two-factor authentication on this account and create separate subsite administrator accounts for each client.
Troubleshooting: three common errors on a WordPress Multisite network
1. Plugin reported as "incompatible with network mode".
Some plugins explicitly check whether WordPress is running in Multisite mode and refuse to activate on the network. The cause is often use of $wpdb->blogid or options stored in a way incompatible with each subsite's prefixed tables. Solution: check the plugin's GitHub issues, look for a compatible alternative, or activate the plugin only on the subsites that need it (if the plugin allows it) rather than at the network level.
2. Network administration page inaccessible (/wp-admin/network/ redirects to the standard dashboard).
The super admin is not the same user as the main site administrator. When the network is created, WordPress adds a super_admin flag to the active user. If you created the network with one account and then log in with another, that second account won't see the network menu. Check in MariaDB:
SELECT meta_value FROM wp_usermeta
WHERE meta_key = 'wp_user_level'
AND user_id = <YOUR_ACCOUNT_ID>;To elevate a user to super admin: use the grant_super_admin( $user_id ) function from a mu-plugins file.
3. Inaccessible subdomains: wildcard DNS doesn't propagate immediately.
After adding *.example.com A <IP>, the record's TTL determines propagation time. During this period, sites created in the network return a DNS error in the browser — WordPress has created them correctly, but the resolver doesn't know the subdomain yet. If you're working locally with a development VPS, add an entry in /etc/hosts on your workstation for each subdomain to test: <VPS_IP> client1.example.com.
A fourth case occurs with mixed www / non-www configurations: if both example.com and www.example.com point to the VPS, ensure that DOMAIN_CURRENT_SITE in wp-config.php matches exactly the main domain without the www prefix, and that Nginx redirects the www form to the canonical form before passing the request to WordPress.
Migrating existing sites to a Multisite network
If you already manage separate WordPress sites and want to consolidate them into a Multisite network, the WordPress Importer plugin (official plugin) exports content, comments, and users from each source instance, then imports them into a network subsite.
Three points to watch before migrating:
- Uploads don't migrate automatically. Copy the wp-content/uploads/ folder from each source site to wp-content/uploads/sites/<ID>/ in the network (the ID is assigned by WordPress when the subsite is created).
- Check network plugin compatibility before switching: a plugin active on the old site may not work in network mode. List each source site's plugins and cross-reference with the available network plugins.
- Test domain redirections. If the migrated site had its own domain (www.client1.com), configure the WordPress MU Domain Mapping module or the native custom domain feature so that client1.example.com redirects to www.client1.com — or vice versa depending on your choice.
Going live: validation steps before opening to your clients
Before migrating your first client sites to the network, review these points:
- Test creating a subsite via client1.example.com and verify it's accessible from an external browser.
- Verify that the wildcard certificate covers *.example.com: openssl s_client -connect client1.example.com:443 -servername client1.example.com | grep subject.
- Simulate a network plugin update and verify all subsites remain functional.
- Plan and test restoration of a subsite from a MariaDB dump: untested restoration is not a backup.
- Document the onboarding procedure for your clients: administration URL, credentials, rights granted to their subsite administrator account.
A ServOrbit VPS sized for your WordPress portfolio gives you control over the full stack — PHP, MariaDB, Nginx, backups — without an abstraction layer that hides errors.
