Multilingual business websites: what to decide before translating

Choose languages around real customers and enquiries, not the number of flags you can fit in a header. Ask where demand comes from, what people need to understand before contacting you and whether your team can continue the conversation in that language.

An English version might serve international businesses in the Netherlands rather than a new office overseas. Write down that audience explicitly. If delivery areas, availability or support differ, agree what the website should say before translating promises that the business cannot fulfil.

You do not have to translate an entire archive on day one. Start with a useful route through the business: the offer, evidence, practical questions and a way to get in touch. A translated homepage followed by service pages in another language leaves that route unfinished.

Create a page inventory and mark what will be shared, adapted, published later or omitted. Include the less visible content too: form errors, confirmation messages, downloads, appointment tools and transactional emails. Check third-party tools separately; translating your own interface does not translate theirs.

Some information should stay aligned across versions: a product specification, the ownership of a service or an agreed process. Other material may need adaptation, such as examples, terminology, currency displays or the questions customers ask. Literal translation is not a substitute for deciding what is relevant.

Document these differences before selecting a CMS workflow. Editors need to know whether changing a shared field affects every language and how a translation awaiting review is marked. Ask the developer to demonstrate a real update, including a missing translation, rather than only showing three finished pages.

Google recommends separate URLs for language versions. Decide how yours will be organised before they become part of campaigns, documents and search results. Language directories such as /nl/ and /en/ are one practical option; the right choice also depends on the existing site and who will operate it.

Create a map of equivalent pages and use it for navigation and implementation. The translated slug may differ while the page still answers the same question. Record changes to existing URLs and any redirects separately so that adding a language does not accidentally break established links or campaigns.

Hreflang annotations connect equivalent language versions. The set should include the page itself and reciprocal links between versions. A developer should validate the rendered output, not just a setting in an administration screen.

Canonical URLs serve a different purpose: identifying the preferred URL among duplicates. Do not canonicalise every translated page to the original language. Keep the preferred URL in the same language, and align the sitemap and internal links with that choice.

These checks help make the structure coherent; they are not a promise of rankings. Choose useful questions and appropriate terminology for each audience. Before launch, check titles, descriptions and page content in every version rather than assuming that translated navigation completes the SEO work.

Label languages clearly, for example Nederlands, English and Español. Flags alone are an ambiguous shortcut for a language. Where an equivalent exists, changing language should open that page rather than send everyone back to the homepage.

Avoid forcing visitors away from an explicitly chosen language URL. Make the selector work with a keyboard, and test longer labels, headings and buttons on a phone. Set the page language correctly so assistive technology can apply suitable pronunciation. Also check error messages, dates and contact details: small inconsistencies become most noticeable when someone is trying to finish a task.

A multilingual launch creates an ongoing editorial commitment. When a price, service or contact method changes, decide who identifies the affected versions, who approves the wording and when those changes go live. Keep a short record of the pages waiting for review.

Automated translation can help produce a draft, but someone still needs to verify meaning, terminology and the business commitments being made. Give reviewers access to the actual page, including buttons and forms. Reading a document alone will not reveal a clipped label, the wrong destination or an untranslated confirmation screen.

Compare how different systems support translation workflows in the guide to choosing a CMS.

Before development starts, bring the audience, page map, content responsibilities and technical decisions into one short brief. It should let you compare proposals on what will actually be delivered, including review time and the work needed after publication.

At handover, test representative tasks in every language on desktop and mobile. Open a service page directly, switch to its equivalent, submit a form and check the resulting message. Verify an older link and a missing page as well. This gives the team concrete acceptance criteria and a repeatable check for future changes.