Multisite CMS: one platform behind every brand, market, and language

TL;DR

For anyone responsible for many websites and tired of running many CMSs, the essentials:

• “Multisite CMS” used to mean one CMS install stretched across sites. In a headless setup it means one content platform serving many frontends through APIs. Brands, markets, and languages become things you model in content, not installations you maintain.
• The technology is the easy half. Governance is the hard half. A multisite platform pays off only if you decide, up front, what is shared (components, content types, brand assets) and what each brand or market controls locally, and encode that in roles rather than in tribal knowledge.
• The serious platforms differ in the unit of isolation, not in whether they “do multisite.” Sanity isolates by project and dataset with schema in code, Storyblok by space with folder-level roles, Contentful by space and environment inside one organization. All three work; which fits depends on how much your sites share.
• “Omnichannel CMS” is mostly the same architecture with a bigger marketing budget. Presentation-neutral content over an API can feed web, apps, and email. That part is real. The suggestion that buying the CMS gets you an omnichannel operation is not.
• The money is in consolidation. N licenses, N hosting contracts, N vendor relationships, and N upgrade cycles collapse into one platform and one team. When we consolidated three Bennetts sites off Sitecore onto one platform, total cost of ownership dropped 70% against their documented Sitecore baseline.
• The migration is where you can lose what you have earned. Rankings, content, and editorial momentum all move with the estate; they survive when the move is engineered, not when it is hoped for.

What a multisite CMS means in a headless world

The phrase carries baggage, so it is worth separating the two things people mean by it.

The old meaning is an instance model: one CMS installation configured to serve several websites. WordPress multisite, Sitecore’s multisite configuration, and AEM’s Multi Site Manager all work this way. The sites share the software, the database, the templates, and the upgrade cycle. It is genuinely better than N separate installs, which is why estates standardize on it, and it is where most teams reading this page are today.

The new meaning is a platform model: one headless content platform holds all the content, structured and brand-aware, and each site is a frontend that queries it through an API. The CMS stops being the thing you install per site and becomes the system of record for content across the estate. A new brand site is a new frontend and a content subtree, not a new installation. One design system with per-brand theming keeps the sites visually distinct but structurally identical, so a component fixed for one brand is fixed for all of them.

The practical difference shows up in the boring places. In the instance model, “add a market” means provisioning, plugin audits, and a deployment; in the platform model it means creating content in a new locale and pointing a frontend at it. In the instance model, an upgrade is an event the whole estate holds its breath for; in the platform model the vendor runs the CMS and your team ships frontends on their own schedule. We built a public reference architecture for this pattern and documented how it launches a new brand site in minutes; this page is about how to evaluate the model and the platforms behind it.

Where the legacy multisite models strain

None of the systems below is wrong, and if yours is running well this page should not talk you out of it. But each has a characteristic failure pattern, and if you recognize yours, that is the signal to evaluate.

WordPress multisite shares one codebase and one database across the network, which is its efficiency and its blast radius. Every plugin update is a network-wide event; a plugin conflict on one site is a risk to all of them. Brands that need to diverge, in design, in functionality, in language handling, end up diverging inside theme code, and a few years later each site is a special case that only one developer understands. Multi-locale setups lean on plugins that were designed for one site and stretched to many. WordPress multisite is at its best when the sites are near-identical; the more your brands differ, the harder it fights you.

Sitecore handles multisite properly at the platform level: multiple sites in one XP instance, shared templates and renderings, mature workflow. What strains is everything around it: the licensing that scales with the estate, the certified-specialist bottleneck for every frontend change, and upgrade paths that amount to re-implementation. Multisite Sitecore estates are not usually broken; they are expensive and slow to change, and the multisite capability is the reason leaving feels hard.

AEM’s Multi Site Manager is the most sophisticated of the three on paper: a blueprint site rolled out into live copies per market, with inheritance keeping locals in sync with the master. The failure pattern is well known to any team that runs it. Local markets break inheritance to customize, the live copies drift, and after enough drift the rollout mechanism that justified the platform no longer really operates; you are maintaining N sites again, now on DXP licensing. As with Sitecore, the honest question is not whether AEM can do multisite but what the capability costs per year against what a platform model would.

If the last two paragraphs describe your estate, the fork is the one we cover in the platform pages linked above: modernize within the vendor’s cloud offering, or replatform onto a headless multisite architecture. The rest of this page assumes you are seriously evaluating the second path.

The governance model: what is shared, what is local, who decides

Here is the part vendor comparisons skip, and the part that decides whether your consolidation succeeds. A multisite platform is a set of capabilities; governance is the set of decisions that turn them into an operating model. Three decisions matter most, and they should be made before a platform is chosen, because they are the requirements the platform has to meet.

