Does ChatGPT Know Your Site Has a Spanish Version? Multilingual AI Visibility, Explained

Most GEO and AEO advice is written, tested, and published in English, about English pages. If you run a site in five languages, almost none of that advice tells you whether your Spanish, Portuguese, or French pages are actually reachable and citable the same way your English ones are. They often aren't, and the reasons are mostly structural, not linguistic.

The crawl has to find the page before it can cite it

An AI crawler or retrieval step can only cite a translated page if it can reach that page as its own URL, with its own content, in the first place. Three common setups quietly block that:

JavaScript-only language switching. If visiting /es/pricing actually serves the English page and swaps text client-side after the page loads, a crawler that doesn't execute JavaScript (many AI crawlers don't, or do so inconsistently) sees English content at a Spanish URL — or sees nothing translated at all.

Locale auto-redirect based on the visitor's headers. A server that redirects every visitor to a "detected" locale based on Accept-Language or geolocation will do the same thing to a crawler, which usually sends generic or English-leaning headers. The result: your non-English URLs rarely get requested directly, because something upstream keeps bouncing the crawler back to English.

No explicit URL per locale. If a language switcher changes a cookie or app state instead of changing the URL, there's no separate translated page for anything to crawl, index, or cite — there's one URL with several possible states, and crawlers don't carry cookies between requests the way a logged-in browser does.

The fix for all three is the same: every locale gets its own crawlable, directly-linkable URL that returns that locale's content on a plain, unauthenticated request — no required JavaScript, no forced redirect, no cookie dependency.

hreflang: not an AI-crawler requirement, but still worth having

hreflang annotations tell search engines which URL to show for which language and region, so they don't need to guess or treat /es/pricing and /pricing as duplicate content. There's no public confirmation that AI answer engines read hreflang directly the way Google Search does — treat any claim that it does as Unverified. What's well established is that hreflang prevents search engines from mis-ranking or canonicalizing away your translated pages, and a page that search engines rank and send traffic to is generally a page more likely to end up in whatever content an AI system was trained or retrieved on. Getting hreflang right is good hygiene with a known SEO benefit; treat any AI-citation benefit as a plausible side effect, not a guarantee.

Translated, but thin, is still a problem

A page that exists in Spanish but is machine-translated boilerplate, or missing the FAQ/schema/structured content the English version has, gives an AI system less to work with in that language — even if the crawl and indexing are both fine. If your English page answers a question clearly under a real heading and your Spanish page doesn't carry the same structure, don't expect the same citation behavior in Spanish. Visibility and translation completeness are two different problems, and fixing the first doesn't fix the second.

What to actually check, in order

1. Does each locale's key page resolve at its own URL with no required redirect or client-side swap, on a plain fetch (no cookies, no JS)?
2. Does that URL return real, locale-specific content — not English content with a different URL, and not thin machine-translated filler?
3. Is hreflang set correctly, pointing every locale version at every other locale version, including itself?
4. Does the translated page carry the same structured data (schema, headings, FAQ) as the English version, in that language — not a stripped-down copy?

Most multilingual AI-visibility problems are steps 1 and 2: the crawl never reaches a real, direct, language-specific page at all. Fix reachability first; polish comes after.