Do we need Multisite, or just several WordPress sites?

The test is shared governance, not site count. Four questions decide it: Do the sites share a theme or a design system? Do the same people administer more than one of them? Do they need to be patched and updated on the same cycle? Does someone need a single view of who has access to what? Three or more yes answers and a network usually pays for itself. One or none, and separate installations are the honest recommendation.

Which plugins break in a Multisite network?

There is no fixed list, which is the problem. The patterns are consistent, though: Plugins that assume one set of options, and write network-wide settings into a single subsite. Plugins whose licensing is bound to one domain and cannot resolve a network. Plugins that bring their own user or role handling, which then competes with the network's shared user table. We validate the plugin set against a network install before anything becomes a dependency, and where something does not hold we replace it or move the function into the theme layer.

How do subsites share media and content?

They do not by default, and that is usually correct: per-site media libraries keep uploads scoped and permissions simple. When sharing is needed there are two separate problems. Shared media needs a dedicated solution, so one brand asset lives in one place instead of being uploaded eleven times. Shared dynamic content, a combined feed of posts from every subsite or a cross-network events listing, needs custom logic over the REST API. What is shared, what is replicated and what stays local gets decided up front and documented. If each subsite also runs in its own language, that decision belongs with the multilingual architecture rather than after it.

Can each team run its own site without breaking the network?

That is what the governance plan is for, written before any subsite exists. Each subsite gets an explicit answer to who can publish, who can change navigation, who can change branding, and who holds super admin. The detail sits in user and permissions management. Plugin and theme installation stays at network level. That is not a trust question, it is a blast-radius question: one plugin activated across the network affects every site on it. Editors get real authority over content, over branding inside the block system, and over their own navigation. What they do not get is the ability to change the platform underneath the other subsites.

What hosting supports Multisite?

WordPress VIP, WP Engine and Kinsta all support network installs. Not every enterprise platform does, so we confirm it before the architecture is signed off. A network on a host that does not properly support one is the most expensive kind of rework, and where WordPress VIP is not the selected path we choose the host on compliance and regional presence, not on price.

Multisite

Enterprise WordPress Multisite: shared infrastructure, delegated autonomy, central control

Q: Subdomains, subdirectories, or mapped domains?

All three work. They are not interchangeable. Subdirectories (example.com/law/) keep every subsite on one hostname, which keeps search authority and analytics consolidated. Subdomains (law.example.com) give each unit a clearer identity and cleaner separation of cookies and tracking. Mapped domains (lawreview.org) are for units that have to be their own brand in public, on a domain of their own rather than a subdomain of yours. We settle this in discovery rather than during build for one reason: changing it after content exists is a URL migration, with redirects and a period where search relearns the site.

One WordPress core running many sites, with domain strategy, plugin compatibility and role boundaries settled before the network is switched on. Multisite is an architecture decision, not a line in wp-config.

Home
Capabilities
Multisite

What we decide first

Five decisions that determine whether the network holds

A network removes duplicated effort and concentrates risk: one core, one plugin set, one shared user table. These are the decisions that separate a network that scales from one that has to be unpicked later.

Subdomains, subdirectories, or mapped domains

site.example.com, example.com/site/, or a separately registered domain such as lawreview.org. They behave differently for search, SSL, analytics and cookie scope, and reversing the choice once content exists means a URL migration. We settle it against how the organization is actually structured, in discovery.

Plugin compatibility across the network

Not every plugin behaves in a network install: some assume a single set of options, some carry their own user handling, some cannot be network-activated at all. We validate the plugin set against a network before it becomes a dependency.

Roles and permission boundaries per subsite

Super admin, site admin, and everything below, written down before the first subsite exists. Each team gets explicit authority over its own site and an explicit limit at the network edge.

What is shared, what is replicated, what stays local

Media libraries are per-site by default and cross-site sharing needs a deliberate solution. Sharing dynamic content between subsites needs custom logic over the REST API. We decide the rules once and write them down.

A base theme with per-subsite overrides

One block system across the network, with branding, navigation and configuration overridable per subsite. New sites launch from a template rather than from scratch, which is where the operational saving comes from.

Proof

Central governance and local publishing, at enterprise scale

Commvault runs a global WordPress VIP platform where regional marketing teams publish on their own, inside role-based permissions and one shared block system. Multisite is one way to deliver that shape; these are the outcomes it gets judged on.

2.5x

Faster publishing after moving to a governed block system

65%

Reduction in developer dependency for routine content work

5 regions

Content delivery run from one central content architecture

When not to use it

Three cases where we tell you not to use Multisite

Multisite is the right call often enough that it gets proposed reflexively, and the cost of finding out late is a migration. These are the situations where we recommend something else.

The sites are genuinely independent

If the properties share no theme, no plugin set, no users and no update cycle, a network adds coupling and gives nothing back. One release then touches sites that had no reason to be affected. Separate installations are the honest answer, even though they are more expensive to maintain.

The plugin stack cannot survive a network

Some functionality only exists in plugins that were never built for a network install. If a business-critical plugin is one of them, the choice is to rebuild that function or to stay on separate installations.

Nobody owns the governance plan

A network needs someone with the authority to decide who administers what. Without that, the permission model gets negotiated site by site and the network becomes harder to run than the separate sites it replaced.

What enterprise teams ask us about WordPress Multisite

Worth reading even if you never hire us.

Related insights

Keep reading on governance at scale

How multi-property organizations keep autonomy and control in balance.

Two people in business attire sit across from each other at a conference table, working on laptops. Large windows show a cityscape in the background. Papers and cables are on the table.

Feb 9, 2026

WordPress

Find out whether Multisite is the right architecture

Tell us how many sites you run, who administers them, and what they share. We will tell you whether a network is the right call, including when it is not.

Request a Multisite review Talk to a WordPress architect