First: what is shared across the estate? The high-value shared layer is structural: the content types (what a “product page” or “article” is made of), the component library the frontends render, and the assets and legal content that must stay consistent everywhere. Sharing these is what makes the estate cheaper to run and faster to extend. The design system carries the visual side: one set of components, themed per brand with tokens, so brands look distinct without being rebuilt. When we built seven brand sites for HanseYachts on one platform, each brand kept its own design direction while every site drew from a single component system; distinctiveness and consistency are not opposites if the sharing happens at the right layer.

Second: what does each brand or market own? The honest answer for most organizations: their content, their campaigns, their local pages, and a defined amount of layout freedom inside the shared components. What they should not own is the content model or the component code, because per-brand forks of the structure are how you end up back at N special-case sites. This is a negotiation, not a technical setting, and it goes better when brand teams get something real in return: publishing autonomy, so a local landing page ships in an afternoon without a ticket to central IT.

Third: who can do what, encoded in roles rather than habit? Every serious platform supports granular roles; the work is deciding them. A workable default for a multi-brand estate: a small central team owns models, components, and permissions; brand editors create and publish within their own subtree; markets translate and localize but do not restructure; and legal or brand review is a workflow state where regulation demands it, not everywhere. Write the matrix down before implementation, because it directly drives how the content is organized in whichever platform you pick.

Get these three right and the platform choice becomes much easier, because you can now ask each vendor a precise question: how do you isolate brands, how do you share structure, and how do your roles map to our matrix?

How the main platforms handle multisite

We implement all three of the platforms below in production and resell none of them, so this is the comparison we actually make in audits, not a ranking. The differences that matter are the unit of isolation, how sharing works across that unit, and what the editorial experience looks like for a brand team.

Sanity treats content as data in one Content Lake, which makes it the most natural fit when the estate is really one content system with many outputs. Isolation is by project and dataset; many multi-brand estates run one dataset with brand and market as fields on the content, which makes cross-estate queries and reuse trivial. Because the schema and the Studio are code, the shared content model is version-controlled and reviewable like any other engineering asset, and you can compose per-brand workspaces over the same content. The trade-off is the one Sanity always carries: the editorial experience is as good as the Studio your team builds, so budget engineering ownership for it.

Storyblok organizes content into spaces, and its folder structure, folder-level roles, and built-in localization map cleanly onto a brands-and-markets tree. Editors get the visual editor per site, which matters more in a multisite estate than in a single site: a brand editor in Lisbon sees the page they are editing, not an abstract form. The architectural decision is one space with per-site folders (maximum sharing, one content model) versus a space per brand (harder isolation, duplicated structure); estates with heavy sharing usually start with the first and split only where a brand genuinely diverges. HanseYachts, above, runs on Storyblok.

Contentful is the institutional choice: one organization containing spaces and environments, with the governance surface (granular roles, tasks and workflows, audit logs, locales) that large review processes and procurement expect. Its multisite question is the mirror image of Storyblok’s: content sharing across spaces takes deliberate architecture, so estates either model everything in one space with permission boundaries or accept some duplication between brand spaces. It rewards organizations that value predictable governance over maximal content reuse. Danone’s Alpro moved off AEM onto Contentful with us, and the point of the exercise was operational: a site the marketing team publishes to without developer queues.

The summary we give clients: all three clear the multisite bar, so the choice falls back to the governance decisions above and to who your editors are. If a page like this could pick your platform, an audit would not be worth paying for; what it can do is tell you the right questions, and those are the three columns of that table.

The omnichannel CMS question

You will meet the phrase “omnichannel CMS” on every vendor site in this category, usually illustrated with the same diagram: one content hub, arrows to web, mobile app, email, digital signage, smartwatch. Since it is a 600-searches-a-month phrase in its own right, it deserves an honest treatment.

The architectural claim is true. A headless CMS stores content presentation-neutrally and serves it over APIs, so the same product description, article, or legal disclaimer can feed your websites, your app, and your email templates from one source of record. For a multi-brand estate this is not hypothetical value: writing a compliance-sensitive claim once and syndicating it everywhere beats reconciling five copies of it at audit time.

What the marketing oversells is everything after the arrow leaves the hub. Each channel still needs a renderer someone builds and owns: the app team consumes the API on their release cycle, email needs the content shaped into templates inside your ESP, and in-store screens need their own delivery pipeline. The CMS also does not give you the operational layer that makes “omnichannel” a strategy rather than a diagram: channel-fit editorial (a push notification is not a shortened article), scheduling and campaign orchestration across channels, and analytics that join them. Those live in your martech stack and your team, whatever CMS you buy.

Our advice is to treat omnichannel as a modeling discipline rather than a purchase. If you structure content well enough to serve many websites, you have already done the work that makes other channels cheap to add later: content broken into typed fields rather than page blobs, no channel-specific formatting baked into the text, and assets managed centrally. Evaluate platforms on the multisite job you have today; the omnichannel option comes with the architecture either way.

