Multi-Brand Website Architecture: Running Several Brands and Markets Without Duplicating Everything
How to run several brands and countries on shared foundations: architecture options, design tokens, a shared CMS, domains and hreflang, and governance.
How should a business run several brands without duplicating everything?
Share the foundations and separate the identity: one component library themed per brand through design tokens, one content platform with brand and locale spaces, shared hosting, deployment, consent and analytics patterns, and separate domains, content and measurement per brand. For countries, choose a URL structure (country domains or subfolders), link equivalent pages with hreflang, and localise currency, legal pages and content rather than copying. Separate codebases are justified only when brands need genuinely different products or teams.
This guide is for marketing, digital and engineering leads at groups running several brands or markets.
Key takeaways
- Theme shared components per brand; do not fork code.
- Use one CMS with spaces, roles and workflows per brand.
- Pick a market URL structure and apply hreflang consistently.
- Standardise consent, analytics and performance budgets.
- Give shared components an owner and a release process.
Architecture options
| Option | Fits when | Trade-offs |
|---|---|---|
| Separate sites per brand | Brands are unrelated or independently run | Duplicated effort; inconsistent quality and security |
| Multi-site CMS platform | Similar sites, editorial teams per brand | Platform constraints; licence costs per site |
| Shared component library and themes (monorepo) | Similar functionality, distinct identities | Needs design system discipline and ownership |
| Headless CMS plus shared front end | Several brands and markets, custom experiences | More engineering; strong flexibility |
Design system and theming
Build components once and theme them with design tokens: colour, typography, spacing, radius and imagery rules per brand. Allow brand-specific components only where needed, keep them in the same library, and test every component against every theme, including contrast for accessibility. See design systems for teams that move fast.
Content platform
Use spaces or sites per brand with roles so editors only see their brand, share content types and genuinely shared content (such as corporate policies), and set publishing workflows per brand and market. See how to choose a CMS.
Domains, markets and hreflang
For the UK and other markets, choose between country-code domains, subdomains or subfolders, following Google's guidance on multi-regional sites. Link equivalent pages with hreflang, including a self-reference and return links, and keep canonical tags pointing to the page itself rather than another market. Localise prices, currency, delivery, legal pages and spelling (British English for the UK). See international ecommerce SEO.
Shared services and governance
- One consent management approach and analytics schema across brands, separate properties per brand.
- Shared performance budgets and accessibility checks in CI.
- Central security headers, dependency updates and monitoring.
- A design system owner, contribution process and versioned releases.
- Brand guidelines mapped to tokens, not reinvented per site.
Hypothetical example: a homeware group
This example is hypothetical. A UK homeware group with three brands ran three separate WordPress sites with different plugins and uneven performance. It moved to one headless CMS with a space per brand, one Next.js front end with a token-themed component library, and UK and Irish subfolders with hreflang. Shared components fixed accessibility issues once for all brands.
Common mistakes
- Forking code per brand.
- Copying UK content to other markets without localisation or hreflang.
- Different consent and analytics setups per brand.
- No owner for shared components.
- Testing components only in one brand theme.
Sources
Conclusion
Multi-brand architecture works when foundations are shared and identities are configured: themed components, a multi-space CMS, consistent consent and analytics, and correct market URLs with hreflang. Govern shared parts deliberately so brands benefit from each improvement.
Running several brands on separate, drifting sites?
ZSpace Labs is a remote-first technology studio that works with clients globally on website platforms and design systems. If it would help to plan a shared architecture, we are happy to talk it through.
Common questions.
Usually not. A shared codebase or component library with brand themes cuts duplicated work, while separate content, domains and analytics properties keep brands distinct. Separate codebases make sense when brands need very different functionality or are run by independent teams.