How to build a multilingual Umbraco site

What does a multilingual Umbraco setup need?

A multilingual site is more than a language switcher. Before translating content, decide which cultures the site will support, which fields vary by culture, how URLs will be routed, and who may edit and publish each language. These choices affect the content model, templates, navigation, SEO and editorial process.

Umbraco's language variants allow one content item to hold separate names and property values for different cultures. Shared properties remain invariant, while translatable properties receive a value for each enabled language.

1. Add the languages and fallback rules

Create the required languages under Settings → Languages. Choose the default language carefully, then decide whether a language is mandatory and whether it should fall back to another culture when a value is missing.

Fallback can be useful during rollout, but it should be deliberate: silently showing English on an otherwise French page may be acceptable during staging and confusing after launch.

2. Enable variants on the right content

Enable culture variation on each document type that represents multilingual content. Then mark the individual properties that need translated values. Typical variant fields include page names, headings, body copy, metadata and calls to action. IDs, media selections, colours, layout settings and many relationships normally remain shared.

For block-based pages, consider both the parent property and the fields inside each element type. A multilingual page model is easier to operate when the boundary between editorial text and structural configuration is explicit.

Which properties should vary, and which should be shared?

In Umbraco this is the Shared across cultures toggle on each property. Getting it wrong is expensive to undo once editors have entered content, so decide deliberately at build time. The guiding question is simple: would a French editor ever need this to differ from the English value?

A useful default is to share anything that is structural or referential, and vary anything a reader actually reads. Note that alt text and meta descriptions are the two most commonly left shared by mistake, and both are visible to users or search engines.

For the exact backoffice steps, see Umbraco's adding language variants tutorial.

3. Configure culture-specific URLs

Map cultures and hostnames at the appropriate root content node. A site might use country domains, language subdomains or language folders such as /en/ and /de/. Templates and navigation should resolve content using the active culture rather than assuming the default language.

For the precise CMS steps and rendering examples, use Umbraco's official multilingual-site tutorial.

It's a good idea to think ahead because even if you launch with just one language you might want to expand later, so bear that in mind when creating URLs and structuring content.

4. Decide how visitors reach their language

Once cultures resolve correctly, decide what happens when someone arrives at the site without choosing a language. There are three common signals, and they are not equally safe.

A dependable pattern is to layer them: honour an explicit choice the visitor has already made, otherwise use Accept-Language, and treat country only as a weak hint for suggesting a region.

Whichever signals you use, map them onto the cultures the site actually publishes and fall back to the default language when there is no confident match. A visitor requesting a language you do not offer should land on a working page, not an error.

5. Separate page content from interface text

Use content variants for editor-managed pages. Use Dictionary items for short interface strings owned by templates or code, such as “Read more”, form labels and validation text. Treating both as one problem usually makes ownership and maintenance less clear.

If a Dictionary contains many missing values, see how to translate Umbraco Dictionary items quickly.

6. Choose a translation workflow

7. Plan multilingual SEO

• Give every published language variant a stable, crawlable URL.
• Render the correct language in page titles, descriptions, headings and navigation.
• Add reciprocal hreflang annotations when the front end exposes equivalent regional or language pages.
• Use self-referencing canonical URLs rather than canonicalising every language to the source page.
• Include translated pages in the XML sitemap.
• Avoid publishing thin or partially translated variants merely to increase page count.

8. Measure whether the languages are working

Most multilingual sites launch without any way to tell which languages earn their keep. Because each culture has its own URL, per-language reporting usually needs no more than a little configuration.

What to set up

• Ensure the rendered <html lang> attribute is correct on every page — some analytics and accessibility tools read it, and it is trivially easy to leave hard-coded as English.
• Segment reporting by the language path or domain, so /de/ traffic can be compared against /en/.
• Track the language switcher as an event. Frequent switching away from a language is a strong signal that automatic detection or translation quality is wrong.
• In Google Search Console, submit each language section and watch impressions per country — this reveals demand you are not yet serving.

What the numbers tell you

This data is also the strongest argument for or against expanding. It converts "should we add Italian?" from an opinion into a question the traffic can answer, and it justifies the ongoing cost of keeping existing languages current.

Multilingual launch checklist

1. Languages, default culture and fallback behaviour are agreed.
2. Document types, element types and properties vary only where needed.
3. Domains or language folders resolve the correct culture.
4. Navigation, forms, search and error pages work in every published language.
5. Dictionary values and page content have named owners.
6. Editors understand draft, review and publish responsibilities.
7. Canonical, hreflang and sitemap output have been tested.
8. Language detection suggests rather than force-redirects, and the choice is remembered.
9. Analytics segment by language, and the language switcher is tracked.
10. A process exists for finding source content that changes after translation.