One login. Every brand. All your sites, run from a single place.
Running separate sites for separate brands or branches usually means separate logins, separate headaches, and the same update made five times over. Umbraco multisite fixes that. It's one Umbraco CMS, one login, and proper content management for the whole group.
For Marketing Leads Managing Multiple Brands, Sites or Locations
One person, several websites, not enough hours.
If you're the one holding together a group structure, a franchise network, or a handful of regional sites, you already know the maths doesn't work. Every new offer, price change or compliance update means editing the same thing five, ten, fifteen times, and hoping nothing gets missed.
We build Umbraco multisite setups that let one team manage every site from a single backoffice, with the same login across the group, while each site keeps its own domain, branding and content. It's centralisation without losing what makes each site different. Whether that's a franchise network where every region website needs its own campaign settings, or a multi-brand group working to one shared marketing strategy, the structure adapts to how you actually work.
Why Teams come to us?
“I've got six sites and six sets of logins to remember.”
We build multisite in Umbraco so every site shares the same admin login. One editor, one password, every site in reach, no juggling separate CMS instances.
“When head office changes something, three sites don't get it.”
Shared content (legal pages, staff profiles, brand assets) updates once and publishes everywhere it's needed, so nothing gets missed on the sites nobody remembered to check.
“Every site looks slightly different and none of it feels like us.”
Shared templates and components keep the group consistent, while each site still has room for its own branding, region or audience where it actually matters.
“I don't trust who's editing what, or when.”
We set proper permissions per site and per team, with draft, review and approval built in, so a regional edit can't accidentally go live across the whole group.
The Gecko Way™
Our approach to successful projects
Before we touch a content tree, we want to understand your actual structure: how many sites, how many brands, which ones share an audience and which don't. For a franchise, that means understanding what head office controls versus what each location needs to own locally, price boards, opening hours, local contact details. For a group of businesses, it means mapping which content genuinely overlaps (legal pages, staff bios, a shared blog) against what has to stay distinct (tone, offers, positioning). We'll also ask the less glamorous questions early: who edits what today, who should be editing it in future, and what's gone wrong the last time something needed updating across every site at once. We'll also want to know how content ownership currently sits, who owns what across the group, whether there's any content governance in place at all, and roughly how many root nodes and document types we're likely to be planning for.
We look at what you're running now, whether that's several disconnected CMS instances, a tangle of WordPress installs, or an existing Umbraco site that's grown past what it was built for. We check what's genuinely shared across your sites and what only looks shared because nobody's separated it out properly yet. This is also where we're honest about scale: multisite in Umbraco works brilliantly for a handful of related sites sharing one team and one governance model, and we'll tell you plainly if your setup would actually be better served by separate Umbraco Cloud projects instead of one shared instance. We're also checking whether your current Umbraco CMS version can support what you're asking of it. Umbraco itself is built to handle genuinely content-rich applications and a wide range of content types, not just a handful of brochure sites bolted together, which matters if you've spent years building websites piecemeal and now need them working as one group.
We build your multisite structure with each site as its own root node, its own domain mapped through Umbraco's hostname setup, and its own content tree, sitting inside one Umbraco project with one shared login. Shared components, testimonial blocks, navigation patterns, page templates, get built once and reused everywhere they're needed, while each site keeps the document types and layout options it needs to stay distinct. If you're on Umbraco Cloud, we'll set this up using Baselines rather than cramming every site into a single project, which keeps things faster and steadier as the group grows. Nothing goes live until you've seen how it actually behaves, not just how it looks in a deck. The same approach works whether you're setting up on Umbraco Cloud or running self-hosted Umbraco on your own Microsoft infrastructure, the content architecture stays the same either way.
A multisite setup is only as good as the people using it day to day, so we don't hand over a login and disappear. We show your team exactly what's shared and what isn't, how permissions work for each site and each role, and how a change to shared content actually ripples out. If you've got a regional team who should only ever touch their own site, we'll show you how that's enforced, not just promised. The goal is that nobody on your team needs to ask us before they understand what a change will actually affect. That means walking your editors through the actual screens, the Content section, the user groups controlling who sees what, so none of it feels like guesswork once we've gone.
Once your sites are live, you're not left checking six places to see if anything's broken. Our support team keeps an eye on the whole group, patches and updates roll out with the group's structure in mind, and if a new site or brand joins later, it slots into the same setup rather than starting from scratch. Because everything sits on the same foundation, fixes and improvements can often be rolled out across every site at once instead of one at a time. You stay the person who understands the structure, not the only person who can maintain it. Day-to-day site operations, patching, monitoring, small fixes, stay with our support team, so multisite administration doesn't become another job on your plate, and content governance stays consistent, governed by the same user groups, as new sites join.
What's Included in Umbraco Multisite Development
Multisite Architecture & Planning
Before any build work starts, we map out your sites as root nodes within a single Umbraco project, deciding what genuinely needs its own content tree, template set and document types, and what can be shared without causing problems later.
This is where we settle the shared-versus-site-specific question properly: legal pages, staff profiles and blog content usually sit in one place and show wherever needed, while landing pages, local offers and regional messaging stay owned by each individual site. Getting this split right at the planning stage is what stops a multisite build turning into a tangle six months in, when someone tries to make one site do something the structure was never built for.
This is also where we settle your content models and content types, so every site's document types stay consistent enough to manage centrally, with a settings node on each site for anything genuinely site-specific like fonts, contact details or local offers, and clear content governance built in from the start. Where it helps, we'll also flag related content between sites, a shared case study or a group-wide offer, so nothing gets duplicated by accident.
Same-Login, Multi-Site Backoffice
Every site in your group sits behind the same Umbraco admin login, so your team isn't juggling separate CMS instances, separate passwords or separate places to check for updates. One backoffice, every site visible from it, each one still entirely its own website with its own domain and content.
For a franchise network or a group of related businesses, this alone tends to be the single biggest time saver: no more logging into five different systems to make the same change five times, and no more wondering which login belongs to which site. Think of it as a single multi-site content hub for the group: one content management platform, one place to check site operations and multisite administration across every location.
Umbraco Cloud Multisite Setup
If your sites are hosted on Umbraco Cloud, we don't just cram every site into one project and hope for the best. We use Umbraco Cloud's Baseline functionality to structure your multisite properly, which avoids the usage limits and performance drag that can come from stacking too many sites into a single environment, and gives you more stability as the group grows.
We'll talk you through the trade-offs honestly: a shared instance is brilliant when your sites genuinely share governance, content and a team, but if two of your sites need very different technical setups or security requirements, we'll say so, rather than forcing everything into one box because it's tidier for us.
Not every group needs Umbraco Cloud multisite specifically. Some are better suited to self-hosted Umbraco, or a straightforward Cloud and On-Premise Deployment split, and we'll recommend whichever genuinely fits rather than defaulting to one answer.
Permissions, Workflows & Governance
Multisite only stays manageable if the right people can touch the right things, and nothing else. We set up permissions per site and per role, so a regional editor can update their own site without being able to touch shared brand content, and a central team can manage group-wide pages without needing separate access to every individual site.
Draft, review and approval workflows sit on top of this, which matters more here than on a single site, because a mistake on shared content doesn't stay contained to one place, it shows up everywhere that content is used. Under the hood, this runs on Umbraco's user groups, so publishing control and custom workflows can be set per site, per section of the site, or per role, with launch controls to stop anything going live before it's ready.
It's what proper content governance actually looks like in practice, not just a policy document nobody follows. If any of your sites need member authentication for customer accounts, or Members Registration for a franchise portal, that sits entirely separately from editor access.
Shared Components & Brand Consistency
We build reusable components, navigation, forms, testimonial blocks, content modules, once, so every site in your group can use them without a developer rebuilding the same thing five times over. Where your brands share DNA but need their own identity, we set up theme-level controls so colours, fonts and spacing can differ site to site while the underlying build stays the same.
The result is a group of sites that clearly belong together without being identical, and a codebase your developers, ours or yours, can actually maintain without dread. We tend to build these using Umbraco's block list editor rather than the older grid property, which gives editors more control over visual elements like layout and spacing without needing a developer for every change.
Media, SEO & Technical Foundations
Without proper rules, multisite setups quietly duplicate the same logo and the same oversized image across every site in the group. We set up shared media folders and naming conventions so your library stays usable rather than a scavenger hunt. On the technical side, we handle hostname mapping, SSL and canonical strategy properly across every site, so near-identical content across your group doesn't end up competing with itself in search results.
If any of your existing sites are running on an older Umbraco version, we'll flag where that setup falls short of current multisite best practice before we build on top of it. Each site also gets its own custom error pages for HTTP errors like 404s, and its own XML Site Map, so search engines index every site correctly rather than treating the group as one confused entity.
A single shared media folder underneath means nobody's re-uploading the same logo for the fifth time. And where legacy Umbraco versions need bringing forward first, that's exactly what our migration and upgrade services are for, including content migration for sites moving into the multisite structure for the first time.
What's Included in Umbraco Multisite Development
Multisite Architecture & Planning
Before any build work starts, we map out your sites as root nodes within a single Umbraco project, deciding what genuinely needs its own content tree, template set and document types, and what can be shared without causing problems later.
This is where we settle the shared-versus-site-specific question properly: legal pages, staff profiles and blog content usually sit in one place and show wherever needed, while landing pages, local offers and regional messaging stay owned by each individual site. Getting this split right at the planning stage is what stops a multisite build turning into a tangle six months in, when someone tries to make one site do something the structure was never built for.
This is also where we settle your content models and content types, so every site's document types stay consistent enough to manage centrally, with a settings node on each site for anything genuinely site-specific like fonts, contact details or local offers, and clear content governance built in from the start. Where it helps, we'll also flag related content between sites, a shared case study or a group-wide offer, so nothing gets duplicated by accident.
Same-Login, Multi-Site Backoffice
Every site in your group sits behind the same Umbraco admin login, so your team isn't juggling separate CMS instances, separate passwords or separate places to check for updates. One backoffice, every site visible from it, each one still entirely its own website with its own domain and content.
For a franchise network or a group of related businesses, this alone tends to be the single biggest time saver: no more logging into five different systems to make the same change five times, and no more wondering which login belongs to which site. Think of it as a single multi-site content hub for the group: one content management platform, one place to check site operations and multisite administration across every location.
Umbraco Cloud Multisite Setup
If your sites are hosted on Umbraco Cloud, we don't just cram every site into one project and hope for the best. We use Umbraco Cloud's Baseline functionality to structure your multisite properly, which avoids the usage limits and performance drag that can come from stacking too many sites into a single environment, and gives you more stability as the group grows.
We'll talk you through the trade-offs honestly: a shared instance is brilliant when your sites genuinely share governance, content and a team, but if two of your sites need very different technical setups or security requirements, we'll say so, rather than forcing everything into one box because it's tidier for us.
Not every group needs Umbraco Cloud multisite specifically. Some are better suited to self-hosted Umbraco, or a straightforward Cloud and On-Premise Deployment split, and we'll recommend whichever genuinely fits rather than defaulting to one answer.
Permissions, Workflows & Governance
Multisite only stays manageable if the right people can touch the right things, and nothing else. We set up permissions per site and per role, so a regional editor can update their own site without being able to touch shared brand content, and a central team can manage group-wide pages without needing separate access to every individual site.
Draft, review and approval workflows sit on top of this, which matters more here than on a single site, because a mistake on shared content doesn't stay contained to one place, it shows up everywhere that content is used. Under the hood, this runs on Umbraco's user groups, so publishing control and custom workflows can be set per site, per section of the site, or per role, with launch controls to stop anything going live before it's ready.
It's what proper content governance actually looks like in practice, not just a policy document nobody follows. If any of your sites need member authentication for customer accounts, or Members Registration for a franchise portal, that sits entirely separately from editor access.
Shared Components & Brand Consistency
We build reusable components, navigation, forms, testimonial blocks, content modules, once, so every site in your group can use them without a developer rebuilding the same thing five times over. Where your brands share DNA but need their own identity, we set up theme-level controls so colours, fonts and spacing can differ site to site while the underlying build stays the same.
The result is a group of sites that clearly belong together without being identical, and a codebase your developers, ours or yours, can actually maintain without dread. We tend to build these using Umbraco's block list editor rather than the older grid property, which gives editors more control over visual elements like layout and spacing without needing a developer for every change.
Media, SEO & Technical Foundations
Without proper rules, multisite setups quietly duplicate the same logo and the same oversized image across every site in the group. We set up shared media folders and naming conventions so your library stays usable rather than a scavenger hunt. On the technical side, we handle hostname mapping, SSL and canonical strategy properly across every site, so near-identical content across your group doesn't end up competing with itself in search results.
If any of your existing sites are running on an older Umbraco version, we'll flag where that setup falls short of current multisite best practice before we build on top of it. Each site also gets its own custom error pages for HTTP errors like 404s, and its own XML Site Map, so search engines index every site correctly rather than treating the group as one confused entity.
A single shared media folder underneath means nobody's re-uploading the same logo for the fifth time. And where legacy Umbraco versions need bringing forward first, that's exactly what our migration and upgrade services are for, including content migration for sites moving into the multisite structure for the first time.
"When a client's team adds a new site to the group now, it slots straight into permissions we've already built, not a fresh set of logins for someone to get wrong."
Marlon Dedakis, Lead Developer at Gecko
Multisite Case Study
[PLACEHOLDER — no confirmed multisite case study or metric is currently available to reference here. Do not populate this section with an invented statistic or project name. Once a real multisite project and metric are confirmed, this section should follow the standard format: ~60–70 word paragraph, one standout metric, linked case study name.]
No, though the two often get mixed up. Multisite means running several genuinely separate websites, each with its own domain and audience, from one Umbraco project. Multilingual means one site presenting the same content in different languages. You can combine the two (a multisite setup where individual sites are also multilingual) but they solve different problems. If your real need is one audience in several languages rather than several distinct sites, that's a different build, and we'll say so before quoting for the wrong thing. Umbraco's own multilanguage support handles the language side well on its own, without needing a multisite structure at all.
No. Each site gets its own root node, its own content tree, and its own templates where needed. Shared components (navigation patterns, forms, testimonial blocks) can be reused across sites to save development time, but each site can still have its own branding, layout and tone. Multisite is about shared infrastructure and, where you want it, a shared admin login, not identical design. Each site can also have its own document types where genuinely needed, or share them with the rest of the group where consistency matters more.
Yes, that's one of the main reasons clients come to us for this. Umbraco multisite runs from a single backoffice, so your team logs in once and can see every site they've got permission for, rather than juggling separate CMS instances and separate passwords for each one. Permissions still control exactly what each person can touch, so one login doesn't mean one person can accidentally edit everything. Behind the scenes, that's controlled through Umbraco's user groups, so access always matches what someone's actually meant to see.
Broadly yes, though we'd usually recommend a slightly different setup. On Umbraco Cloud, we typically build multisite using Baselines rather than stacking every site into a single project, which avoids the usage limits and performance issues that can come with running several busy sites through one shared environment. We'll talk you through what fits your specific group of sites before recommending either approach.
Umbraco itself is built to handle serious scale, and plenty of large organisations run it. But that's not who we're speaking to here. We work with groups, franchises and multi-brand businesses that need several well-built, properly connected sites, not a sprawling enterprise deployment. If that's genuinely what you need, we're happy to have that honest conversation rather than stretching to fit a job that isn't ours to do well. Umbraco's one of a handful of content platforms genuinely built to handle that kind of scale, which is exactly why it suits a growing multi-site group even without a full enterprise deployment.
As a rule, anything genuinely the same everywhere (legal pages, staff profiles, group-wide announcements, a shared blog) is worth centralising, so it only needs updating once. Anything genuinely local or brand-specific (landing pages, regional offers, local contact details, individual site messaging) should stay owned by that site. We map this properly during planning rather than guessing, because getting the split wrong is the single biggest cause of multisite setups turning messy.
Yes, and it's one of the clearest use cases for it. A new location becomes a new site within the same Umbraco project, inheriting the shared components, permissions structure and brand foundations you've already got, rather than starting a build from scratch each time. What usually needs deciding per new site is the local content: address, opening hours, local team, local offers, and we can set up templates that make adding that quick for whoever's responsible for it.
Not if it's built properly. Umbraco's own guidance is honest that stacking many sites into one project can increase resource use, which is exactly why we plan capacity and, on Umbraco Cloud, use Baselines rather than defaulting to a single crowded project. We'll tell you upfront if your group of sites is better served by a different technical split, rather than selling you one big shared instance regardless of whether it's the right fit. Day-to-day site operations stay smooth either way, that's the point of planning capacity properly up front rather than after something breaks.
It depends on how many sites you're consolidating and how tangled the current setup is, but most groups are looking at several weeks for planning and architecture before build work starts in earnest. Migrating existing sites into the new structure typically takes longer than building fresh ones, since we're untangling what's actually shared versus duplicated along the way. We'll give you a proper timeline once we understand your specific sites, not a generic estimate that ignores the state you're starting from. Either way, a multisite solution should feel simpler once it's live, not just different.
Yes, though it's a different conversation to a standard multisite build. If some of your sites need to feed content into other places, a native app, a partner site, a kiosk display, we can set up API delivery alongside the multisite structure itself. That's usually done through API-Driven Content Delivery for the specific sites that need it, rather than converting the whole group to a Headless Umbraco CMS setup unless every site genuinely needs one. We'll ask what's actually pulling the content before recommending either approach.
The honest answer is it depends on how much your sites genuinely share, team, governance, content, and how much they need to stay distinct. Rather than guess from here, book a free consultation and we'll talk through your specific sites, what's shared, what's separate, and whether one Umbraco multisite setup is actually the right call, or whether you're better served by something else entirely. If ongoing multisite administration is the real worry rather than the build itself, we can take that off your plate entirely too.
