Insight

Choosing a CMS for a multilingual website: the questions that matter more than features

Most CMS comparisons focus on editors, templates and integrations. For a multilingual website, the decisive questions are different: how translations are linked, how local variations are handled, who approves each language and how the site prevents one language quietly falling out of date.

Published by Somnium Digital

A wireframe of the Insight page: headline, supporting sections and a single call to action. Insight Choosing a CMS for a multilingual… Get in touch 01 Multilingual is a con… 02 Questions to ask abou… 03 Translation workflows

Multilingual is a content model problem

A multilingual website is not just the same pages in several languages. Some pages are direct translations, some are local adaptations, some exist only in one market and some need different legal information, prices, contacts or examples. A CMS must represent those relationships clearly.

If the CMS treats each language as an unrelated page, teams lose track of which pages correspond. If it forces every page to exist in every language, local teams publish poor translations just to fill gaps. The right model supports equivalence where it exists and difference where the market needs it.

Questions to ask about content structure

Can a page be linked to its equivalents in other languages? Can some fields be shared across languages while others are translated? Can a market have its own version of a page without breaking the relationship to the original? Can pages exist in only selected languages? Can structured content such as services, locations and FAQs be translated consistently?

These questions determine whether the website remains manageable after the first launch.

Equivalents
Translations linked to their source and each other.
Shared fields
Images, prices or identifiers shared where appropriate.
Local variants
Market-specific content without losing the relationship.
Partial coverage
Pages published only in the languages that need them.

Translation workflows

Multilingual websites fail most often through workflow rather than technology. When the source page changes, translated versions should be flagged for review. Translators and reviewers need clear status: not started, in translation, in review, approved or published.

Integration with translation management systems can help larger organisations, while smaller teams may need a simple review queue. Machine translation can accelerate drafts, but important pages, legal content and languages with smaller translation markets need native review.

URLs, hreflang and search

The CMS should support clear language URL structures, such as language subdirectories, and generate hreflang annotations from linked translations. It should also allow translated page slugs, titles, descriptions and structured data rather than copying the source language metadata.

Avoid systems that switch language only with cookies or browser detection, because search engines and users need stable URLs for each language version.

Permissions and governance

A German market team may be allowed to edit German content but not Spanish content. Legal reviewers may need approval rights for certain pages in every language. Central brand teams may control shared components while local teams manage market-specific sections.

Role-based permissions and audit trails prevent accidental changes and make responsibility clear. Governance should also define which language is the source for each page and what happens when local content diverges.

Traditional, headless or static

Traditional CMS platforms combine content management and page rendering. Headless CMS platforms manage content and deliver it to separate front ends. Static site approaches generate pages from content files or a CMS at build time. Each can work for multilingual websites.

The choice should follow the organisation’s needs: editor experience, developer resources, performance, integration requirements, number of languages, publishing frequency and governance. A simpler system with a strong multilingual model often beats a more powerful system configured poorly.

Before choosing, test real scenarios: update a source page, create a local variant, publish a page in two languages only, check hreflang and review permissions. Demonstrations with sample content rarely reveal the problems teams face later.

Questions

What matters most in a multilingual CMS?

How translations and local variants are modelled, reviewed, published and kept current.

Should every page exist in every language?

Not necessarily. Pages should exist where they serve the market properly.

Can a CMS generate hreflang automatically?

Many can, if translations are linked correctly and URLs are stable.

Is machine translation enough for multilingual websites?

It can help drafts, but important and legal content needs native review.

Should we use a headless CMS?

It depends on editor needs, developer resources, integrations and performance. Multilingual modelling matters more than architecture labels.

How should we test a CMS before choosing?

Run real multilingual scenarios such as source updates, local variants, partial translations, hreflang and permissions.

Where this sits in what we do

This article covers one decision inside a wider engagement. The solution page sets out how that engagement runs, what it includes and what it costs to find out.

Planning a multilingual website?

We model multilingual content, choose or configure the CMS and build translation workflows, URLs and hreflang that stay manageable after launch.

Get in touch

Tell us what you are trying to change

Describe the problem rather than the service — the two frequently differ, and working out which is which is the useful part of a first conversation. We reply within one working day, and if it is outside what we do well you will hear that in the reply rather than after a call.

We use what you send to reply to you. Nothing else, and no list.

WhatsApp