Wagtail multi-site setup for multi-brand businesses: consolidate, scale, simplify

We set up a multi-site for a holding with four brands — we ran into code duplication and content confusion. The solution: one Wagtail installation with multiple sites. Our experience of over 5 years (10+ projects) guarantees a reliable architecture where each domain lives its own life but is administered centrally.

Wagtail multi-site is an engineering approach that saves up to 60% on hosting and accelerates deployment by 5x compared to separate installations. Clients often come with ready-made sites on different CMS — we merge them into one ecosystem via Wagtail multi-site, migrating content while preserving SEO metrics. This solves typical issues: N+1 queries with separate databases, template desynchronization, update complexity — all gone with centralized architecture.

The Wagtail documentation says: Multiple sites can be hosted from a single Wagtail instance. This is the foundation of our work. We configure data migrations for reproducibility across all environments — dev, stage, production.

What problems multi-site solves

• Code duplication. Instead of five copies of one project — a single codebase with updates in one place.
• Content confusion. Editors see only their pages thanks to access restrictions. No one accidentally breaks another's landing page.
• Maintenance costs. One server instead of five — less administration, higher security.

How we configure multi-site: a practice case

The client — an agency with three sites for different niches (e-commerce, blog, portfolio). We did:

• one PostgreSQL database with shared users and groups;
• three root HomePage pages with different slugs (ecommerce, blog, portfolio);
• three records in wagtailcore_site: shop.example.com, blog.example.com, portfolio.example.com;
• a shared ArticlePage model for all sites, but with different themes via get_context;
• access restrictions: three editor groups, each only sees its own branch.

Results: average page load time under 1 second, time to add a new site — 2 hours. Read more about configuration in Wagtail multi-site documentation.

Work process

1. Analysis. We study each site's structure, gather content and template requirements.
2. Design. We determine shared and separate page models, design the media library scheme.
3. Implementation. We configure wagtailcore_site, write data migrations, add access groups.
4. Testing. We check each domain: routing, content display, editor permissions.
5. Deployment. We deploy to production, configure NGINX with proxy to a single gunicorn.

Comparison of approaches: shared vs separate models

Estimated timelines

Basic setup for 2–3 domains with shared models takes 1–2 days. Pricing is calculated individually. For separate brand configurations, custom media libraries, and access restrictions — 3–4 days. Migrating an existing single-domain site starts from 2 days. Exact cost depends on complexity — contact us to evaluate your project.

Why multi-site is better than separate installations?

A 5-minute Wagtail installer is an illusion. Maintaining five copies means updating code five times, setting up SSL five times, monitoring five times. Multi-site reduces these costs manifold. Per our measurements, clients save 40–60% on hosting and administration budget when switching to a single installation.

What's included in turnkey configuration

• Configuration of wagtailcore_site (domains, ports, root pages)
• Data migration for reproducibility
• Media library separation (optional: tags or separate image model)
• Access restrictions (groups, GroupPagePermission)
• NGINX configuration (one upstream, multiple server blocks)
• Documentation on adding a new site to the structure
• Caching and CDN recommendations

How to organize access restrictions?

We use GroupPagePermission programmatically through data migration — this guarantees the same permissions on all environments (dev/stage/prod). Editor of site A does not see site B. Example code:

def setup_brand_editors(brand_root_page, group_name): group, _ = Group.objects.get_or_create(name=group_name) GroupPagePermission.objects.get_or_create( group=group, page=brand_root_page, permission_type='change', ) GroupPagePermission.objects.get_or_create( group=group, page=brand_root_page, permission_type='publish', ) return group 

We guarantee stable operation under any load. Evaluate your project — contact us for a consultation. Don't postpone optimization — request an audit of your current architecture today.