Going Global with Umbraco

To be honest, “just make it multilingual” is one of those innocent-sounding requests that can quietly turn a tidy website project into a sprawling international headache.

On paper, it sounds simple enough. Add a language selector. Translate the pages. Job done. In reality, building a multilingual site that actually works for users, editors, and search engines takes a lot more thought than that. The good news is that Umbraco gives you a very solid foundation for doing it properly, provided you make the right decisions early. Whether you are working on multilanguage websites for one region or several, the same planning principles apply.

If you are figuring out how to build multilingual websites in Umbraco, the trick is not just enabling multiple languages. It is building a structure that can grow, keeping content manageable, and making sure the experience feels local rather than lazily translated.

This blog is here to help with exactly that.

Why multilingual websites go wrong so often

Most multilingual websites do not fail because the CMS cannot handle them. They fail because the team jumps straight into website translation before sorting out structure, governance, and user experience.

Here is where things usually wobble:

• First, the site structure gets messy. Pages are duplicated inconsistently, URLs vary from one language to the next, and nobody is quite sure which content should be shared and which should be localised.

• Second, editors are left with an awkward workflow. They are hunting through dozens of variants, copying content between languages, and trying to remember what is still in draft in German but already published in French.

• Third, SEO is treated as an afterthought. Missing hreflang tags, inconsistent metadata, and poor URL logic can make an international site much harder for search engines and local search engines to understand.

• Fourth is the user experience. A language switcher shoved into the header is not a multilingual strategy. People need clear navigation, content that respects their region and context, and confidence they are in the right place.

That is why a proper multilingual build needs more than a technical toggle. It needs planning.

If you are still at the early stages, it helps to get clear on the wider strategy behind Multilingual Umbraco Websites before getting lost in templates, translation spreadsheets, and disconnected SEO strategies.

Start with the right multilingual model

Before you touch content types or code, decide what kind of multilingual site you are actually building.

Not every translated website works the same way. In broad terms, most projects fall into one of three models.

The first is a straight translation model. Every language has largely the same pages, same structure, and same messaging, just translated. This is often the simplest option and suits organisations with consistent services across regions.

The second is a localised model. Core content may be shared, but individual markets need different messaging, case studies, legal content, offers, or calls to action. This is common when different countries have different audiences, expectations, or regulations.

The third is a hybrid model. Some areas of the site are tightly controlled and centrally translated, while others are adapted locally. This often works well for larger organisations that need brand consistency without strangling local relevance.

Why does this matter? Because your chosen model affects everything else: content structure, editorial permissions, navigation, workflows, and how much flexibility you build into the CMS.

A common mistake is assuming every page should exist in every language. That sounds neat until you realise some content has no local value whatsoever. Forcing one-to-one page duplication where it is not needed creates clutter for editors and confusion for users, especially across large content trees.

How Umbraco handles multilingual content

One of Umbraco’s strengths is that it gives you flexibility without feeling like a DIY disaster zone. As a web content management system built on Microsoft .Net, it is particularly well suited to teams that need structure without losing flexibility.

For multilingual projects, the key feature is Language Variants. These allow editors to manage multiple language versions of the same content node within a single content tree. Instead of creating a separate site for every language, you can keep related content together while still varying fields by language. In practice, this kind of multilanguage setup gives teams a much cleaner route into day-to-day content edition.

That setup can be incredibly tidy, but only if you use it thoughtfully.

For example, not every property needs to vary by language. A product code, internal reference, or shared media asset may stay the same across all regions. Headings, body copy, metadata, and certain calls to action probably should vary. Being deliberate about which fields are variant and which are invariant makes editing cleaner and reduces mistakes. In some cases, that includes understanding how a property editor behaves when culture variations are enabled.

Umbraco also supports dictionary items, which are useful for reusable interface text such as button labels, form prompts, and standard system messages. These work a bit like key-value pairs, giving teams a more controlled way to manage repeated interface copy across languages. That helps avoid hardcoding repeated phrases across templates. More importantly, it prevents editors from wasting time manually changing the same tiny snippets over and over again.

This is where teams often begin to see the bigger picture. Building multilingual content in Umbraco is not just about storing translations. It is about creating a manageable system. A well-structured multilingual website in Umbraco should make life easier for editors, not quietly ruin their week.

