ShopifyHydrogenHeadlessLocale DetectionSEOAI Crawlersi18n

Stop Auto-Redirecting Visitors by Language — Hydrogen's Right Way

August 11, 2026 ·11 min read

Your store ships in five languages. A visitor from Italy lands on your English homepage. Should your server quietly bounce them to /it/? It feels helpful. It’s actually one of the worst things you can do to your SEO. Here’s why Shopify, Google, and 2026 crawler testing all agree — and what to do instead.

The Question Every Multilingual Store Asks

When a Hydrogen storefront supports multiple languages (EN / DE / FR / IT / ES), this comes up immediately:

Can we detect the visitor’s language and automatically redirect them to the right version?

The intuitive answer is “sure” — read the browser’s Accept-Language header or IP geolocation, then fire a server-side 302 to the matching language path.

But after digging through Shopify’s official documentation, Google Search Central guidelines, and 2026 crawler behavior research, three independent sources converge on the same conclusion: auto-redirect is bad practice. A suggestion banner is the best practice.

What Is a “Locale-Adaptive” Page?

This is the concept that explains everything. Google defines it in its Search Central documentation:

Locale-adaptive pages change their content to reflect the user’s language or perceived geographic location.

In plain terms: if your server returns different content — or redirects to a different URL — for the same URL based on the visitor’s language or location, your pages are locale-adaptive.

For example:

Visitor A (browser language de) hits / → server returns 302 to /de/
Visitor B (browser language it) hits / → server returns 302 to /it/
Visitor C (no Accept-Language) hits / → gets the English homepage

That’s locale-adaptive behavior. The problem: Google’s crawlers and AI crawlers aren’t normal visitors.

How Googlebot Actually Crawls

Google states three facts officially:

Googlebot doesn’t send an Accept-Language header by default — so your server sees a request that “looks like” a US English user.
Googlebot’s default IPs appear US-based — so IP geolocation detection also thinks the crawler is American.
Google may not fully index all your language versions — because it can only crawl from a US-IP, language-neutral perspective.

Google did add geo-distributed crawling from non-US IPs and language-aware crawling with Accept-Language starting in 2015 — but that’s selectively enabled after automatic detection. You cannot rely on it to guarantee every language version is discovered and indexed.

What Google Recommends Instead

We continue to support and recommend using separate URLs as they are still the best way for users to interact and share your content, and also to maximize indexing and better ranking of all variants of your content.

— Google Search Central Blog, 2015

In other words: separate URLs + hreflang annotations — not one URL that adapts itself to whoever shows up.

Shopify’s Official Position

Shopify’s Hydrogen Localization Detection docs spell it out in a Caution box. This applies whether or not you use Shopify Markets:

	Official wording	What it means
✅ Good	“Show a banner asking the user if they want to switch country”	Ask the user with a banner
❌ Bad	“The user gets automatically redirected”	Automatic redirect

An important boundary: Shopify isn’t saying “don’t detect the locale.” Detection is explicitly fine for improving user experience. What’s bad is acting on the detection with an automatic redirect.

Shopify lists three technical drawbacks:

Other drawbacks of this approach are that page caching ignores locale cookies, headers and URL search params. SEO bots tend to origin from the US, don’t have cookies, and will not change their accept-language headers.

Translated:

Edge caches ignore locale cookies and headers. Hydrogen runs on Oxygen’s edge nodes, and the edge caches responses. Accept-Language and locale cookies aren’t part of the cache key — the first German visitor’s 302 gets cached, and every subsequent visitor (including Americans) gets redirected to German.
SEO bots originate from the US. Crawler IP geolocates to the US → IP detection says “America” → content skews English.
Bots have no cookies. Even if you persist language choice in a cookie, crawlers arrive cookie-less, so your redirect logic behaves unpredictably for them.

What Shopify’s Own Demo Store Does

