A multilingual website that actually works in every market you serve.
Umbraco's built to run multilingual sites properly, one content tree, editors who aren't drowning in duplicate pages, and search engines that actually understand what's translated and what's not.
For Marketing Leads Managing Sites Across Several Markets
You don't need six websites. You need one that behaves like it.
If you're the one holding a multi-market website together, whether that's a Marketing Lead juggling five language versions, a Digital Lead inheriting a site nobody planned, or an Ops Director watching translation costs creep, the priority's the same: consistency, without the firefighting. It's the same brief whether you're a single UK organisation adding a second language or one of the international companies we work with running five, the user experience has to feel considered in every market, not bolted on.
We build the content structure and editorial workflow before we touch a single translated word, so your team knows exactly what's shared, what's local, and who signs off what. No guesswork, no duplicated pages nobody remembers creating.
Why Teams come to us?
“Our translations feel like an afterthought.”
We plan the content model and language variants before translation starts, so every market gets proper structure, not a bolted-on afterthought.
“We don't know what's translated and what's out of date.”
Umbraco's Language Variants keep every version in one content tree, with clear status tracking, so nobody's publishing English updates while French quietly goes stale.
“Every new market means starting the website from scratch.”
We build one content model that scales, straight translation, localised, or hybrid, so adding a market means configuring, not rebuilding.
“Our multilingual SEO is a mess of duplicate content.”
We set hreflang, canonicals and translated metadata properly from the outset, so search engines know exactly which page belongs to which market.
The Gecko Way™
Our approach to successful projects
Before we open Umbraco, we get a clear picture of who actually needs what. Which markets are live, which are next, and which pages genuinely need a local voice versus a straight translation. We'll ask which language is your source (usually English), who owns approval in each market, and what's gone wrong before, an untranslated page still sitting in the main menu, a French site quietly six months out of date. We also look at how your audience actually searches in each market, because keyword research doesn't translate word for word any more than your copy does. This stage is about decisions, not development, so nothing gets built on assumptions. We'll also flag any language variation worth planning for early, UK English and US English needing different spelling and tone, or French for France reading differently to French for Canada, so it's decided upfront rather than discovered halfway through translation.
e map your content against the three structural models, straight translation, localised, or hybrid, and work out which one your business actually needs rather than which sounds most impressive. Most sites end up somewhere in the hybrid middle: core pages shared and centrally translated, others adapted per market for legal, cultural or competitive reasons. We also audit what's shareable, product data, imagery, system text, and what genuinely needs local editorial control. If you're inheriting an existing multilingual site, this is where we work out what's salvageable in Umbraco's Language Variants and what needs rebuilding properly, rather than patched again.
This is where the content model gets built in Umbraco, using Language Variants so every market lives inside one content tree instead of a tangle of separate sites. We set up dictionary items for repeated interface text, structure URLs so they're consistent and correctly targeted per language, and configure hreflang, canonicals and translated metadata from day one rather than retrofitting them later. Design and templates are built to flex for different text lengths and reading directions, because a headline that fits in English rarely fits the same way in German. Nothing goes live until the structure holds up, not just the visuals. Where a market needs a Right-to-Left language, such as Arabic or Hebrew, that's planned into the template from the start, not patched in as an afterthought once the rest of the site's built.
We hand over more than login details. Your editors get clear guidance on what needs proper translation, what can be adapted, and what stays shared across markets, so nobody's left guessing which version they're looking at. We talk you through fallback behaviour for pages that aren't translated yet, and show you exactly how status tracking works in Umbraco so it's obvious at a glance what's live, in draft, or overdue. If machine translation's part of your workflow, we're honest about where it helps and where it needs a human editor's eye, particularly for anything legal, technical or brand-sensitive.
Multilingual sites drift out of sync quietly if nobody's watching, so we agree a governance model before we hand back the keys: who owns source content, who approves translations, and what happens when something changes in one market but not another. Our support team keeps an eye on the technical side, hosting, security, performance, across every language version, not just the English one. And because search behaviour and market priorities shift, we'll flag when it's worth revisiting your structure rather than letting five language versions quietly go their separate ways.
What's Included in a Multilingual Umbraco Website
Language Variants Setup
We build your multilingual site around Umbraco's Language Variants, so every market lives inside one content tree rather than a separate site per language. In practice, it works page by page: you'll have an English version of a page, then a French version of that same page sitting right alongside it, switchable from a simple dropdown rather than living on an entirely different site.
That means one place for editors to work, one structure to maintain, and no risk of markets drifting apart because they're technically separate systems. We decide, page by page, what should vary by language and what should stay shared, product codes, shared media, internal references, so editors aren't retranslating things that never needed translating in the first place.
Dictionary items handle repeated interface text, buttons, form prompts, system messages, so nothing gets hardcoded in one language and forgotten when a new market's added. On the front end, that same setup powers a simple language switcher, so visitors can move between versions without hunting for it, and language selection never depends on guesswork from their browser settings alone.
Content Model & Governance Planning
Before any translation starts, we map your content against the three multilingual models, straight translation, localised, or hybrid, and agree which pages need which treatment. We define what's genuinely global, what needs local adaptation, and what's market-specific from the outset, so you're not forcing every page into every language just because the last one had it.
We also set the governance rules that keep things sane later: who owns source content, who signs off translations, and what happens automatically when something changes in one market but hasn't been updated in another. It's the planning work most multilingual projects skip, and the reason most multilingual projects go wrong. Multi-language websites succeed or fail on this planning stage more than any other, which is exactly why we don't skip straight to translation.
Multilingual SEO & Hreflang
A multilingual site is only as good as search engines' understanding of it. We set hreflang tags correctly across every language and region, build translated metadata and title tags for each market rather than duplicating the English versions, and make sure URLs are structured consistently so nothing gets flagged as duplicate content.
We don't translate keywords word for word either, because search behaviour genuinely differs by market, so we do local keyword research for each language you're targeting. Canonical logic gets set up properly from the start, so translated pages point to themselves, not quietly back to the English original.
Get this right and each market's pages show up properly in local search results rather than competing against each other. That's really what multilingual search engine optimization comes down to, hreflang annotations telling Google Search and other engines which version to serve, and clean structure doing the rest.
Translation & Localisation Workflow
Translation changes the words. Localisation changes whether the page actually makes sense to someone in that market, dates, currency, forms of address, trust signals, imagery, even which case studies you lead with. We help you decide what needs full localisation and what's fine as a straight translation, then build the editorial workflow around it, source language, review stages, and clear sign-off before anything goes live.
If machine translation's useful for your first drafts, we'll help you use it sensibly, with human review built in as a step, not an afterthought, especially for anything legal, technical or brand-critical. For anything nuanced or high-stakes, we'll bring in professional translation rather than relying on templates alone, and make sure the result fits your glossary and tone of voice, not just the dictionary definition.
That includes something as simple as date formats, since 03/04/2026 means a different day depending which market's reading it. Media translations matter too, images with embedded text, PDFs and video captions are all media content that needs the same localisation attention as your page copy.
Editor Training & Documentation
Your team ends up running this, so we make sure they actually can. We walk your editors through the finished content structure, show them exactly which fields vary by language and which don't, and document what needs translating versus adapting versus leaving alone.
We cover fallback behaviour for pages that aren't translated yet, whether that's hiding them from navigation or showing a clear placeholder, and make sure status tracking is obvious at a glance, so nobody's asking "which version did you translate?" three months after launch. Clear documentation now saves a lot of confused Slack messages later.
Ongoing Multilingual Support
Multilingual sites need watching, because content drifts out of sync quietly if nobody's checking. Our support team keeps an eye on the technical side, hosting, performance, security patching, across every language version, not just the main one.
If a new market comes on board, we help you extend the existing structure rather than starting again, and if search behaviour or your business priorities shift, we'll flag when it's worth revisiting your multilingual setup rather than letting it drift. You'll have a direct line to the same team who built it, not a ticket queue that starts from zero every time.
What's Included in a Multilingual Umbraco Website
Language Variants Setup
We build your multilingual site around Umbraco's Language Variants, so every market lives inside one content tree rather than a separate site per language. In practice, it works page by page: you'll have an English version of a page, then a French version of that same page sitting right alongside it, switchable from a simple dropdown rather than living on an entirely different site.
That means one place for editors to work, one structure to maintain, and no risk of markets drifting apart because they're technically separate systems. We decide, page by page, what should vary by language and what should stay shared, product codes, shared media, internal references, so editors aren't retranslating things that never needed translating in the first place.
Dictionary items handle repeated interface text, buttons, form prompts, system messages, so nothing gets hardcoded in one language and forgotten when a new market's added. On the front end, that same setup powers a simple language switcher, so visitors can move between versions without hunting for it, and language selection never depends on guesswork from their browser settings alone.
Content Model & Governance Planning
Before any translation starts, we map your content against the three multilingual models, straight translation, localised, or hybrid, and agree which pages need which treatment. We define what's genuinely global, what needs local adaptation, and what's market-specific from the outset, so you're not forcing every page into every language just because the last one had it.
We also set the governance rules that keep things sane later: who owns source content, who signs off translations, and what happens automatically when something changes in one market but hasn't been updated in another. It's the planning work most multilingual projects skip, and the reason most multilingual projects go wrong. Multi-language websites succeed or fail on this planning stage more than any other, which is exactly why we don't skip straight to translation.
Multilingual SEO & Hreflang
A multilingual site is only as good as search engines' understanding of it. We set hreflang tags correctly across every language and region, build translated metadata and title tags for each market rather than duplicating the English versions, and make sure URLs are structured consistently so nothing gets flagged as duplicate content.
We don't translate keywords word for word either, because search behaviour genuinely differs by market, so we do local keyword research for each language you're targeting. Canonical logic gets set up properly from the start, so translated pages point to themselves, not quietly back to the English original.
Get this right and each market's pages show up properly in local search results rather than competing against each other. That's really what multilingual search engine optimization comes down to, hreflang annotations telling Google Search and other engines which version to serve, and clean structure doing the rest.
Translation & Localisation Workflow
Translation changes the words. Localisation changes whether the page actually makes sense to someone in that market, dates, currency, forms of address, trust signals, imagery, even which case studies you lead with. We help you decide what needs full localisation and what's fine as a straight translation, then build the editorial workflow around it, source language, review stages, and clear sign-off before anything goes live.
If machine translation's useful for your first drafts, we'll help you use it sensibly, with human review built in as a step, not an afterthought, especially for anything legal, technical or brand-critical. For anything nuanced or high-stakes, we'll bring in professional translation rather than relying on templates alone, and make sure the result fits your glossary and tone of voice, not just the dictionary definition.
That includes something as simple as date formats, since 03/04/2026 means a different day depending which market's reading it. Media translations matter too, images with embedded text, PDFs and video captions are all media content that needs the same localisation attention as your page copy.
Editor Training & Documentation
Your team ends up running this, so we make sure they actually can. We walk your editors through the finished content structure, show them exactly which fields vary by language and which don't, and document what needs translating versus adapting versus leaving alone.
We cover fallback behaviour for pages that aren't translated yet, whether that's hiding them from navigation or showing a clear placeholder, and make sure status tracking is obvious at a glance, so nobody's asking "which version did you translate?" three months after launch. Clear documentation now saves a lot of confused Slack messages later.
Ongoing Multilingual Support
Multilingual sites need watching, because content drifts out of sync quietly if nobody's checking. Our support team keeps an eye on the technical side, hosting, performance, security patching, across every language version, not just the main one.
If a new market comes on board, we help you extend the existing structure rather than starting again, and if search behaviour or your business priorities shift, we'll flag when it's worth revisiting your multilingual setup rather than letting it drift. You'll have a direct line to the same team who built it, not a ticket queue that starts from zero every time.
"I always check the fallback rules before we sign off a language variant, so an editor never accidentally publishes a half-translated page to a live market."
Marlon Dedakis, Lead Developer at Gecko
Multilingual Umbraco Case Study
[Case study details to be added once a suitable multilingual project is confirmed for public use.] The shape of the work we're looking to show here: an organisation running several language versions with no shared governance, duplicate URLs confusing search engines, and an editorial team unsure which page was actually live in which market, rebuilt around Umbraco's Language Variants with proper hreflang, metadata and one clear source of truth.
Not in the DIY, drag-and-drop sense. Umbraco's a content management system, and a genuinely capable one for multilingual work, but it's built to be configured and structured properly for your business rather than assembled from a template. If you've been searching for a multilingual website builder expecting something you can set up yourself in an afternoon, worth knowing upfront: the sites that work well long-term are the ones where the content model and governance get planned first. That's the bit a builder tool skips, and the bit that actually determines whether your multilingual site holds up.
There's no single "best" that fits every organisation, but Umbraco's Language Variants feature makes it a strong option for most. It keeps every language version of a page inside one content tree, rather than forcing you to manage separate sites per market, which makes editing, governance and SEO considerably easier to keep consistent. If your markets need substantially different navigation, products or legal content, a hybrid setup with some separate structure alongside variants can work better. We'll talk you through which shape fits your actual markets rather than defaulting to whichever sounds most impressive. There are other capable CMS platforms out there, but few combine content governance and language variants as tightly as Umbraco does out of the box, and a website builder aimed at a single market rarely holds up once translation and governance enter the picture.
No, and forcing it usually makes things worse. Translating every page into every language creates thin, sometimes empty pages that exist purely to mirror the English structure, which helps nobody. We work out which pages genuinely deliver value in each market and translate those properly, rather than ticking a box for pages nobody in that market will read.
Translation changes the words. Localisation changes whether the page actually lands with someone in that market, the dates, currency, forms of address, trust signals, imagery, and sometimes which case studies or offers you lead with. A page can be perfectly translated and still feel foreign if the localisation's been skipped. We plan for both from the start, rather than treating localisation as a nice-to-have if there's budget left over.
It depends on how different your markets actually are. A straight translation model suits organisations with consistent services and messaging everywhere. A localised model suits businesses where individual markets need genuinely different content, offers or legal wording. A hybrid model, core pages shared and centrally translated, others adapted locally, suits most mid-sized organisations we work with, because it protects brand consistency without forcing every market into an identical mould. We'll help you work out which one actually matches your business rather than assuming. This decision matters most for anyone weighing up a single multilingual website against a fully separate regional site per market, since the two solve different problems and cost very differently to maintain.
The core feature is Language Variants, which let editors manage multiple language versions of the same content node inside a single content tree, rather than running a separate site per language. It's managed page by page: open a page, and if a language variant's enabled, there's a dropdown to switch language and see (or write) the translated version of that same page. Not every property needs to vary by language, product codes and shared media often don't, while headings, body copy and metadata usually should. Umbraco also supports dictionary items for reusable interface text, buttons, form prompts, system messages, so you're not hardcoding the same phrase six different ways across six languages. All of your CMS content, not just the page text, benefits from this structure, because the underlying data stays consistent even as the display language changes.
Yes, with care. It's genuinely useful for speed and first drafts, but it's not a substitute for human review, particularly for legal, technical, healthcare or brand-sensitive content. We usually recommend building a glossary or style guide so terminology stays consistent, and treating machine translation as the starting point in your workflow rather than the finished product. Tools like Google Translate are fine for a quick first pass, but full automation isn't the goal here, a human editor needs to check anything client-facing before it goes live.
Get hreflang, canonical tags and translated metadata right from the start, rather than retrofitting them once you notice search performance dipping. Each language version needs its own genuinely localised metadata, consistent URL structure, and keyword research done for that market specifically, because search behaviour rarely translates word for word. This is planning work, not a launch-day checklist item, which is exactly where most multilingual SEO problems come from.
Yes, if the content model was built to scale in the first place. This is one of the main reasons the planning stage matters so much: a structure built around Umbraco's Language Variants from day one means adding a new market is a configuration job, not a rebuild. Sites that skip this planning tend to hit a wall the moment a second or third language gets added. Whether you call it a multilingual website or a multi-language website, the planning principle's the same: build the structure to scale before you need it to.
The best next step is a conversation about your specific markets, current setup and where things are going wrong today. Book a consultation and we'll talk you through what building multilingual websites properly would actually look like for your organisation, no pressure, no jargon.
