The automatic-redirect trap.
Forcing the user to a language version based on their location or browser language is a pattern that imprisons both the user and the search engine’s crawler.
The idea looks well-intentioned: if the user comes from Germany, let us send them to the German version and spare them the trouble. In practice this is the most frequent and most damaging error multilingual sites make.
Google warns against this behaviour explicitly, and the reason is technical: its crawler comes from a specific location, and if every request is redirected there, it can never see the other language versions — and therefore cannot index them.
Why it harms the user too
The assumption is this: location shows language preference. The assumption is wrong. A Turk in Germany, an Englishman in Istanbul, a user on a trip, or a professional who runs their work in English — all can want a language different from their location.
The browser language is a slightly better signal, but it is not certain either: many users run their device in English and want to read content in their native language.
The most maddening part of forced redirection is that it cannot be undone: the user picks another language from the switcher, the page reloads, and the redirect throws them back to the same place. The user is stuck on the site.
Location does not show language preference — a Turk in Germany, an Englishman in Istanbul.
The right approach: suggest, do not force
Ignoring the signals entirely is not required either. The correct behaviour is offering the user a suggestion and leaving the decision to them.
- Show the page in the language they asked for — whichever address they opened, let them stay in that language.
- Show a banner — a dismissible suggestion like “This page is also available in German”.
- Remember the preference — once the user has chosen, do not ask again.
- Do not redirect the crawler — the search engine’s crawler must be able to see every version.
- Keep the language switcher always visible — even if the suggestion is declined, the path stays open.
The third item carries an implementation detail: remembering the preference usually requires a cookie or local storage. On this site the privacy text says no cookies are used and the suite measures it — so preference memory was never built here, and there is no banner either. Whichever address the user opened, they stay there.
The decision is plain but consistent: when the privacy claim and interface convenience collide, the claim wins. All three languages are always visible in the header, and on every page they go to that page’s counterpart.
Server side or client side
If redirection is to be done, where it is done matters too. A server-side redirect affects the crawler directly and breaks the indexing. A client-side redirect usually does not affect the crawlers but still breaks the user experience.
Neither is recommended. But if forced to, the client side is less harmful — and it must leave an exit: once the user has chosen another language, the redirect must go inactive.
Legitimate exceptions
The rule is harsh but not absolute; there are a few cases where redirection is defensible, and the distinguishing criterion is always the same: is the user’s decision preserved?
- From the root address to a language — reasonable if the home page picks a language and the choice is remembered.
- Legal obligation — in some markets the content must be localized by law.
- Currency and stock — in genuinely separate operations the user should be shown the right store.
- If the user has chosen once — remembering their own choice is not redirection but respect.
- The crawler must NEVER be redirected — whatever the case.
The fifth item has no exception: the search engine’s crawler must be able to see every language version. Logic applied to the user must not be applied to the crawler, and that distinction must not be made server-side by user agent — because serving different content by agent is a separate violation.
The correct technical solution: do the redirect on the client side and only on an explicit user signal. If the crawler runs no JavaScript, no redirect happens and every version stays reachable.
On this site there is no redirection at all. The three languages are always visible in the header, every page links to its own counterpart, and whichever address the user opened, they stay there. The decision is also consistent with the privacy claim — remembering a preference would need a cookie or local storage, and neither is used.
Banner design
If a suggestion is offered instead of a redirect, how that suggestion is shown is a design decision too. A badly designed suggestion banner can be as bothersome as a redirect.
- It must not push into the content — entering the page flow produces layout shift.
- It must be dismissible — and the dismissal remembered.
- It must be written in the target language — a German suggestion must be written in German so the target user can read it.
- It must be shown once — a banner reappearing on every page is worse than a redirect.
- It must be small — it must not overpower the content.
The third item looks backwards at first glance but is logical: the banner’s target is a user who speaks that language. Writing the banner in the source language means exactly the person meant to be reached cannot read it.
The fourth item produces an implementation problem: the fact of “shown once” has to be held somewhere, and that usually means a cookie or local storage. On a site with a privacy claim, that produces a contradiction.
On this site the contradiction was resolved in the claim’s favour: the banner was never built, there is no preference memory, no cookies. The three languages are always visible in the header, and whichever address the user opened, they stay there. Plain, consistent and measurable.
A principle to close: offering the user a choice instead of deciding on their behalf gives the better result in nearly every interface decision. Language choice is the clearest example, because when guessed wrong the user becomes unable to use the site. A suggestion is always legitimate; force almost never is.
A diagnostic note to finish: the fastest way to tell whether an existing site redirects is opening it with a different language setting or from a different location. If the address changes, there is a redirect.
The second check is done from the search console: if one of the language versions never enters the index, the crawler never reaching that version is among the likely causes.