Look at utils.ts in Shopify’s official Hydrogen Demo Store. The getLocaleFromRequest function extracts the locale purely from the URL path — it never reads Accept-Language to redirect:

export function getLocaleFromRequest(request: Request): I18nLocale {
  const url = new URL(request.url);
  const firstPathPart = '/' + url.pathname.substring(1).split('/')[0].toLowerCase();
  return countries[firstPathPart]
    ? { ...countries[firstPathPart], pathPrefix: firstPathPart }
    : { ...countries['default'], pathPrefix: '' };
}

Shopify’s own reference implementation doesn’t auto-switch languages.

The 2026 Crawler Data

MERJ’s 2026 research tested the Accept-Language behavior of every major search engine and AI crawler (published March 2026, data from February 2026). This table is the decisive evidence:

Crawler	Accept-Language behavior
Googlebot (also Gemini)	Not sent. `en-US` appears when following JS redirects during rendering
Bingbot (also Copilot)	Not sent
GPTBot (OpenAI)	Not sent
OAI-SearchBot (OpenAI)	Not sent
ClaudeBot (Anthropic)	Not sent
PerplexityBot	Not sent
ChatGPT-User	Sometimes `en-US,en;q=0.9`, sometimes absent
Applebot	Guesses from ccTLD (.com → absent, .de → `de-DE`)
Baiduspider	Absent or `zh-CN,zh-TW`
DuckDuckBot	Absent or `en-US,en;q=0.8`

The Most Dangerous Edge Case: Rendering

Googlebot’s initial HTML fetch really does skip Accept-Language. But during the rendering phase, when JavaScript on the page triggers a redirect, follow-up requests inherit the browser instance’s default Accept-Language: en-US (observed in MERJ’s testing).

If your redirect logic lives in client-side JS (say, a React Router client loader), the chain looks like this:

1. Googlebot fetches / (HTML, no Accept-Language) → English page (correct)
2. Googlebot renders the JS on / → JS reads navigator.language
3. Client-side language redirect logic fires → jump to /en/
4. Indexing signals get muddy: the initial HTML was English, but rendering bounced away

This is why even if your server doesn’t redirect, client-side language detection can still interfere with crawler indexing.

AI Search Makes This Worse

GPT, Claude, Perplexity, and Gemini all crawl the web for retrieval-augmented generation. Their Accept-Language behavior is even less predictable:

Some never send it (safe)
Some send en-US,en;q=0.9 (a default value, not user intent)
Virtually no AI crawler adjusts Accept-Language based on the user’s prompt language

When present, Accept-Language is typically default en-US,en;q=0.9. Therefore, Accept-Language based redirects for bots do not reliably improve user experience, introduce content accessibility risks, and can reduce indexing quality for both search engines and LLM retrieval systems.

— MERJ, 2026

The Full Defect List for Auto-Redirects

If you still want to auto-redirect (by Accept-Language or IP geolocation), you must handle all of these:

#	Problem	Cause	Fix
1	Edge cache locale pollution	Oxygen caches 302 responses; the first visitor’s language “pollutes” everyone after	Add `Vary: Accept-Language` or disable caching on the route
2	User choice not remembered	Pure `Accept-Language` has no memory; users who switch back get redirected again	Add a locale cookie override layer
3	Deep links don’t trigger	Detection only works on `/`; `/about` never redirects	Move logic to the global routing layer (more complexity)
4	The 302 vs 301 dilemma	301 pushes the root URL’s canonical to one language version; 302 adds a round trip	Use 302 only
5	Googlebot rendering interference	The rendering browser instance carries `en-US`, which can fire client redirects	Exclude bot UAs (unreliable)
6	AI crawler language bias	AI crawlers send default `en-US` → get bounced to English → non-English content ignored	Maintain a bot allowlist (always outdated)
7	Extra network round trip	`/` → 302 → `/de/` costs one extra hop	Cannot be eliminated

The bottom line: problems 1–6 all have “fixes,” but each fix adds system complexity and maintenance cost. The banner approach eliminates all seven problems at once.

