Auto-Redirect by Language or Location: Why Avoid It

Automatic redirects by IP address or browser language are best avoided, because the signal is often wrong for the person and because they can stop Google from reaching some of your language versions. Google advises linking to the other versions and letting users choose, with separate URLs and hreflang for search engines. A suggestion banner plus a remembered choice gives most of the convenience without the risk.

Why do sites auto-redirect in the first place?

The goal is reasonable: send a French visitor to the French site. Two signals are usually used.

• IP geolocation, which maps an address to a country.
• The Accept-Language header, which the browser sends with each request. MDN describes it as telling the server which languages and locales the client prefers, generally matching the browser's UI language.

A typical rule looks like this:

# Anti-pattern: forced redirect from the home page on first request
if ($http_accept_language ~* "^fr") {
    return 302 /fr/;
}

The convenience is real when the guess is right. The problems come from when it is wrong and from who cannot see past it.

Why are these signals unreliable?

MDN is explicit that Accept-Language is a hint, not an authoritative signal: a server should use it only when it cannot determine the language another way, and should never override an explicit user selection. Reasons it can mislead:

• It may not reflect the user's real preference, for example when traveling or using a shared or borrowed device.
• It may be intentionally incomplete. For privacy, some browsers send only one language (MDN notes Safari always lists one, and Chrome's incognito mode does too).
• Users may want a page in a language other than their interface language.

IP location has similar limits. Travelers, VPN users, corporate networks and mobile carriers can all appear in a different country or language zone from where the person actually belongs. A country also is not a language: Switzerland, Belgium, Canada and India each have several. (See language and region codes.)

What does Google say about locale-adaptive pages?

Google's guidance on locale-adaptive pages says that if you serve different content based on a visitor's perceived country or language, Google "might not crawl, index, or rank all your content for different locales." Its explanation is that Googlebot's default IP addresses appear to be US-based and that its requests do not set an Accept-Language header.

Google flags the better approach as important: use separate locale URL configurations, annotated with rel="alternate" hreflang. It also notes that Googlebot crawls from some non-US IP addresses too, and that you should treat it like any other visitor from that country: if you block US users but allow Australian ones, block Googlebot when it appears to come from the US and allow it when it appears to come from Australia. It adds that Googlebot uses the same user agent string in all configurations and that you can verify geo-distributed crawls with reverse DNS.

Google's multi-regional guidance goes further: it advises against automatically redirecting users to another language version based on assumed language, since that can stop both users and search engines from reaching all versions. Instead, link to the other versions so users can choose.

Practical consequences:

1. A US-looking crawler with no Accept-Language may always land on one version. If a redirect sends all such requests to the English site, the other versions are never fetched via that path. They might still be discovered through direct links and sitemaps, but a forced redirect on entry points removes a main route.
2. Redirect chains waste crawl effort and confuse users.
3. Do not treat Googlebot differently to dodge the issue. Serving crawlers different content from users is how cloaking is defined in Google's spam policies ("presenting different content to users and search engines"). Fix the design instead of special-casing bots.

What do users experience?

• A visitor sent to the wrong language may not know how to get back, especially if the switcher is also in the wrong language.
• Shared links break. A friend who sends you a link to the English page may find you redirected elsewhere.
• Browser back-button loops occur when each visit redirects again.
• Return visitors who chose a language are forced back to the guess unless their choice is remembered.

The language switcher UX best practices article covers the interface side.

What are better patterns?

1. Separate URL per language, always reachable

Every language version lives at its own stable URL and returns that content to everyone, regardless of IP or headers.

2. Cross-link versions with hreflang

Annotate each version with all alternates, including itself, as covered in the hreflang guide:

<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

3. Use x-default for the entry or chooser page

Google describes x-default as the fallback for users whose language settings match none of your versions, and recommends it for language selector pages or auto-redirecting home pages.

4. Suggest, do not force

If you detect a likely mismatch, show a small dismissible banner on the current page:

This page is also available in Français. [Switch] [Stay here]

The page content does not change and stays crawlable. We did not find banners named in Google's pages; this is common practice and our recommendation.

5. Remember the explicit choice

When the visitor chooses a language, store it (a first-party cookie or local storage is typical) and use it only to decide whether to show the suggestion again, or to pick where a bare home-page visit lands. Keep every language URL directly accessible even when a preference is stored. Check your consent obligations for the storage you use.

6. If you must redirect, keep it narrow

If your business needs a redirect, limit it to the bare root URL, make it a temporary (302) redirect, never apply it to deep links, honor a stored explicit choice first, and make sure every language URL is also linked in HTML so crawlers can reach it. This is our judgment, not Google guidance, and the safer option remains no forced redirect.

How do you test your setup?

• Request each language URL with curl using different Accept-Language values and from a clean session: each should return its own content with a 200.
• Check Search Console's URL Inspection for the live fetch of each version.
• Confirm that no language URL redirects based on location.
• Confirm the sitemap lists every version. See the multilingual XML sitemaps article for the markup.

Key takeaways

• Google advises against automatic redirects by assumed language; link to versions and let users choose.
• Googlebot appears to come from US IPs with no Accept-Language, so locale-adaptive serving can hide content; Google recommends separate locale URLs with hreflang.
• Accept-Language and IP are hints, not facts about the person.
• Prefer a dismissible suggestion banner and a remembered explicit choice, with every version always reachable.
• Use x-default for a language chooser or fallback page.

Sources

• Locale-adaptive pages – crawling from US IPs, no Accept-Language, separate locale URLs, geo-distributed crawling
• Managing multi-regional and multilingual sites – advice against automatic redirection by assumed language
• Tell Google about localized versions of your page – hreflang requirements and x-default
• Spam policies for Google web search – definition of cloaking
• MDN: Accept-Language header – what the header is and why it is only a hint