What consolidation actually saves

The business case for a multisite CMS is rarely a better website; it is a cheaper and faster estate. The savings arrive in three layers, in ascending order of size.

The first layer is the obvious one: licenses and infrastructure. N CMS licenses, N hosting arrangements, and N sets of plugins and integrations become one platform contract and one hosting setup. If the estate includes a DXP, this layer alone can be large, because DXP licensing scales with exactly the things a multi-brand estate has a lot of.

The second layer is duplicated work. In a fragmented estate, every redesign, accessibility fix, cookie-consent change, and performance effort is executed once per site, often by a different vendor at a different standard. On a shared platform and design system it is executed once. This layer compounds: each new regulation and each new brand multiplies the difference.

The third layer, hardest to see on an invoice and usually the largest, is organizational drag: the vendor management overhead of many agencies, the knowledge trapped in each special-case site, the campaigns that launch late because the right developer was unavailable. Consolidation replaces that with one team operating one system, and gives marketers publishing autonomy so routine changes stop being engineering work at all.

We can attach a documented number to one consolidation. When Bennetts moved three sites from a 2017 Sitecore install onto one headless platform, total cost of ownership fell 70% against the Sitecore baseline: the license line went away, the monolith’s infrastructure was replaced by a lighter stack, and the standing dependency on specialist Sitecore developers ended. Your number depends on your baseline, which is why our audits model it before we recommend anything; a WordPress multisite estate will not save what a DXP estate saves, and pretending otherwise is how this industry earns its skepticism.

The migration path, without the hand-waving

Consolidating an estate is a program, not a project, and the sequencing is most of the risk management. The path we run:

Audit the estate before choosing anything. Inventory every site, CMS, contract, integration, and content set, including the sites nobody admits to owning. This is where the shared-versus-local governance decisions get made with real data, and where the platform requirements come from.

Design the shared system once. The content model and the design system are built for the estate, not for the first site: brand and market are dimensions of the model from day one, and components carry per-brand theming. Retrofitting multisite into a model built for one site is a rebuild in disguise, so this stage earns its time.

Migrate a pilot brand first. One real site, end to end: content migration, redirects, editorial training, launch. The pilot proves the model, surfaces the surprises while they are cheap, and gives the remaining brand teams something working to look at instead of a slide deck.

Roll the rest in waves, protecting what each site has earned. Every site brings URLs, rankings, and analytics history, and each cutover needs the full discipline: complete redirect inventory, field-level content parity checks, staging crawls diffed against production, and a reversible cutover. We keep the full replatform SEO playbook public, and the Bennetts consolidation is the proof it works at estate scale: three sites moved off Sitecore without losing rankings.

Run it after launch. The consolidated platform is an operating asset: components evolve, brands get added, markets localize. The economics of the whole exercise depend on the system staying coherent, which is a staffing question as much as a technical one. Decide before you migrate who owns the shared layer, whether that is your team, a partner, or both.

For estates leaving a specific platform, the migration profile differs enough that we keep dedicated pages: moving off Sitecore has its own well-worn path, and the Sitecore and AEM evaluations cover the stay-or-go fork honestly, including when staying is right.

Common questions

What is a multisite CMS?

A CMS that serves multiple websites from one system. The term covers two architectures: legacy instance models, where one installation hosts several sites (WordPress multisite, AEM Multi Site Manager), and the headless platform model, where one content platform feeds any number of frontends through APIs. Most teams evaluating the term today are running the first and considering the second.

Is WordPress multisite enough for a multi-brand company?

It can be, when the sites are structurally similar, the plugin surface is disciplined, and the brands share one language and market. It strains when brands need to diverge in design or functionality, when locales multiply, and when the shared upgrade cycle becomes a risk to every site at once. If your multisite network is accumulating per-site exceptions in theme code, that is the pattern worth acting on before it hardens.

Do we need a separate CMS space for each brand?

Not by default. Separate spaces buy isolation at the cost of duplicated structure and harder content sharing; a single space or dataset with folder- or field-level permissions buys reuse at the cost of more careful role design. The right split follows from how much your brands genuinely share. Decide the governance model first and let it pick the architecture, not the other way around.

Will one platform make all our sites look the same?

Only if the design system is built lazily. The pattern that works is shared components with per-brand theming: structure and behavior are common, visual identity is a token layer each brand owns. HanseYachts runs seven visibly distinct brand sites on exactly this model.

Is a multisite CMS the same as an omnichannel CMS?

They are the same architecture sold to different audiences. A headless platform that serves many websites can serve apps and email too, because content is stored presentation-neutrally and delivered over APIs. The difference is operational: multisite is a problem the CMS plus a design system largely solves, while omnichannel additionally needs renderers, editorial process, and analytics per channel, which no CMS ships in a box.