WordPress Multisite lets one installation run many sites that share code, users and infrastructure. I have been working with it since it was folded into core in WordPress 3.0, and I have seen it used brilliantly and badly. Done right, it turns dozens or thousands of sites into one platform you can update in a single deploy. Done wrong, it becomes a tangle where one plugin update breaks everything at once.
When Multisite is the right call
Multisite shines when many sites share a common purpose and a common codebase:
- A school district with a site per school, as in our Newark Public Schools migration
- A county or city with department sites under one brand
- A brand with regional or language sites, like the Microsoft News Center network of 38 sites in 16 languages
- A product that hosts sites for many customers, like the LexisNexis LawLinks platform for nearly 3,000 law firms
- A retailer or resort with sister properties, such as Jenkinson's
In each case the sites look related, use the same features and benefit from shared updates.
When it is the wrong call
Multisite is not a fit when sites need very different plugins, have separate owners with separate budgets, require different PHP versions or hosting, or must be sold or spun off independently. In those cases separate installs managed with shared tooling are usually simpler. Also remember that a network shares one database and one codebase, so a heavy traffic spike on one site affects the others unless the hosting is built for it.
Plan the network structure
The first decision is subdomains or subdirectories. Subdirectories such as example.org/schools/lincoln are simpler for SSL and SEO consolidation. Subdomains suit sites with their own identities. Either way, domain mapping, built into core since WordPress 4.5, lets any site use its own domain.
Then decide what is shared and what is local:
- Network activated plugins provide features every site must have
- Plugins available per site are enabled by administrators of each site
- One parent theme, with child themes or style variations for each site's look
- Network wide users, with roles assigned per site
Govern plugins and themes centrally
Only super admins can install plugins and themes on a network, which is a feature. We keep a short approved list, test every update on a staging network first and deploy through Git. Site administrators get the freedom to choose from the approved set without the ability to add risk.
Roles and permissions
Multisite adds the super admin role above site administrators. Keep super admins to a very small group. Give department leads administrator or editor roles on their own site only. For organizations with single sign on, connect the network to your identity provider so people use one login and access is removed when they leave.
Performance and operations at scale
Large networks need a persistent object cache such as Redis, full page caching, a CDN and careful database maintenance, since each site adds its own tables. WP-CLI makes network operations practical; commands can loop over every site to run updates, search and replace or reports. We script recurring tasks so they are repeatable and logged.
Content sharing across sites
A common request is to publish once and show everywhere: a district announcement on every school site or a county alert on every department site. We handle this with a shared content source and custom blocks that pull from the main site, or with syndication plugins when the needs are simple. The goal is one source of truth.
Testing and deploying across a network
Every change to a network affects every site, so testing matters more than on a single install. We keep a staging network with a representative sample of sites, including the busiest and the most customized, and run updates there first. Automated checks load a key page on each sample site and fail the deploy if anything breaks. Deployments go out through Git so the whole network moves to the new version at once, and database changes that touch every site are written as WP-CLI commands that can be run, logged and repeated safely. When something must be rolled back, it rolls back everywhere in one step. That predictability is what makes Multisite a relief instead of a risk for the teams who run it.
Multisite checklist
- Confirm the sites truly share features and ownership
- Choose subdirectories or subdomains and plan domain mapping
- Define network activated and per site plugins
- One parent theme with controlled variations
- Super admin access limited to a few people
- Staging network and Git based deploys
- Object cache, page cache and CDN in place
- WP-CLI scripts for network wide tasks
Frequently asked questions
Can we move existing separate sites into Multisite?
Yes. We import each site into the network, map users and media and redirect old URLs. Our platform migration process covers this.
Can one site leave the network later?
Yes, a site can be exported to a standalone install. It takes planning, which is why we discuss exit paths up front.
Does Multisite cost more to host?
One network is usually cheaper to host and maintain than many separate installs, but it needs hosting sized for the combined traffic. See our hosting service.
Thinking about consolidating? Learn more about our WordPress Multisite services.
