Multi-Language Sites and the Agent Locale Problem
An AI agent based in a US data centre visits a European retailer's website. The server detects a US IP address and redirects to the English-language US store. The product the agent was looking for is only available in the German store. The agent never sees it.
This is the locale problem. Multi-language, multi-region sites make assumptions about visitors based on IP address, browser language headers, or cookies. Those assumptions are often wrong for AI agents, and the consequences range from seeing the wrong prices to missing entire product catalogues.
IP-Based Redirects Break Agent Access
Many international sites use IP geolocation to redirect visitors. A request from a German IP goes to example.de. A request from the US goes to example.com. The redirect happens at the server level before any page content loads.
AI agents run from data centre IPs. Those IPs are typically located in the US (Virginia, Oregon) or Western Europe (Ireland, Frankfurt). The server picks a locale based on the data centre location, not the end user's location. An agent working on behalf of a Japanese user gets redirected to the US English store because the agent's server is in Oregon.
Some sites redirect aggressively without offering a way to override. The redirect is a 301 or 302, and hitting the German URL from a US IP always bounces to the US site. The agent literally cannot access the locale it needs.
The Accept-Language Header
Browsers send an Accept-Language header with every request: Accept-Language: de-DE,de;q=0.9,en;q=0.8. This tells the server the user prefers German. Well-built sites respect this header over IP geolocation.
Most AI agents don't set this header, or they set it to en-US by default. The agent gets the English version of the site regardless of what the end user wanted. Agents that do set the header correctly face a different problem: some sites ignore the header entirely and rely only on IP or cookies.
The fix on the agent side is straightforward: set the right Accept-Language header. The fix on the site side matters more: actually respect it.
Hreflang Tags Are the Proper Solution
The hreflang attribute tells search engines (and agents) that alternative language versions of a page exist. A product page at example.com/shoes/running might include:
<link rel="alternate" hreflang="de" href="https://example.de/schuhe/laufschuhe" />
<link rel="alternate" hreflang="fr" href="https://example.fr/chaussures/course" />
<link rel="alternate" hreflang="en" href="https://example.com/shoes/running" />
<link rel="alternate" hreflang="x-default" href="https://example.com/shoes/running" />
An agent reading these tags knows exactly which URLs correspond to which language versions. It can request the German version directly, bypassing geolocation redirects. This is how hreflang tags support international agent routing in practice.
The x-default value is especially useful. It tells agents which URL to use when no specific locale matches. Without it, agents may not know which version is the canonical default.
URL Structure Signals
Three common patterns for multi-language URLs:
Subdirectories (example.com/de/, example.com/fr/): the most agent-friendly. A single domain with locale prefixes means the agent can construct URLs for different languages by swapping the prefix. Predictable and easy to parse.
Subdomains (de.example.com, fr.example.com): also works well. Each subdomain is its own locale. Agents can discover the pattern from hreflang tags and switch between subdomains.
Separate domains (example.de, example.fr): hardest for agents. There's no URL pattern to predict. The agent relies entirely on hreflang tags or site configuration to discover other locales.
Language Switcher Pitfalls
Most multi-language sites include a language switcher, a dropdown or set of flag icons that lets users change locale. These have the same problems for agents that dropdown menus do. The switcher is often hidden behind a click or hover. The options may be loaded dynamically. Flag icons without text labels don't tell agents which language each option represents.
The best language switchers use plain <a> elements with descriptive text (<a href="/de/">Deutsch</a>), visible in the DOM without interaction. Each link points to the equivalent page in the target language, not to a generic language-change endpoint that uses a cookie.
Content Parity Problems
Some sites don't have the same content across all languages. A product might exist in the German catalogue but not the English one. A blog post might be written in French with no English translation. An agent browsing the English version of the site sees a smaller catalogue or fewer articles than actually exist.
There's no clean technical fix for this. But being transparent about it helps. A message like "This product is available in our German store" with a direct link gives the agent a path forward. Returning a 404 for a product that does exist in another locale is the worst outcome: the agent assumes the product doesn't exist at all.
Build your multi-language site so that agents can find and access every locale version. Use hreflang tags on every page. Prefer subdirectory-based URL structures. Respect the Accept-Language header. Don't redirect based on IP without offering an override. These aren't just agent-friendly practices; they're the same things that help your international SEO.