WordPress Multisite lets you run many separate websites from a single WordPress installation — one set of core files, one database, one admin login, but distinct sites each with their own content, theme, users, and URL. It’s a real feature, well-supported, but it’s also frequently used wrong. This guide covers when multisite is the right tool, when separate WordPress installs are better, and how to set it up on shared cPanel hosting.
When multisite is the right tool
- Same person/team manages all sites. Single super-admin who maintains the network.
- Sites share most plugins and themes. Updating once benefits all.
- Sites have similar functionality. Blog network, university departments, regional storefronts of the same brand.
- You want central user management. Add a user once; assign them roles across multiple sites.
- 10+ similar sites. Maintenance burden of separate installs becomes excessive.
When multisite is the WRONG tool
- Sites belong to different clients. Total disaster — one site’s plugin bug breaks all. Use separate installs.
- Sites need different plugins. Plugin activation is global or per-site, but plugin code is shared. Conflicts cascade.
- One site might need migration later. Extracting a single site from multisite is painful.
- You need different PHP versions per site. Multisite shares one PHP version.
- Sites have wildly different traffic. One viral site can take down everything else.
- You want SSL on different domains via Let’s Encrypt. Possible but more complex than single sites.
- WooCommerce sites with different products/payments per site. WooCommerce + multisite is fragile.
Rule of thumb: if you’d describe your sites as “related” — multisite. “Separate” — separate installs. When in doubt, separate installs are safer.
Subdomain vs subdirectory mode
Multisite uses one of two URL structures, picked during setup:
| Subdomain mode | Subdirectory mode | |
|---|---|---|
| URL pattern | site1.yourdomain.com, site2.yourdomain.com | yourdomain.com/site1/, yourdomain.com/site2/ |
| Needs wildcard DNS | Yes | No |
| Custom domain mapping | Easier | Possible but more complex |
| SEO implication | Each subdomain treated as separate domain | Inherits parent domain authority |
| Best for | Distinct brands/products under one umbrella | Content sections of one organization |
Subdirectory mode only works for new installs (not converting existing single sites — WordPress core blocks this to prevent URL conflicts).
Subdomain mode works for either new or converted installs.
Setting up multisite on iWebVault cPanel
Step 1: Start with a single WordPress install
Install WordPress via Softaculous as usual. WordPress install guide.
Critical: deactivate ALL plugins before enabling multisite. Plugin conflicts during conversion break things.
Step 2: Enable multisite in wp-config.php
Edit wp-config.php via cPanel File Manager. Add this line ABOVE the “/* That’s all, stop editing!” comment:
define('WP_ALLOW_MULTISITE', true);
Save.
Step 3: Run network setup
- Log into WordPress admin.
- Tools → Network Setup (this menu only appears after step 2).
- Choose subdomain or subdirectory mode.
- Set network title and admin email.
- Install.
WordPress shows you two code blocks: one for wp-config.php, one for .htaccess. Copy both.
Step 4: Add the wp-config.php constants
Add the WordPress-provided block to wp-config.php (above “/* That’s all…”):
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true); // or false for subdirectory
define('DOMAIN_CURRENT_SITE', 'yourdomain.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
Step 5: Replace .htaccess
Replace your .htaccess content with the rules WordPress provided. Standard subdomain multisite rules look like:
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*.php)$ $1 [L]
RewriteRule . index.php [L]
Step 6: Log back in
You’ll be logged out. Sign back in. WordPress admin now has new “My Sites” and “Network Admin” menus at top.
Wildcard subdomain setup (for subdomain mode)
Subdomain multisite needs wildcard DNS so that any subdomain.yourdomain.com routes to your install.
DNS
cPanel → Zone Editor → add A record:
Name: *
Type: A
Address: [your server IP]
TTL: 3600
Apache / cPanel
cPanel → Domains → Subdomains → add subdomain * pointing to your domain’s document root.
If subdomain creation rejects the asterisk: open a ticket. Some configurations require server-side wildcard mapping.
SSL for wildcard subdomains
AutoSSL handles wildcard certs via DNS-01 challenge. Verify in SSL/TLS Status that wildcard cert is issued. Wildcard SSL guide.
Adding sites to the network
- WordPress admin → My Sites → Network Admin → Sites → Add New.
- Enter subdomain (e.g. “blog”), title, admin email.
- Create site. Available at blog.yourdomain.com immediately.
Each new site has its own content, theme settings, options — but inherits available plugins/themes from network.
Custom domain mapping
Often you want site1.yourdomain.com to actually live at clientdomain.com. Modern WordPress includes built-in domain mapping:
- Point clientdomain.com’s DNS A record to your server.
- cPanel → Aliases → add clientdomain.com as alias of yourdomain.com.
- Network Admin → Sites → edit the relevant site.
- Change primary site address from site1.yourdomain.com to clientdomain.com.
- Verify AutoSSL covers the new domain.
Resource considerations on shared hosting
- Disk usage — All sites share your account’s disk quota. Plan for total.
- Memory limit — Multisite has slightly higher memory floor than single WordPress.
- Concurrent traffic — One viral site uses all your CPU. Other sites slow down too.
- Backup size — Whole multisite = single backup. Restoring one site requires extracting from network backup.
For 5-10 small low-traffic sites: shared hosting is fine. For 50+ sites or any with serious traffic: VPS or dedicated.
Network-only plugins and themes
In multisite, plugin activation has two modes:
- Network Activate — Plugin runs on all sites. Individual sites can’t disable.
- Network Install (don’t activate) — Plugin available but each site activates separately.
Network admin controls what plugins/themes are installed; individual site admins choose from those.
Common issues
“Subdomain sites return 404 / parking page.” Wildcard subdomain not configured at cPanel level. Add subdomain “*” or open a ticket.
“Different site admin keeps showing main site.” Logged into main site, not the subsite. Switch via My Sites menu.
“SSL warning on subdomain sites.” AutoSSL may need to be re-triggered after adding wildcard. cPanel → SSL/TLS Status → Run AutoSSL.
“How do I extract one site to its own WordPress install?” Painful. Plugins like “WP All Migrate” or “Duplicator Pro” have multisite export tools. Otherwise SQL extraction + media file copy. Major project for any non-trivial site.
“Can I have different themes on different sites?” Yes — each site chooses its own theme from the network-installed list.
“My plugin says ‘Compatible with multisite’ — what does that mean?” The plugin can be Network Activated and properly handles per-site data. Plugins NOT marked multisite-compatible may corrupt data or behave unpredictably in multisite. Use only multisite-compatible plugins.
When to leave multisite
Signs your multisite has outgrown shared hosting or the structure itself:
- One site needs features incompatible with multisite.
- One site’s traffic dwarfs others; affects all.
- Different clients with different SLAs — separate installs cleaner.
- Resource limits constantly hit.
Migrating to separate installs: schedule it as a multi-step project. Each site export via Duplicator → new cPanel account → fresh install → import. Test thoroughly before pointing DNS.
What’s next
- WordPress install basics: Install WordPress.
- Wildcard SSL setup: Wildcard SSL.
- Security across multisite: WordPress hardening.
Multisite is powerful when sites genuinely belong together. It’s a maintenance nightmare when forced onto unrelated sites. Honest assessment of “would I want all these to update at once” decides which side of the line you’re on. For related sites managed by one team, multisite cuts maintenance dramatically. For everything else, separate WordPress installs remain the simpler answer.
Was this helpful?
Thanks for your feedback!