WordPress Multisite allows several sites to share one WordPress installation, core files and a central network administration layer. It can reduce repeated administration for a genuinely related group of sites, but it also concentrates risk and makes hosting, plugins, domains, user management and recovery more complex.
What Multisite changes
Each site has separate content tables while the network shares users and installed code. Network administrators control installation of themes and plugins, while individual site administrators have narrower powers. Networks can use subdirectories, subdomains or mapped domains depending on configuration.
Good and poor use cases
| More suitable | Usually less suitable |
|---|---|
| Related regional or departmental sites under one governance model | Independent client sites with separate owners and exit requirements |
| Shared theme/plugin standards and central technical team | Sites needing incompatible plugin, PHP or update schedules |
| Many similar campaign or publication sites | A few sites merely to save separate logins |
| Central user administration that is genuinely required | Sites expected to be sold, moved or administered independently |
| Hosting designed and supported for Multisite | Basic shared hosting without network expertise |
Understand the shared risk
A failed update, compromised privileged account or server outage can affect the whole network. Backups and restoration are more complex because tables, uploads and domains must be mapped correctly. A plugin compatible with single-site WordPress may not support network activation or per-site configuration as expected.
Ask governance questions
- Who is the Super Admin and who provides emergency cover?
- Who approves themes, plugins and network-wide updates?
- Can a site be exported or separated if ownership changes?
- How are domains, certificates and DNS managed?
- How are backups restored for one site versus the full network?
- Which personal data and users are shared?
- What is the incident and supplier-exit plan?
Test before conversion
Create a non-production network and test domain mapping, roles, required plugins, media, email, updates, backups and single-site export. Converting existing independent sites can encounter user and settings limitations; do not treat it as a simple merge operation.
Consider simpler alternatives
Separate WordPress installations can still share deployment tooling, managed hosting and a common theme without sharing one database and failure domain. A single site with structured sections may also solve a content-organisation problem that does not require separate sites.
Exit and recovery test
Before adopting Multisite, demonstrate how one subsite would be exported, restored and handed to a new owner. Also demonstrate a network-wide backup and the restoration of a single site without damaging its neighbours.
If the proposed team cannot explain these procedures before launch, the operational complexity is not yet under control.
Practical next step
Write down the reason Multisite is being considered and compare it with separate managed installations. Proceed only if shared governance is a requirement rather than a convenience.
Sources and date checked
This guide was checked on 21 July 2026. WordPress, plugins, hosting platforms and commercial terms change, so confirm the current documentation and licence details before making a material change.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.