Multisite is powerful, but use it for the wrong shape of project and running it becomes painful. The bottom line: use multisite when “sites with the same setup, the same operating rules, managed by the same people.” If even one of those differs, keep them separate.
The upsides
1. Updates happen once
WordPress core, themes and plugins update once for the whole network. Ten sites, one job. The more sites you manage, the bigger the win.
2. Users are managed centrally
One account can belong to several sites, with a role (editor, author and so on) per site. In an organization with a lot of people coming and going, that alone can justify it.
3. Design and structure stay aligned
Because the theme is shared, the look doesn’t drift between sites. It structurally prevents the “each branch’s design slowly falls apart” problem.
4. Hosting cost and admin overhead collapse into one
One contract, one SSL certificate, one backup target. When you’re carrying ten small sites, both cost and effort drop sharply.
5. You can work with data across sites
Cross-site displays like “collect every site’s latest posts in one place” or “show the head office’s announcements on branch sites” are achievable in code.
TipsFetching another site's posts in multisite (switch_to_blog)How to fetch another site’s posts (switch_to_blog)The downsides
1. Failures affect every site
This is the biggest risk. Because things are shared, this is what happens.
- A plugin update breaks something → every site is affected at once
- One site gets a traffic spike → every site gets slow
- A serious failure → every site goes down together
If you have a requirement that “one site going down shouldn’t take the others with it,” multisite isn’t the fit.
2. Moving just one site out later is hard
When you need to “hand a branch site over to another company” or “move one site to a different server,” you have to extract not just the posts but the users, images and settings. It’s nothing like copying a standalone site.
3. Some plugins don’t work
Plugins that don’t advertise multisite support may not work, or may behave unexpectedly. Caching, backup and SEO plugins in particular need checking in advance.
4. Permissions get complicated
Each site’s administrator can’t install themes or plugins (only the network administrator can). That’s a poor match for “each site should be free to install its own plugins.”
5. Server and hosting constraints
- Some hosting plans don’t support multisite
- On Nginx,
.htaccesshas no effect, so server configuration is required - Subdomain setups need wildcard DNS
Confirm “multisite supported” before you sign up.
Decision checklist
The more of these you answer “yes” to, the better multisite fits.
- The sites share the same look and feature set
- The same person (or organization) manages all of them
- Sites don’t need freedom to install their own plugins
- There’s no plan to move one site to a different server
- The number of sites is likely to keep growing
- You want to share users or information between sites
Conversely, if any of these apply, keeping them separate is safer.
- Different clients (each delivery should be independent)
- The plugins each site needs differ substantially
- One of them might receive heavy traffic
- A future sale, handover or transfer is on the horizon
- You want site owners to install plugins themselves
Fit and misfit, by example
| Case | Verdict | Why |
|---|---|---|
| Branch pages nationwide (same design) | ◎ Good fit | Shared setup, same admins, growing count |
| A school’s faculty and department sites | ◎ Good fit | Different editors, shared rules |
| Language-specific sites | ○ Worth considering | Weigh it against a multilingual plugin |
| Internal team sites and intranets | ◎ Good fit | User management can be centralized |
| An agency’s sites for different clients | ✕ Separate | Different clients means independence is required |
| A personal blog plus a shop | △ Be careful | The plugins each needs tend to differ a lot |
| A high-traffic publication plus a small company site | ✕ Separate | You want the blast radius separated |
Alternatives
Option 1: separate sites, shared theme management
Manage the theme in Git and distribute it to each site. The update effort remains, but independence is total. This is the default when an agency handles several clients.
Option 2: split within one site using custom post types
If all you’re doing is splitting by type—“products,” “case studies,” “news”—you don’t need multisite. The URLs can be split too, as /products/ and so on.
Option 3: use a plugin for multiple languages
If language-specific sites are the goal, both a multilingual plugin and multisite are options. A plugin that builds the translation links and language switcher for you is usually less implementation work.
Practical notes if you do adopt it
- Set up a test environment—updating only on production is dangerous when the blast radius is every site
- Keep the plugin count down—because things are shared, one bug has a big impact
- Automate backups—confirm the mechanism can restore a single site
- Standardize cache settings—different settings per site make tracing causes hard
Summary
- The upsides are one update, central user management, consistent design, consolidated cost and cross-site displays
- The downsides are that failures affect every site and moving one site out is hard
- The decision comes down to three things: shared setup, same admins, no plan to separate
- With few sites or different clients, separate sites with a shared theme is safer
Think in terms of “can I live with a choice I can’t reverse?” rather than “can this technically work,” and you won’t get the decision wrong.