Plan your content structure before translation starts

If you want to know how to build multilingual websites in Umbraco properly, here is the unglamorous answer: map the content model before anyone starts translating.

That means answering a few important questions:

• Which Document Type settings need language variants

• Which sections will exist in all languages?

• Which pages are market-specific?

• Will URLs be translated or kept consistent?

• Who approves translated content before it goes live?

These are not tiny admin details. They shape the whole implementation.

A good rule of thumb is to separate global content, localisable content, and market-specific content as early as possible. That gives you a clearer picture of what can be reused and what needs independent ownership.

For example, a company overview page may exist in every language with mostly equivalent messaging. A legal or regulatory page may differ significantly by region. A news article may only be relevant in one country. If you force all three into the same editorial model, things get messy fast.

It is also worth deciding how you want to handle navigation. Some sites mirror the same nav structure in every language. Others allow local teams to adapt menus by market. Neither is universally right, but the choice should be intentional. At the root level, this often starts from the Home Page and flows down through the rest of the site structure.

And yes, URL structure matters too. Clear language-specific URLs usually make life easier for both users and search engines. Keeping things predictable helps enormously once the site starts to grow.

Translation is not the same as localisation

Here is where many multilingual projects start acting a bit too confident.

Translation changes words. Localisation changes meaning, tone, context, and relevance.

A sentence that reads perfectly well in English may land awkwardly in another market, not because the translator got it wrong, but because the original concept does not quite fit. Dates, currencies, measurements, forms of address, trust signals, examples, and cultural references all need consideration.

That is why multilingual websites that “technically work” can still perform badly. They may be readable, but they do not feel built for the audience.

When building in Umbraco, you should account for this by giving editors room to adapt content where necessary. That could mean allowing localised hero copy, region-specific calls to action, different imagery, or bespoke FAQ content. Trying to lock every market into a rigid translation model often produces content that feels flat and faintly robotic. This is also where content translation workflows need to be realistic. Some businesses use internal teams, while others bring in translation agencies for review and localisation support.

If your organisation is serious about international growth, localisation should be built into the workflow, not bolted on afterwards.

Think carefully about editorial workflow

A multilingual site is only as good as the team managing it after launch.

This is where plenty of builds look brilliant in staging and then become a maintenance nightmare the moment real editors get involved.

A better editorial setup usually includes:

• Clear ownership of each language or region

• Defined publishing workflows

• Visible status tracking for untranslated or outdated pages

• Guidance on what must be translated and what can be adapted

• A sensible process for updating shared content

Without that, you end up with half-updated pages, stale translations, and region-specific content drifting away from the brand.

Umbraco can support robust workflows, but the CMS alone will not save a muddled process. Editors need clarity. They need to know what they are responsible for, what happens when English content changes, and how to avoid publishing incomplete language variants. They also need the right editorial access so the right people can review, edit, and sign in to manage only the areas relevant to their market.

This is also the point where stakeholder expectations need managing. Not every market update can happen simultaneously. Not every page needs instant parity. A smart workflow prioritises the content that matters most and makes those decisions visible. Some teams also rely on a sensible fallback language model so users are never left staring at half-finished sections in their least favourite language of choice.

Do not treat multilingual SEO as a final checkbox

Nothing says “we launched too quickly” quite like a multilingual site with tangled indexing and inconsistent page signals.

If you are building a multilingual Umbraco site, SEO needs to be considered from the outset. That includes page structure, metadata, internal linking, canonical logic, and hreflang implementation.

The goal is to help search engines understand which version of a page is intended for which audience. It also helps avoid situations where multiple versions compete with each other or the wrong regional page appears in search.

A few principles matter here.

• Each language version should have unique, localised metadata where appropriate. Simply copying English page titles everywhere is lazy and rarely effective.

• URLs should be consistent and easy to interpret. Language-specific folders or domains can work well, provided the structure is coherent.

• Internal links should support discoverability across language versions without creating unnecessary confusion.

And yes, hreflang needs to be right. Not “roughly in the right ballpark”. Right.

This is one reason businesses often explore a more strategic approach to Umbraco language solutions for global sites rather than treating multilingual SEO as something to patch up after launch. It also helps to include performance monitoring from the outset so you can see how each market is actually performing, rather than just hoping the traffic graph behaves itself.