WordPress Multisite lets you run many websites from one WordPress installation: one set of core files, one database, one place to update plugins and themes. It suits organisations that manage a family of similar sites. It also ties those sites together, so a mistake or an outage on the network can reach every site at once.
This WordPress user guide walks through a WP multisite setup from start to finish, the hosting it needs, how to protect logins with multi-factor authentication, and the risks I check with clients before a single site gets added. I’ve kept the setup steps in the same order as the official WordPress documentation, so you can follow both side by side.
What is WordPress Multisite?
WordPress Multisite is a built-in WordPress feature that turns one installation into a network of separate sites. Each site has its own content, settings and administrators, while all of them share the same WordPress core, the same installed plugins and themes, one database and one user table. A Super Admin manages the whole network from a Network Admin dashboard.
Typical networks include a university with a site per department, a franchise with a site per location, a publisher running regional editions, or an agency hosting many small brochure sites on one stack. In each case the sites look and work alike, and one team keeps them updated.
Each site keeps its own media library (uploads live in wp-content/uploads/sites/<site-id>/) and its own posts and pages. What sites do not get is independence: they can only use plugins and themes the Super Admin has installed, and they all run on the same server.
Should you use WordPress Multisite or separate installs?
Use Multisite when one team runs several similar sites with the same plugins and theme and wants to update them together. Choose separate WordPress installs when sites need different plugins, different owners or separate hosting, or may be sold or moved later. WordPress’s own guide warns that Multisite “might not be the best solution” when sites need to share data.
| WordPress Multisite | Separate WordPress installs | |
|---|---|---|
| Updates | One update covers every site | Each site updated on its own |
| Plugins and themes | Installed once by the Super Admin; sites choose from that list | Each site installs whatever it needs |
| Users | One shared user table across the network | Separate users per site |
| Hosting | All sites share one server and database | Sites can live on different hosts |
| Failure scope | A bad update or outage can affect every site | A problem stays on the affected site |
| Moving one site elsewhere | Possible, but it takes an export and cleanup | Standard migration |
| Best for | Families of similar sites run by one team | Unrelated sites, different owners, mixed stacks |
If you manage a handful of unrelated sites, separate installs on a shared maintenance process are usually simpler. This clinic group care plan example shows that approach: twelve sites kept as their own installs, run on one update process with one point of contact.
How to set up WordPress Multisite step by step
To set up WordPress Multisite, back up the site, deactivate all plugins, add the WP_ALLOW_MULTISITE line to wp-config.php, then open Tools > Network Setup, choose subdomains or subdirectories and click Install. WordPress then shows the exact lines to paste into wp-config.php and .htaccess. After you log in again, the Network Admin dashboard appears under My Sites.
- Back up the database and all files. The official guide only skips this for a brand-new install with nothing to lose. Test the backup on a staging site if the site is already live.
- Check that pretty permalinks work, then deactivate every active plugin. You can reactivate them once the network exists.
- Open
wp-config.phpand add this line above the comment that says “That’s all, stop editing”:/* Multisite */ define( 'WP_ALLOW_MULTISITE', true ); - Refresh the dashboard, go to Tools > Network Setup, choose subdomains or subdirectories, check the network title and admin email, and click Install.
- Back up
wp-config.phpand.htaccess, then paste in the lines the Network Setup screen gives you. They are generated for your install, so copy them from the screen and nowhere else. - Log in again with the link provided. Open My Sites > Network Admin, review Settings, then add your first site under Sites > Add New.
You may need to clear your browser cookies before the new login works. If the Network Admin menu doesn’t appear, the WordPress guide covers where it hides after upgrades.
Subdomains or subdirectories: which should you choose?
Choose subdirectories (example.com/site1) when every site should sit under one domain and benefit from it, and subdomains (site1.example.com) when sites are distinct brands or regions. Decide carefully: WordPress notes that switching later “might not be easy”. Subdirectories are blocked on an existing install that has been running for more than a month, because of permalink clashes.
Subdomain networks that create sites on demand also need wildcard DNS (a *.example.com record) and, in practice, a wildcard SSL certificate. A subdirectory network adds a /blog/ slug to the main site’s post URLs, which WordPress recommends keeping. The full requirements are in Before You Create a Network.
Can each site in the network have its own domain?
Yes. Since WordPress 4.5, domain mapping is a native feature, so a site in the network can use its own domain without a plugin. Point the domain’s DNS at your server, install SSL for it, then edit the site under Network Admin > Sites and enter the full domain in the Site Address (URL) field.
If logins fail silently on a mapped domain, the domain mapping guide suggests a COOKIE_DOMAIN setting in wp-config.php. Only add it if you hit that problem.
What hosting does WordPress Multisite need?
Multisite WordPress hosting needs URL rewrites that work (mod_rewrite on Apache, or equivalent Nginx rules), file access to edit wp-config.php, and enough server capacity for every site combined, because all of them share one server and database. Subdomain networks also need wildcard DNS and SSL, and mapped domains need their own certificates.
WordPress’s own guide notes that on shared hosting these requirements may need to be “negotiated with your host”. Beyond the basics, these are the questions I ask a host before a network goes live:
- Does the plan officially support Multisite, including subdomain or mapped-domain networks?
- Can SSL cover every subdomain and every mapped domain automatically?
- How many PHP workers and how much memory does the plan include, and is there an object cache such as Redis? Traffic on any one site uses the same pool.
- Can backups restore a single site from the network, or only the whole network?
- Does the staging tool copy a Multisite network correctly, including domains and the network tables?
A host that answers “whole network only” to the backup question is the most common surprise. It means a mistake on one small site can force you to roll back all of them.
What are the hidden risks of WordPress Multisite?
The hidden risks of WordPress Multisite come from sharing: one codebase, one database, one user table and one server. A broken plugin update, a compromised Super Admin account or a traffic spike on one site can affect every site in the network. Restoring or moving a single site is also harder than with a standalone install.
| Risk | What can happen | How to reduce it |
|---|---|---|
| One update reaches every site | A plugin, theme or core update with a bug breaks all sites at the same time | Test every update on a staging copy of the network first, and keep a rollback plan |
| Super Admin account compromise | An attacker with Super Admin access can install code that runs on every site | Keep very few Super Admins, require multi-factor authentication, use unique passwords |
| Shared server resources | One busy or attacked site slows the others | Size hosting for the whole network, add object caching, monitor each site |
| Whole-network backups | Restoring one site means rolling back every site | Choose backups that can restore a single site, and test a restore |
| Plugin compatibility | Some plugins misbehave when network-activated or store settings per site unexpectedly | Check each plugin’s Multisite support before installing it |
| Shared users | One account, one password across every site the user belongs to | Review users regularly and remove access from each site when someone leaves |
| Hard-to-change structure | Subdomain or subdirectory choice is difficult to reverse | Decide the URL structure before launch |
| Leaving the network | Moving one site to its own install takes an export, a new install and redirects | Keep sites that may be sold or split off outside the network |
Why one plugin update can break every site
Every site in a network runs the same copy of each plugin and theme. When the Super Admin updates a plugin, the new version goes live on all sites in the same moment. That’s the convenience Multisite promises, and it’s also a common cause of network-wide outages.
The fix is process: a staging copy of the whole network, updates applied there first, a quick check of the busiest sites, then the same update on production. A CI/CD pipeline helps if the network has custom code.
Why shared users are a security risk
Multisite keeps one user table for the whole network. A person added to five sites has one account and one password for all five, with a role on each. Removing them from one site leaves the account and their access to the other four in place. Super Admins can manage every site, install plugins and edit users network-wide.
That makes role planning important. My guide to WordPress user roles and capabilities covers how to give people only the access they need.
How do you add multi-factor authentication to WordPress Multisite?
WordPress core has no built-in multi-factor authentication, so you add it with a plugin. Install a 2FA plugin that supports Multisite, network-activate it, and turn it on for every Super Admin and site administrator first. Then confirm the plugin can enforce 2FA for those roles, because some popular options leave it to each user to opt in.
The Two Factor plugin, built by WordPress community contributors, supports authenticator apps (TOTP), email codes and backup codes, with security keys available through a separate WebAuthn add-on. Its documentation says it is compatible with Multisite, and also that it has “no network-wide settings”. A Super Admin can’t force it on everyone from Network Admin.
That gap is the hidden risk with WordPress multi factor authentication on a network: you can believe the network is protected while most accounts never switched 2FA on. Here is the order I use:
- List every Super Admin and every administrator on each site. Remove anyone who doesn’t need that level of access.
- Choose a 2FA plugin that states Multisite support and lets you require 2FA by role. Test it on the staging network.
- Network-activate it and enrol the Super Admins first, using an authenticator app and saved backup codes.
- Require 2FA for administrators and editors on every site, then check the plugin’s user list to confirm enrolment.
- Write down how a locked-out user recovers access, so nobody disables the plugin in a panic.
2FA is one layer. The rest of the basics, from updates to backups, are in my WordPress security practices guide.
Should you hire a WordPress development agency for Multisite?
Hire one of the WordPress development agencies you trust, or an experienced freelancer, for Multisite when the network carries business-critical sites, custom code or mapped domains, or when nobody in-house owns updates and backups. Ask how they test updates across the whole network, how they restore a single site, and who holds the Super Admin accounts.
Agencies bring more people and cover for holidays. A freelancer often costs less and you speak to the person doing the work. I compare both honestly in freelancer vs agency. Whoever you choose, a network needs an ongoing owner, which is what my WordPress maintenance and care plans cover: staged updates, tested backups and monitoring for every site.
WordPress Multisite checklist before you launch
Before launching a WordPress Multisite network, confirm you have a tested backup, a final choice of subdomains or subdirectories, hosting that supports Multisite with SSL for every site, a staging copy of the network, a short list of Super Admins with 2FA, plugins checked for Multisite support, and a written update and restore process. Fix any gap first.
- Tested backup of the database and files, restored once on staging.
- URL structure chosen: subdomains, subdirectories, and any mapped domains.
- Host confirmed for Multisite, wildcard or per-domain SSL, and enough capacity.
- Staging copy of the network that matches production.
- Super Admins kept to a minimum, each with multi-factor authentication.
- Every plugin and theme checked for Multisite support.
- A written process for updates, single-site restores and removing users.
If you’re moving existing sites into a network, or out of one, plan the redirects before anything changes. My WordPress migration service handles both directions.
