How do I build a multisite setup with one content source?

A multisite setup with one content source usually means:

• One place where content is created and managed
• Multiple sites / domains / subdomains
• Each site may share some or all content from the central source
• Optionally, sites can add local content or overrides

The exact approach depends on whether you mean WordPress Multisite, a headless CMS, or a custom stack. Here’s the general architecture and the main ways to build it.

---

1) Pick the content model

You generally have 3 patterns:

A. Central CMS, multiple frontend sites

• One CMS stores all content.
• Separate frontend apps pull content from the CMS.
• Best when sites need different designs, tech stacks, or deployments.

Example:

• CMS: Contentful / Strapi / Sanity / WordPress
• Frontends: Next.js, Nuxt, Astro, etc.
• Each site filters content by siteId, locale, or brand

B. CMS multisite, shared content library

• One CMS instance serves multiple sites.
• Shared content types and site-specific content exist in the same system.
• Best when you want centralized editing and tight integration.

C. One codebase, many sites, shared content source

• One app serves multiple domains.
• Requests resolve the tenant/site based on host.
• The app fetches the right content from the central source.

Best when you want operational simplicity.

---

2) Define how content is shared

Decide what “one content source” means in practice:

Shared-only content

All sites show the same articles, pages, products, etc.

Shared core + local extensions

• Shared: company pages, articles, policies, reusable blocks
• Local: region-specific contact info, promos, landing pages

Shared content with overrides

• Base content comes from the central source
• A site can override title, hero image, CTA, or localization

This is usually the most flexible model.

---

3) Add a site/tenant identifier to content

Your content source needs a way to know what belongs to which site.

Typical fields:

• siteId
• tenantId
• brandId
• locale
• channel
• publishedForSites[]

Example content record:

{
  "id": "about-us",
  "title": "About Us",
  "body": "...",
  "sites": ["site-a", "site-b"],
  "locale": "en-US"
}

Or with shared/default content:

{
  "id": "home-hero",
  "default": true,
  "overrides": {
    "site-a": {
      "headline": "Welcome to Site A"
    },
    "site-b": {
      "headline": "Welcome to Site B"
    }
  }
}

---

4) Build site resolution logic

When a request comes in, determine which site it belongs to.

Common strategies:

• Domain mapping: site-a.com vs site-b.com
• Subdomain mapping: a.example.com, b.example.com
• Path-based: example.com/site-a
• Header-based: used behind a proxy or for preview

Example resolution flow:

1. User requests https://site-a.com/about
2. App reads host header
3. Host maps to siteId = site-a
4. App fetches content where siteId = site-a
5. Render page

---

5) Decide on one of these technical architectures

Option 1: Headless CMS + multiple frontends

This is the most common modern setup.

Components

• Central CMS for content authors
• Shared API for content delivery
• Multiple frontend apps or one multi-tenant frontend
• CDN for caching

Pros

• Flexible
• Easy to scale
• Works well with many sites

Cons

• More engineering work
• Need to handle site resolution, previews, caching, permissions

---

Option 2: WordPress Multisite

If you’re in the WordPress ecosystem, this can work well.

How it works

• One WordPress install
• Multiple sites under one network
• Shared plugins/themes possible
• Each site can have separate content

How to approximate “one content source”

• Use shared custom post types
• Use network-wide content or synchronization plugins
• Build custom logic to pull content between sites

Pros

• Familiar admin UI
• Easier for editorial teams already using WordPress

Cons

• Shared content across sites can get messy
• Can become hard to maintain at scale

---

Option 3: Custom application with a shared content service

For advanced needs.

Architecture

• Content service/database centralizes all content
• Frontend sites call the service via API
• Optional local caching/search index

Pros

• Full control
• Great for complex business rules

Cons

• Highest build/maintenance cost

---

6) Plan for localization and variants

If the multisite setup spans regions or languages, model these separately:

• site = brand or domain
• locale = language/region
• contentVariant = campaign or market-specific version

Example:

• site-a.com/en
• site-a.com/fr
• site-b.com/en

You may need:

• Translation workflows
• Fallback rules
• Content inheritance

Example fallback:

1. Exact site + locale
2. Site default locale
3. Global default content

---

7) Handle media centrally

Don’t store images/files separately per site unless you must.

Use:

• Shared media library
• CDN-backed asset storage
• Metadata tagging by site if needed

Example:

• Store assets in S3 or a DAM
• Attach them to content entries
• Restrict visibility with site tags

---

8) Set permissions and workflows

In a multisite system, editorial permissions matter.

Typical roles:

• Global admin
• Site editor
• Translator
• Approver

Workflow options:

• Global content published once and pushed to all sites
• Site-level approval for overrides
• Draft/preview per site

---

9) Implement caching carefully

Because many sites share one source, caching is important.

Cache layers:

• API response cache
• CDN edge cache
• Server-side page cache
• Query-level cache

Cache key should include:

• siteId
• locale
• page slug
• query params if relevant

Example cache key:

site-a:en-US:/about

---

10) Support preview and staging

You’ll want preview for:

• Draft content
• Site-specific variants
• Local overrides

Typical setup:

• Preview token
• Preview domain
• Draft API access
• Separate staging environment

---

11) Recommended build pattern

If you want the safest modern approach, use:

• One headless CMS
• One shared content schema
• Multi-tenant site resolution
• One or more frontend apps
• Central media storage
• Locale + site-aware filtering
• Strong caching

This gives you one source of truth without forcing every site to be identical.

---

12) Example implementation pattern

Content schema

• Page
  • slug
  • siteId
  • locale
  • title
  • body
  • publishedAt

Request flow

1. Request comes to brand1.com/products
2. Middleware maps host → siteId=brand1
3. CMS query:
   • slug = products
   • siteId = brand1
   • locale = en
4. Render with brand1 theme

Shared content

• FAQ entries published globally
• Site-specific homepage hero
• Brand-specific navigation

---

13) Common pitfalls

• Mixing shared and site-specific content without clear rules
• Not planning for locale fallback
• Hardcoding domain-to-site mappings
• Ignoring cache invalidation
• Letting editors accidentally publish content to the wrong site
• Using separate media libraries unnecessarily

---

14) Quick recommendation by use case

If you want simplicity and editorial control:

• WordPress Multisite

If you want modern frontend flexibility:

• Headless CMS + multi-tenant frontend

If you need deep custom behavior:

• Custom content service + multi-site app

---

If you want, I can give you:

1. a WordPress Multisite implementation plan,
2. a headless CMS architecture diagram, or
3. a step-by-step build using Next.js + Strapi/Contentful/Sanity.