One Sanity instance can run your entire web estate — two sites, five sites, ten. Each with its own editorial space, its own content, and its own Next.js frontend.
No separate environments, no duplicated schemas, no global copy change that has to be made four times.
Most teams reach this architecture after years of compounding the wrong decision: one CMS per site, maintained independently, drifting apart quietly until a schema update or a new brand launch makes the cost impossible to ignore.
This guide covers how to structure it, which of the three Sanity multisite approaches fits your situation, and what changes when you’re consolidating existing sites rather than building from scratch.
Based on Pagepro’s experience as a Sanity Partner across 50+ client implementations.
Can Sanity manage multiple websites from one instance?
Yes. Sanity supports multisite setups natively through three named approaches: the shared dataset model, the workspace-per-brand model, and the separate projects model.
Each handles content isolation, editorial access, and schema sharing differently — the right choice depends on how much your sites actually diverge from each other.
The rest of this guide covers how to choose between them, how to structure your schema, and what changes when you’re migrating from legacy CMSes rather than building from scratch.
Three approaches to Sanity multisite — and when to use each
The right architecture depends on one question: how much do your sites differ from each other?
Sites that share the same content structure, component library, and editorial patterns need a different setup than sites with fundamentally different schemas and independent teams.
| Approach | Best for | Schema isolation | Editor isolation | Complexity |
| Shared dataset | Sites with similar content structure | None | Partial (Structure Tool) | Low |
| Multiple workspaces | Different schemas, same team | Partial | Full | Medium |
| Separate projects | Fully independent brands | Full | Full | High |
Approach 1 — Shared dataset with document-level filtering
All sites live in the same Sanity dataset. Every document carries a brand identifier, and GROQ queries on the frontend scope content to that identifier at request time. Use this when your sites share the same page types, component library, and editorial patterns.
The tradeoff: data isolation is enforced at the query layer, not the storage layer — sloppy GROQ can surface cross-brand content.
typescript
// GROQ query scoped to a specific brand — filters all pages by brand reference
const query = groq`*[_type == "page" && brand._ref == $brandId]{
title,
slug,
content
}`Approach 2 — Multiple workspaces, one project
A Sanity workspace is an editorial UI configuration — it controls what editors see and can do in Studio. The defineConfig function accepts an array of workspace definitions, each with its own base path, schema subset, and Structure Tool configuration.
Editors log into the same Studio URL but are routed to their own workspace. Use this when brands have meaningfully different schemas or editorial governance requirements. The tradeoff: all schemas must be defined in one codebase, even if each workspace only surfaces a subset.
typescript
// defineConfig with two workspaces — each brand gets its own Studio environment
export default defineConfig([
{
name: 'brand-a',
title: 'Brand A',
projectId: process.env.SANITY_PROJECT_ID,
dataset: 'brand-a',
basePath: '/brand-a',
schema: { types: brandATypes },
},
{
name: 'brand-b',
title: 'Brand B',
projectId: process.env.SANITY_PROJECT_ID,
dataset: 'brand-b',
basePath: '/brand-b',
schema: { types: brandBTypes },
},
])Approach 3 — Separate Sanity projects
Each brand gets its own Sanity project, its own dataset, and its own Studio instance.
Use this when brands have different billing requirements, different data residency or compliance needs, or are operated by fully independent teams with no shared content.
For most SMBs managing 2–5 related sites, separate projects create more maintenance overhead than the isolation justifies — schema updates, dependency upgrades, and Studio configuration changes must be repeated per project.
How to design your schema for multisite content
Regardless of which architecture approach you choose, the schema design work is where the most consequential decisions get made.
A well-structured multisite Sanity setup uses a three-layer hierarchy — the global-brand-page model — to separate what’s shared from what’s customizable from what’s site-specific.
Global configuration (singleton)
A global configuration singleton is a single document constrained to one instance, surfaced in Studio as a settings panel rather than a list view. It holds values that apply everywhere by default: typography tokens, fallback legal copy, default form endpoints, third-party script identifiers, and any other values that would be error-prone to maintain separately per brand.
Only a central content operations team should have write access to this document.
Brand document
The brand document holds per-brand overrides. Rather than duplicating the entire global configuration and editing it per brand, the brand document type contains only the fields that brands are permitted to customize — colors, logos, CRM endpoints, analytics IDs, reviews integrations.
The frontend resolves the final value by checking the brand document first, then falling back to global configuration if no override exists.
typescript
// Brand document resolution — brand overrides take precedence over global config
function resolveValue<T>(brandValue: T | undefined, globalValue: T): T {
return brandValue ?? globalValue
}Page-level content
Pages reference their parent brand, which resolves its overrides against the global configuration.
The result is a predictable hierarchy:
global defaults → brand overrides → page-specific values
The practical payoff is significant — onboarding a new brand means creating one Brand document and setting only the fields that differ from global defaults.
No new CMS environment, no schema duplication, no developer involvement for standard campaign pages.
How does Sanity multisite compare to other headless CMSes?
Sanity is not the only headless CMS that supports multisite setups. Storyblok, Contentful, and WordPress Multisite all offer multisite capabilities — but the architecture and operational tradeoffs differ significantly.
| Capability | Sanity | Storyblok | Contentful | WordPress Multisite |
| Native multisite support | Workspaces + datasets | Spaces (folder-based) | Environments (limited) | Built-in (coupled) |
| Schema sharing across sites | Yes (shared dataset) | No | No | Yes (coupled) |
| Per-site editor permissions | Yes | Yes | Yes (Enterprise only) | Yes |
| Headless / Next.js integration | Native | Good | Good | Plugin-dependent |
| Migration tooling | Yes (Nexity) | No | No | No |
| Pricing at 3–5 sites | One project | Per space | Per environment | Self-hosted |
Storyblok’s folder-based approach — where each domain maps to a content folder and a separate deployment with its own environment variable — works, but requires one deployment per domain and offers no native schema sharing across sites.
Sanity’s workspace model handles domain routing at the Next.js middleware layer instead, meaning one codebase serves all domains without separate deployments.
Contentful’s multisite support is limited outside of enterprise pricing — per-environment costs make it expensive at 3–5 sites.
WordPress Multisite shares a database across sites but tightly couples content to WordPress’s rendering layer, making headless adoption complex and performance optimisation per-site impractical.
For teams already evaluating Next.js + headless CMS, Sanity’s workspace architecture gives the most flexibility without the per-site cost overhead.
What changes for SEO when you manage multiple sites in Sanity?
Running multiple sites from one Sanity instance doesn’t automatically handle SEO correctly — three things require explicit configuration per domain.
Canonical tags per domain
Each domain needs a canonical tag pointing to itself. Sanity’s next/metadata integration handles this per document, but it must be configured explicitly per workspace — it does not inherit correctly across workspaces by default.
Verify that each workspace’s metadata configuration sets the canonical URL to its own domain, not the primary domain.
Sitemap per domain
Each domain needs its own scoped sitemap.xml. A GROQ query filtered by brand identifier generates it cleanly without cross-domain content leaking into the wrong sitemap.
typescript
// Sitemap query scoped to a specific brand — excludes all other brands' pages
const sitemapQuery = groq`*[_type == "page" && brand._ref == $brandId]{
"slug": slug.current,
_updatedAt
}`Redirect maps per domain during migration
Migrating multiple legacy sites to one Sanity instance means managing multiple redirect maps simultaneously — one per source domain. This is where multisite migrations get significantly more complex than single-site migrations.
Each domain has its own URL structure, its own permalink patterns, and its own redirect requirements.
Nexity manages 301 redirects inside Sanity Studio, where editors maintain redirect maps per brand without touching configuration files or involving a developer.
When go-live happens, redirects activate per domain — staggered, not all at once.
If you’re planning to consolidate multiple sites onto Sanity, see how Pagepro approaches multisite migrations — including how we scope redirect maps before a single line of code is written.
Migrating multiple legacy sites to one Sanity instance
Consolidating multiple legacy sites — WordPress, custom monoliths, or no/low-code stacks — into one Sanity instance is architecturally more complex than a single-site migration. The content types, URL structures, and editorial workflows of each site need to be mapped independently before any migration work begins.
Step 1. Audit before merging
Map content type overlap across all source sites before touching the schema. Where sites share the same page types and component patterns, a shared dataset works. Where schemas diverge significantly, separate workspaces are the right call.
Getting this wrong early means restructuring mid-migration — the most expensive mistake in a multisite consolidation.
Step 2. Migrate global configuration first
Establish the global configuration singleton before migrating any site-specific content. Brand documents come next, with overrides mapped against the global defaults. Content migration follows per brand.
Reversing this order — migrating content before the configuration hierarchy is established — creates remapping work that compounds with every additional site.
Step 3. QA and go-live per domain
Stagger go-lives. One domain at a time, with full QA — Lighthouse scores, redirect verification, content parity checks — completed before the next domain is touched.
Activating all redirects simultaneously across multiple domains on a single go-live date is the fastest way to create an SEO incident that takes months to recover from.
Pagepro handles multisite migrations through Nexity — a fixed-price 4-week engagement built on 20+ real client migrations. Brand document setup, per-domain redirect maps managed inside Sanity Studio, and a per-brand QA checklist are included as standard.
Consolidating multiple sites onto Next.js + Sanity?
We’ll migrate one of your sites in 48 hours using your actual content — no commitment. Or start with a Migration Assessment to map the full scope across all your domains.
Book the 48h demo → Request a Migration Assessment →
Frequently asked questions
A Sanity workspace is an editorial UI configuration — it controls what editors see and can do in Studio. A dataset is the actual data store where content lives. Multiple workspaces can share one dataset, or each workspace can point to its own. The decision affects data isolation, not just the editorial interface.
Yes. Workspaces and shared datasets are available on free and growth tiers. Cross-dataset references — for sharing content between separate datasets — require an enterprise plan. For most SMBs managing 2–5 related sites, a single dataset with workspace separation is sufficient and does not require enterprise pricing.
Use separate projects when brands have different billing requirements, different data residency or compliance needs, or are operated by fully independent teams with no shared content. For most Digital Native SMBs managing 2–5 related sites, separate projects create more maintenance overhead than the isolation justifies.
WordPress Multisite shares a codebase and database but tightly couples content to WordPress’s rendering layer. Sanity’s approach is fully headless — content is CMS-agnostic and domain routing is handled in Next.js middleware. This gives significantly more flexibility for performance optimization, frontend customization, and independent deployments per domain.
Each domain requires its own canonical tag, its own scoped sitemap, and its own redirect map. Sanity’s per-document metadata fields handle canonicals. Sitemap generation uses a GROQ query filtered by brand. Redirect management for migrations is handled inside Sanity Studio, where editors maintain 301s without developer involvement
