Multilingual websites: UX and SEO best practices for international businesses

Translating a website is the easy part and the part everyone budgets for. The architecture underneath it is the part that decides whether the other languages ever compete.

You can usually identify a retrofitted multilingual site in about fifteen seconds. The non-English versions have English URLs, the metadata is translated English keywords, the structure matches English exactly, and the form validation reverts to English the moment something goes wrong.

It is readable. It does not compete. Those are different standards.

Decide the URL architecture first, because it is the hardest to change

There are three viable patterns and one common mistake.

• Subdirectories (example.com/fr/) — usually the right default. Authority is consolidated on one domain, and it is the simplest to operate.
• Subdomains (fr.example.com) — reasonable when infrastructure or teams are genuinely separate.
• Country domains (example.fr) — strongest local signal, highest cost, and each one starts from nothing.
• The mistake: serving different languages at the same URL based on browser or IP. Search engines then see one version, users get guessed at, and nobody can link to a specific language.

Localise the slugs too

If your French pages live at /fr/services/website-development, you have translated the content and left the address in English.

The slug should be the phrase the market actually uses — /fr/services/creation-site-web. It reads correctly, it matches search behaviour, and it signals the page was built for that audience rather than adapted.

For languages with a non-Latin script there is a legitimate choice between native-script slugs and stable Latin ones. Either works; what matters is that the decision is deliberate and consistent.

hreflang, and the error nearly everyone makes

hreflang tells search engines which version of a page to show which audience. It is not difficult, and it is frequently implemented wrongly in one specific way.

• Every page must point at its actual equivalent — not at the homepage of each language. Pointing all alternates at the homepage is the most common error and it defeats the purpose entirely.
• The tags must be reciprocal. If English points at French, French must point back at English.
• Include a self-referencing hreflang on each page.
• Add x-default for the fallback version.
• Use correct codes: fr for French, fr-CA only if you genuinely have a distinct Canadian version.

A useful way to keep this honest is to generate the tags from a single route map rather than writing them per page, so a missing translation becomes a build error instead of a silent lie.

Localise rather than translate

A literal translation of English marketing copy produces text that is grammatically correct and subtly foreign. It reads as imported, which undermines the credibility the site exists to build.

Beyond tone, the substantive differences: how services are named in that market, what buyers expect to see, what proof is persuasive, what a call to action sounds like when it is not a translated imperative.

The test is whether someone can arrive from their own search engine, in their own language, and never notice that English exists.

Do keyword research per language, not once

Translated keywords are the most reliable way to build a site that ranks for nothing.

People search differently in different languages: different phrasings, different levels of formality, different use of English loanwords within an otherwise non-English query. Research each market on its own terms, then write the metadata from that research.

Right-to-left is structure, not styling

If you support Hebrew or Arabic, RTL is an architectural decision made at the start, not a stylesheet appended at the end.

• Use logical CSS properties throughout — margin-inline-start rather than margin-left. Then direction is a property of the document rather than a second set of rules.
• Set dir="rtl" and the correct lang on the document.
• Mirror what carries direction: arrows, progress, breadcrumb separators, back and forward.
• Do not mirror logos, photographs, product images or device frames. A phone is not reversed by a language.
• Check typography separately. Hebrew and Arabic have different vertical rhythm needs; the line-height that suits Latin text often reads tight.
• Test forms specifically — input alignment, validation messages, and the language those messages appear in.

The language switcher

Small component, disproportionate effect on whether the other languages get used.

• Switch to the equivalent page, not to the homepage. Sending someone back to the start is the fastest way to teach them not to use the switcher.
• Label languages in their own language: Français, עברית, not flags. Flags are countries, not languages, and get it wrong for most of the world.
• Make it findable without being prominent.
• Remember the choice, but never override an explicit one.

What often gets forgotten

Plan for maintenance, because that is where it decays

Multilingual sites fail slowly. English gets a new page; the other languages do not. Six months later English has twenty pages the others lack, hreflang points at pages that do not exist, and the French site is quietly a subset.

Decide up front: does every page exist in every language, or are some language-specific? Both are valid. What is not valid is having no answer, because the default is drift.

In short

Multilingual work is mostly an architecture problem wearing a language problem's clothes. Get the URL structure, the hreflang generation and the RTL foundations right at the start, and translation becomes the straightforward part.

Get them wrong and no amount of good translation compensates. Our website development and SEO pages cover how we handle this.