A multilingual website: five mistakes that eat your visibility

To a client a multilingual site feels like a translation project: take the existing site and put the copy into another language. Technically it is a structural project, and the faults that arise there are invisible to the eye — they show up six months later in Search Console. Here are the five most common.

1. The languages live on one address

If the language is switched by a script and the address stays the same, then as far as a search engine is concerned there is one page in one language. The second version is not indexed, because it has no address of its own to point at. Every language needs its own address — a separate folder (`/en/...`), a separate subdomain or a separate domain.

2. hreflang is missing or points wrongly

hreflang is the marker that tells Google: these pages are the same content in different languages, show each person the right one. Without it the wrong language can appear in search, or the versions can compete with each other. The most common fault is not a missing hreflang but one pointing at addresses that do not exist — a page not translated into that language, for instance.

Another detail often skipped: every version has to point at itself as well, and the references have to be mutual. A one-sided hreflang is simply disregarded.

3. The addresses are left untranslated

If a local-language page lives at `/services/web-development`, one easy opportunity is lost: local words in the address. They are not the strongest factor, but they are free and they count in local search. The sensible solution is translated paths — one per language, in that language.

But here is a catch that gets missed very often. Once the address is translated, the language switcher has to know each language’s address too. If it merely swaps the language prefix and leaves the rest of the address as it was, it leads to a page that does not exist and returns 404. The user sees an error, while hreflang may be perfectly correct at the same time — so the fault appears in no report, yet for a human being the site is broken.

4. Machine translation without editing

A translation engine copes with meaning but not with how people actually search. Search terms are not translations: a person in one country searches with different words than a neighbour, and the right word comes from data, not from translation. Tone matters as well — a machine-translated page is readable, but it does not persuade.

A practical compromise: start from machine translation and have a person go over the headings, the opening paragraphs and every place where the keywords sit. A full rewrite for every language is not always in the budget; editing the headings always is.

5. Languages nobody maintains

Five languages with empty content are worse than two with solid content. Every language is an upkeep cost: a new article has to be translated, a new service too, and when that does not happen, part of the site visibly ages. Start with the languages for which there is both a market and a person responsible for the content.

What to check before launch

• Every language has its own address and it opens directly, without a redirect.
• hreflang is present in every version, points at every language and at itself.
• The language switcher leads to the same page in the other language, not to the home page and not to a 404.
• There is no automatic language detection, or it does not redirect a search crawler.
• Titles and metadata differ in every language rather than being engine output.

The third point is the most tiresome of them: it shows up in no standard check, because everything in the `<head>` may be in order. The only reliable way is to click through every language-switch link — or have a script walk them.

How a multilingual structure is built here — translated addresses, hreflang and content management per language — is set out on the website development page. If the site is already multilingual and you want to know what is broken in it now, a technical audit answers that.