← All articles
5 min readBy Onravetoni

Planning a multilingual website: structure, translations and enquiries per language

A second language means more than duplicated copy. Each language version needs its own address, matching metadata, maintained content and an enquiry path someone can handle in that language. Plan these points before translation starts, or you end up with pages Google can find but visitors cannot act on.

Decide what content each language needs

Start with a matrix: rows are pages and features, columns are languages. For each cell, record whether content is translated, adapted for the market or deliberately not offered. A service you do not provide in a market should not appear there as a page.

Separate translation from adaptation. Prices, legal pages, availability, payment methods and examples often depend on the market. German business websites, for example, need an Impressum; a literally translated English page does not cover such requirements automatically.

  • Page or feature and responsible person.
  • Status per language: translated, adapted or not offered.
  • Market-specific details: prices, currency, legal pages, availability.
  • Sign-off by someone fluent in the language.
  • Date of the last update for each language version.

Give every language its own URL

Use a stable address for each language version, such as the subdirectories /de/, /en/ and /ua/. If the language changes only through a cookie or script on the same URL, Google cannot reliably index the versions separately. Do not redirect visitors automatically based on their assumed language; provide a visible language switcher instead.

Connect equivalent pages with reciprocal hreflang annotations and add x-default for the default version. Use correct language codes: Ukrainian is uk, not ua, because ua is the country code. The language switcher should lead to the equivalent page, not the homepage.

  • Each language version returns status 200 with a self-referencing canonical.
  • hreflang annotations are reciprocal and include the page itself.
  • Titles and descriptions are written in the page language.
  • The sitemap lists every language version.
  • The language switcher leads to the equivalent page.

Localise the enquiry path

A German form with an English error message or English confirmation email looks unfinished. Check field labels, error messages, success message, confirmation email and privacy notice in every language. Store the enquiry language in your CRM so the reply comes in the same language.

Decide who handles enquiries in each language and within what timeframe. If a language has limited support, say so on the contact page rather than promising a reply nobody can give.

Plan maintenance after launch

Translations go stale as soon as prices, services or legal pages change. Agree that a change is only complete when every affected language version is updated or deliberately deferred. A short note in the change log is enough.

Measure visibility and enquiries separately per language. A market without impressions usually needs better-matched content; a market with clicks but no enquiries needs a review of the offer and form. Example: the German service page gets impressions but few clicks. First check whether its title and description match German search queries.

Frequently asked questions

Is machine translation good enough?
It can help as a draft. Before publishing, someone fluent should review terminology, prices, legal text and tone.
Do I need a separate domain for each language?
Not necessarily. Subdirectories such as /de/ and /en/ on one domain are easy to maintain. What matters is a stable URL per language, correct hreflang and maintained content.

Sources

Planning a website in two or more languages? Send the page list and target markets. We can discuss structure, translation workflow and enquiry handling.

Discuss a multilingual website