WordPress Multisite is a built-in mode that runs several sites from one WordPress installation, sharing the core files, the theme and the plugin set, while each site keeps its own content, media, users and settings. It suits a network of related properties — country subsidiary sites, regional distributor sites, a group of similar brand sites — where the requirements are close enough for one codebase to serve them all.
The trade it makes is consistency and maintenance effort against shared fate. One update, one theme deployment and one security posture cover the whole network; equally, a plugin conflict or a hosting problem reaches every site at once. Whether that trade suits you depends on how alike the sites are and how much operational independence each market expects.
Shared: the WordPress core files, the plugin and theme code, the user table across the network, and the hosting environment. Separate: each site’s content, media library, menus, options and, where you want it, its own domain.
That split is the whole proposition. Code and infrastructure are maintained once while editorial control stays local, so a country marketing team publishes without waiting on the group and still receives platform improvements it did not have to commission.
The clearest case is a manufacturer with country subsidiary sites sharing a catalogue structure and a brand system while needing local language, local distributors, local certifications and a local news feed.
A second is a portfolio of similar brands after an acquisition, each keeping its identity while sharing templates. A third is a set of regional distributor or installer sites published under group control. See multi-country architecture for how the estate is planned.
Sites differing in substance sit badly together. An authenticated distributor portal, a B2B ecommerce platform and a marketing site carry different uptime expectations, release cadences and security requirements.
A property a subsidiary needs to release on its own schedule fits poorly too, since network updates are coordinated centrally. And where an acquired business runs its own IT, hosting contract and agency, the cost of pulling it into the network can exceed what sharing saves.
A network-level problem — a plugin conflict, a failed update, resource exhaustion — reaches every site. Bound it by keeping the plugin set small and vetted, staging every update against a representative sample of sites, giving the network real hosting headroom, and keeping high-value properties such as a portal outside it.
Our enterprise WordPress page covers the operating standard that makes this manageable at scale.
Agree what a local team may change and what belongs to the group: templates, components and the plugin set centrally; content, menus, local products and news locally. Record who approves a new plugin, how a market requests a template change, and how a rollout is sequenced.
Networks come apart through governance rather than through technology. See website governance for how those rules are set and held.
No technical ceiling matters in practice. The limits come from hosting resources, from how far the sites diverge, and from how much shared risk the organisation will carry. A group running twenty closely related country sites is a comfortable network.
The same group forcing an ecommerce platform and an authenticated portal into it is not. See WordPress Multisite for how we assess and build these.
It is a built-in WordPress mode that runs several sites from one installation, sharing the core files, theme and plugin set while each site keeps its own content, media, menus and settings, and optionally its own domain. It suits a network of related properties such as country subsidiary sites, where requirements are close enough for one codebase to serve them all.
It can. Because the network shares code and infrastructure, a plugin conflict, a failed update or a resource problem reaches every site rather than staying local. That is the trade against lower maintenance effort and greater consistency. Bound it with a small vetted plugin set, staged updates, real hosting headroom, and by keeping high-value properties outside the network.
Yes. Sites in a network can carry distinct themes or theme variations while drawing on shared components, so a country site or an acquired brand keeps its own presentation without duplicating the build. See design systems for how that shared component layer works across several brands and markets.
They are related and distinct. Multisite is a specific feature for running several sites from one installation; enterprise WordPress is the wider set of scaling, security, release and governance practices a large organisation needs whether or not it uses Multisite. See enterprise WordPress for that context.
When the sites differ in substance rather than in styling. An authenticated portal, a B2B ecommerce platform and a marketing site carry different uptime expectations, release cadences and security requirements. A property a subsidiary must release on its own schedule fits poorly too, since network updates are coordinated centrally.
No technical ceiling matters in practice. The limits are hosting resources, how far the sites diverge from one another, and how much shared risk the organisation will accept. Twenty closely related country sites is a comfortable network; the same network with an ecommerce platform and a portal forced into it is not.
Tell us how many properties you run and how far they diverge, and we will set out whether one network serves them or splits the risk badly.