Multi-site is where headless CMS setups either shine or collapse. Done right, one CMS instance can power many sites—brand sites, regional sites, client sites—without duplicating infrastructure. Done wrong, you get tangled content, accidental cross-brand leaks, and impossible governance.
This guide gives you a practical architecture for multi-site with a headless CMS like ElmapiCMS.
Table of Contents
- Define “multi-site” for your case
- Three common architectures
- Recommended model: strict isolation + shared templates
- Content routing and canonical URLs
- Shared components (blocks) across sites
- Permissions and editorial governance
- Caching and invalidation across sites
- Pitfalls to avoid
Define “multi-site” for your case
Multi-site can mean:
- Multi-brand: different domains with different design + content
- Multi-locale: one brand across regions/languages
- Multi-client: agencies hosting many client websites
- Multi-product: one company with many product microsites
The right architecture depends on how isolated the content must be and who controls it.
Three common architectures
1) One CMS project per site (strong isolation)
Each site gets its own “project” or “space” with its own API credentials.
Pros: isolation, permissions, easier governance.
Cons: shared content must be duplicated or synced.
2) One project, tenant field on all content (soft isolation)
Everything shares the same schema. Every entry has siteId or tenant.
Pros: easy sharing, one schema.
Cons: easy to leak content if filters are missed; permissions get tricky.
3) Hybrid: shared base + isolated content
Shared content (global components, design tokens, universal docs) lives in one place; each site has isolated content elsewhere.
Pros: best balance.
Cons: more engineering and clear rules required.
Recommended model: strict isolation + shared templates
For most teams:
- Keep site content isolated (one project/space per site)
- Share frontend templates/components in code (monorepo or shared package)
This gives you:
- predictable permissions
- clean APIs per site
- fewer “forgot to filter” bugs
When you truly need shared content (e.g. corporate footer, legal pages), you can:
- duplicate with a controlled process, or
- fetch shared content from a dedicated “global” project
If you choose a shared “global” project, keep the contract small:
- navigation
- footer/legal
- shared CTAs
Content routing and canonical URLs
Multi-site SEO depends on strict URL rules:
- Each site must generate canonical URLs for its domain
- Slugs should be unique per site (or scoped by locale)
- Sitemaps should be domain-specific
If you share a CMS instance across domains, never assume a slug maps to one URL—always compute the URL using the site context.
Shared components (blocks) across sites
If you use a “blocks” model:
- keep section types consistent across sites
- render them via a single component map in code
- allow site-level variants (theme tokens, spacing) in configuration rather than duplicating section schemas
This is where headless shines: one design system, many content sources.
Permissions and editorial governance
Multi-site needs strict roles:
- editors for site A should not see site B content
- global admins can manage shared templates
- publishing rights are usually per site
Add governance rules:
- naming conventions (site slugs, locales)
- review workflows for shared items (global navigation)
- change logs (who changed what)
If you run an agency setup, treat each client as a tenant with hard boundaries.
Caching and invalidation across sites
When content updates:
- only revalidate the affected site(s)
- don’t nuke caches across all domains unless a global item changed
Use webhook payloads that include:
- site identifier
- locale (if applicable)
- content type (page/post/menu)
Then route invalidation correctly per domain.
Pitfalls to avoid
- Soft isolation without filters: one missed filter leaks content across sites.
- Shared schema drift: different sites “customize” blocks and break the shared renderer.
- Cross-domain canonical mistakes: wrong canonical URL kills SEO.
- No ownership: global navigation edits should have a review step.