Shopify-recommended, Google-approved, and the simplest thing to build.

How It Works

Visitor in Italy hits / (English homepage)
     ↓
Server renders the English page normally (no redirect)
     ↓
Server also computes a "suggested locale" (from Accept-Language or oxygen-buyer-country)
     ↓
Suggested locale is passed to the frontend
     ↓
Frontend checks:
  ├─ Current locale ≠ suggested locale? (e.g., English now, Italian suggested)
  ├─ No "dismissed" cookie?
  └─ Both true → show the banner
     ↓
Banner: "This site is also available in Italiano"
  ├─ [Switch to Italiano] → navigate to /it/ + set cookie
  └─ [Stay in English]    → dismiss banner + set cookie
     ↓
Next visit:
  └─ Cookie is read first → no banner

Side by Side

Dimension	Auto-redirect	Suggestion banner
Shopify official	❌ Bad example	✅ Good example
Google SEO	Locale-adaptive risk	Zero risk
AI crawler indexing	Bias risk	Zero risk
Edge caching	Needs `Vary` or disaster	No impact
User experience	Forced guess, irreversible	User choice, reversible
Implementation	High (solve 7 problems one by one)	Low (one component + one cookie)
Network performance	Extra round trip	Zero extra requests

Implementation Notes for Hydrogen / React Router

Infer the suggestion server-side. In your root loader, read accept-language or oxygen-buyer-country (Oxygen provides IP→country), map it to a supported locale, and pass it to the client. Do not redirect.
A banner component. A <LocaleSuggestionBanner> that checks whether the current locale differs from the suggestion and whether a “dismissed” cookie exists.
Persist with cookies. Whether the user clicks “switch” or “dismiss,” write a cookie so the banner never reappears.
Keep a manual switcher. Banner or not, always provide a locale switcher — users should be able to change language on their own terms.

If your storefront also handles currency and market routing, our guide to selling globally from one Shopify store covers how Markets organizes language, currency, and domains — the banner sits on top of that structure.

Does this still apply if we don't use Shopify Markets?

Yes. Shopify’s “Good Example / Bad Example” guidance lives under the Markets section, but the underlying reasons (caching, cookies, crawler behavior) are HTTP- and SEO-level concerns that have nothing to do with whether you use Markets.

Don't big companies like Amazon and IKEA auto-redirect?

They do. But they run dedicated SEO teams to maintain crawler allowlists, infrastructure to handle Vary headers and edge caching, and budgets for continuous crawler-behavior monitoring. For a headless storefront project, the banner’s return on investment is far higher than auto-redirecting.

Won't it be a bad experience if an Italian visitor lands on English?

A banner can be very elegant — one line at the top of the page, in the visitor’s language, one tap to switch. That’s better than “I got teleported somewhere and don’t know why,” and it keeps the choice with the user. In our headless projects, banner-driven switches perform no worse than auto-redirects — users who want their language were going to switch anyway, and users who don’t are spared a forced jump.

Which signal is better for inferring the suggestion: oxygen-buyer-country or accept-language?

Use both, layered:

oxygen-buyer-country: IP → country (high accuracy, but the user may be on a VPN or traveling)
accept-language: browser language preference (moderate accuracy, but reflects the user’s own choice)

Our recommended strategy: prefer accept-language (the user’s explicit preference is more reliable), fall back to oxygen-buyer-country.

Building a multilingual Hydrogen storefront is one of the biggest reasons teams go headless in the first place — and once you do, remember that storefront event tracking needs to be rebuilt from scratch.

Sources

Fact-checked 2026-08-11 against Shopify official documentation, Google Search Central, and MERJ’s 2026 crawler testing. Crawler behavior data is current as of February 2026 (MERJ tests) — search engine and AI crawler behavior evolves, so treat official documentation as the final authority.

Information Verification

Verified: 2026-08-11