WordPress multisite: the structure, and whether it is the right one
Multisite is one installation serving many sites, sharing users, plugins and themes. It solves a real problem and it is chosen far more often than it is warranted, and the cost of choosing it wrongly is paid by whoever has to work inside it later.
Multisite is a structural decision that is hard to reverse
A network changes where content lives, how users work, how plugins are deployed and how backups and updates behave. Moving into it is a migration and moving out of it is a harder one, so the decision is worth making deliberately rather than because a site has grown into several. The question is not whether you have multiple sites — it is whether they are genuinely one system.
- Several WordPress sites are being maintained separately and the duplication is the problem
- A network exists and nobody can safely install a plugin on one site
- Sites in the network need different plugins and the constraint is causing workarounds
- Users need access to more than one site and accounts are being created in each
- A theme change has to be repeated across a dozen installations
- One site's plugin has broken another's admin
- The network's shared database is a single point of failure nobody planned for
- A multisite was set up for a purpose it no longer serves
The people who usually bring us this problem
Someone considering a network
Several sites share content, users or structure, and you want to know whether a network is the right answer or the wrong one.
Someone already running one
The network exists and the constraints are being worked around rather than addressed.
Someone who has inherited a network
It was set up by someone else and you need to know what it is, what it depends on and what can safely change.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
Multisite is a good answer to a narrower question than it looks
It is right when sites genuinely share users, share content, or are structurally identical. It is wrong when sites are independent but happen to run the same software — in that case a network couples them together so a plugin, an update or an outage on one affects all of them, which is the opposite of what independence means.
Plugins become a shared decision
Plugins are enabled per site but installed and updated network-wide, so the set of plugins a network can use is the intersection of what every site can tolerate. A site with a requirement no other site shares becomes a conflict, and the workaround is usually a second installation — at which point the network is not doing what it was for.
The database is shared and that changes the failure model
All sites share one set of tables with a per-site prefix, so the database is a single point of failure for the entire estate and its size is the sum of every site's. Backups, restores and migrations operate on the whole network, which means restoring one site means handling all of them.
Moving out is harder than moving in
Extracting a single site from a network into its own installation means separating its content, its users, its media and its plugin configuration, and then redirecting its URLs. It is a real migration, and it is the reason the decision deserves to be made properly rather than by default.
Capabilities
Each of these is work we carry out, not an area we advise on.
Whether a network is warranted, decided honestly
Establishing what the sites actually share — users, content, structure or nothing — and whether that sharing justifies the coupling. A recommendation against multisite is a legitimate outcome and a frequent one.
Network architecture
Subdirectory or subdomain, domain mapping, whether the network is one brand or many, and how the shared and per-site boundaries are drawn. These are the decisions everything else follows from.
Shared and per-site component strategy
Which themes and plugins are network-activated, which are available to sites and which are withheld, and how a site-specific requirement is handled without breaking the network for everyone else.
User and role model
How accounts work across the network, who can access which sites, and what an administrator of one site can and cannot affect. On a network this is a genuinely different model from a single installation and it is frequently left at its defaults.
Domain and URL handling
Mapped domains, their certificates, canonical URLs and redirects, and how a site's address relates to the network's. Domain mapping is where a multisite most often develops a search problem, because each site's URLs have to be correct independently.
Per-site theming
Themes built so sites can differ where they need to and share where they do not — a parent theme with per-site configuration, rather than a copy per site that drifts.
Content sharing and syndication
Where sites genuinely need the same content, how it is shared rather than duplicated, and how a change propagates. Duplicated content across a network is the failure this capability exists to prevent.
Operations at network scale
Backups, restores, updates and staging for a network rather than for a site, including how a plugin update is tested before it reaches every site at once. The blast radius of a mistake on a network is the whole estate.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Establish what is actually shared first
Users, content, structure, branding, deployment. If the answer is nothing, a network couples independent sites together for the convenience of one dashboard, which is not a reason. This question decides the whole engagement and it is asked before any architecture is proposed.
Say so when the answer is no
Where separate installations with a shared deployment process would serve better, that is the recommendation. Multisite is the more impressive answer and it is frequently the wrong one, and recommending it against the evidence produces a constraint the client lives inside for years.
Decide the component boundary explicitly
What is network-wide and what is per-site, written down, with the reasoning. The boundary is what determines whether a future requirement is achievable within the network or forces a second installation, so it is decided rather than left to how plugins happen to be installed.
Treat the shared database as the risk it is
Backups, restores and migrations designed for the whole network, with the restore of a single site as a documented procedure rather than an improvisation. The shared database is the structural cost of multisite and it is better planned for than discovered during a recovery.
Design for the site that does not fit yet
The requirement that arrives later is what breaks networks, and it usually arrives at one site. The architecture accounts for it in advance — a per-site plugin allowance, a documented path to extraction — so the answer is a decision rather than a crisis.
Keep each site's URLs and search behaviour independent
Mapped domains, canonicals, redirects and sitemaps correct per site. A network is one installation and its sites are separate public properties, and the search configuration has to reflect that rather than the installation's shape.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Assessment
- What the sites share: users, content, structure, branding, deployment
- Whether a network is warranted, with the reasoning and the alternative
- If a network exists: its structure, its component boundary, and what depends on what
- The failure model, given the shared database
- Per-site requirements that the network cannot currently accommodate
Build
- Network architecture: addressing, domain mapping, boundaries
- Shared and per-site themes and plugins, with the boundary documented
- User and role model, including per-site administration limits
- Per-site domains, certificates, canonicals and redirects
- Backup, restore and update procedures for the network
Handover
- What is network-wide and what is per-site, and why
- How to add a site, and what a new site inherits
- What to do when one site needs a plugin the others do not
- How to restore or extract a single site
- What the network cannot do, stated plainly
Architecture and technology
What multisite is good at
- Sites that share a user base, so one account works across all of them
- Sites that are structurally identical and differ by content and branding
- Sites that genuinely share content rather than duplicating it
- A deployment where a theme or plugin change should reach every site at once
- Administration of many similar sites from one place
What it costs
- One database for every site — a shared failure domain and the sum of every site's size
- Plugins installed network-wide, so a site's requirement becomes everyone's constraint
- Updates that reach every site at once, with the whole estate as the blast radius
- A user model that differs from a single installation and is easy to leave at defaults
- Extraction of a single site into its own installation being a real migration
- Mapped domains requiring their own certificates, canonicals and redirects
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The sites should stay separate
Building and extending a WordPress installation without coupling it to others.
WordPress developmentThe content needs to move between sites
Content modelling, mapping and a migration rather than duplication.
WordPress website migrationThe network has grown past its infrastructure
Serving-path design, capacity and database configuration.
Server managementEach site needs to be findable independently
Technical SEO for a complex WordPress estate.
WordPress technical SEOFrequently asked
Should we use multisite?
Only if the sites genuinely share something — a user base, content, or a structure identical enough that one theme configuration serves all of them. If the sites are independent and happen to run the same software, a network couples them together: one shared database, plugins installed network-wide, updates reaching every site at once. That is the opposite of independence, and it is the reason we recommend against multisite more often than for it. The assessment establishes what the sites actually share before anything is proposed.
Do you have multisite references?
No. Our published engagements are forum platforms and a small number of other systems, and none of them is a WordPress network a reader could check. The page describes the decision and the engineering rather than pointing at a client, and the FAQ says so rather than routing around it. If a named reference is a requirement, that is reasonable and this is not the page that has one.
Can one site in the network have its own plugins?
It can be enabled per site, but the plugin has to be installed and updated network-wide, and its code runs against the shared installation. So a plugin that only one site needs is still a plugin the whole network carries, and it is still updated for everyone at once. The practical answer is that a site with a requirement no other site shares is the case that eventually forces a separate installation, which is why the component boundary is decided explicitly rather than left to how plugins happen to be installed.
How do we get a site out of a network?
It is a real migration rather than a toggle: separating the site's content, users, media and plugin configuration, then giving it its own installation and redirecting its URLs. That is the reason the decision deserves care on the way in, because moving out is harder than moving in and it carries the same search risks as any other migration. Where a network is being planned, the extraction path is documented as part of the architecture so the answer exists before the question is urgent.
Does multisite affect SEO?
It does not have to, and it frequently does — because each site is a separate public property and the installation's shape is not. Each mapped domain needs its own certificates, canonicals, redirects and sitemap, and shared content across sites is duplication unless it is handled deliberately. On a network these are per-site configuration decisions rather than installation-level ones, and treating the network as one site is how a multisite develops a search problem.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.