A WordPress Multisite network is a single WordPress installation that hosts multiple websites (called sites or subsites) which share the same codebase (core, plugins, themes) and database, while retaining separate content, settings and media folders. One account — the Super Admin — manages the whole network; site admins manage individual subsites.
Why use it?
- Centralized updates and plugin/theme management — update once for every site.
- Easier provisioning for large numbers of similar sites (clients, departments, school sites, microsites).
- Shared users: a user on one site can be given access across others.
- More efficient infrastructure for many small sites (single codebase, one DB).
When you should (and should NOT) use Multisite
Use Multisite when:
- You manage many similar sites (franchises, schools, blogs, documentation microsites).
- You want centralized plugin/theme control and updates.
- You plan to host many small sites that can share resources and have similar requirements.
You must use a hosting service that supports WordPress multisite hosting. (For example Cloudways, Kinsta etc.)
Avoid Multisite if:
- Each site requires heavily different plugins, custom themes, or isolated custom code.
- Clients must have total, isolated control (legal/hosting isolation).
- You need totally independent databases/backups per site (multisite uses one DB).
- You plan to sell single-site hosting where customers require full root-level control.
Step-by-step: How to create a WordPress Multisite network
Prerequisites (do this first)
- Full backup of files + database (do not skip).
- Latest WordPress installed and working (single-site).
- FTP/SFTP or cPanel access to edit
wp-config.phpand.htaccess. - Hosting that supports WordPress pretty-permalinks (
Apache mod_rewriteor equivalent) or proper Nginx configuration. - Decide: subdomains (
site1.example.com) vs subdirectories (example.com/site1). If you want subdomains you will need wildcard DNS and server config. - Temporarily deactivate caching/security plugins before switching.
1 — Prepare DNS / local environment
Subdomains: Add a wildcard DNS A record:
*.example.com →
(Or on managed DNS: add A record for * to your server IP.)
Subdirectories: No wildcard DNS needed.
Local dev: Hosts file doesn’t accept wildcards — either add each test subdomain manually or use a dev tool (LocalWP, Valet, Docker) that supports wildcard subdomains.
2 — Allow Multisite in WordPress
Edit wp-config.php (in WordPress root) and add just above the /* That's all, stop editing! */ line:
/* Enable Multisite */
define( 'WP_ALLOW_MULTISITE', true );
Save and upload.
3 — Create the network in WP admin
Log into WP admin as an administrator.
Go to Tools → Network Setup. (This menu appears only after the constant above is present.)
Choose Sub-domains or Sub-directories (choose carefully).
Give your Network a Title and make sure the Admin Email is correct.
Click Install.
WordPress will now show you two code snippets — one for wp-config.php and one for .htaccess. Follow the exact instructions.
4 — Add the provided code (example)
Example wp-config.php lines (WordPress will give exact values — copy/paste what WP shows):
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true); // true for subdomains, false for subdirectories
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
Place those in wp-config.php above the require_once( ABSPATH . 'wp-settings.php' ); line.
Example .htaccess (Apache) — replace your existing WordPress rules with these:
BEGIN WordPress
RewriteEngine On
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 . index.php [L]
END WordPress
Nginx users: add a server block with server_name example.com *.example.com; and the usual try_files $uri $uri/ /index.php?$args; handling. Example:
`server {
listen 80;
server_name example.com *.example.com;
root /var/www/example.com;
index index.php;
location / {
try_files $uri $uri/ /index.php?$args;
}`
location ~ \.php$ {
fastcgi_pass unix:/run/php/php7.4-fpm.sock; # adjust to your PHP-FPM socket
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
5 — Log back in and confirm Network Admin
After adding the files and logging back in, you’ll see My Sites → Network Admin in the admin bar.
Visit Network Admin → Sites to add new sites. Use Sites → Add New (enter site address, title, admin email).
Visit Network Admin → Plugins to install plugins; you can Network Activate to enable on all sites or enable per-site.
6 — Important network settings & management
Network Admin → Settings → Network Settings: control registration (closed, user accounts allowed, site registration), default language, upload settings (site upload space), and new site defaults.
Themes: install themes from Network Admin → Themes. Themes must be Network Enabled to be available for site admins.
Plugins: install network-wide or enable per site. Note: many plugins are not multisite-safe — test first.
Users: Super Admin manages users network-wide. Site admins manage users only for their site (unless given network privilege).
7 — Media and files
Multisite stores uploads per site under wp-content/uploads/sites/<site_ID>/ (or blogs.dir for very old installs). Backups should include these folders.
When moving a single subsite out of the network you’ll need to copy files, update URLs and database entries — use migration tools or plugins that support multisite.
8 — SSL for subdomains
For subdomain setups you’ll likely want a wildcard SSL certificate (*.example.com) or a certificate per domain. Let’s Encrypt supports wildcard certs via DNS challenge.
Alternatively, use a load balancer/CDN that offers SSL termination.
9 — Testing, backup and roll-back
Test the entire flow on a staging site first.
Keep a tested rollback plan: backups + database export pre-multisite.
Re-enable caching/security plugins only after verifying the network is stable.
Pros and Cons of WordPress Multisite
Pros
- Centralized management: one WordPress install to update core, themes, and plugins.
- Easier to create and maintain many sites quickly.
- Shared filesystem and database reduces duplication.
- Single sign-on-style user management across sites (users can be given access across network).
Good for schools, franchises, and multisite SaaS models.
ConsSingle point of failure — one compromise or failure affects every site.
One DB for all sites makes large network backups/restores more complex.
Plugin/theme incompatibilities can break multiple sites; not all plugins are multisite-friendly.
Migrating a subsite out to a standalone install is more involved.
Hosting and resource needs scale differently — heavy sites can affect the entire network.
Five common FAQs
Q1: Can I switch from subdirectories to subdomains later?
A: You can, but it’s non-trivial — you’ll need DNS/server changes and mass URL redirects or domain mapping. Plan the structure early.
Q2: Can every subsite use a different domain (example2.com) instead of subdomain?
A: Yes — with domain mapping. You can either use a domain-mapping plugin or configure each site's Site Address and server virtual hosts; DNS must point the mapped domain to the same server.
Q3: Is a multisite network faster or slower than separate installs?
A: Multisite saves resources for many small sites (single WP core), but a very busy single subsite can slow the whole network. Use scalable hosting and caching.
Q4: How do I back up multisite safely?
A: Back up files and the single database. Use a multisite-aware backup plugin (or server-level backups). Test restores in a staging environment.
Q5: Can I give a client admin-only access to their subsite?
A: Yes — site administrators have control over their subsite unless you (Super Admin) restrict capabilities. The Super Admin retains network-level control.
Top comments (0)