GEO for Multilingual Sites: Getting Cited in Every Language
Almost every GEO guide assumes an English-only site. Mine doesn't — this one runs in 13 languages — and three things broke or underperformed the moment I looked past English: hreflang/x-default correctness, llms.txt scope, and schema consistency across locales. Here's what actually changes and the audit prompt I use to check a multilingual site in one pass.
Every Wednesday. 28,400+ operators. Zero fluff.
✓ Check your inbox — click the confirmation link to complete sign-up.
✓ You're subscribed!
✓ You're already on the list.
Published September 2026.
TL;DR: Almost every GEO guide assumes an English-only site. Mine doesn’t — this one runs in 13 languages — and three things broke or underperformed the moment I looked past English: hreflang/x-default correctness, llms.txt scope, and schema consistency across locales. Here’s what actually changes and the audit prompt I use to check a multilingual site in one pass.
[Operator’s read] Every GEO checklist I’ve read, including two of my own, was written against one language. I only found out how much of that advice quietly assumes English when I went looking for why my Spanish and Japanese pages weren’t getting the same treatment as the English originals — same content, same schema template, wildly different outcomes.
Table of contents
Open Table of contents
- Why multilingual GEO isn’t SEO in 12 more languages
- What actually breaks first: hreflang and x-default
- The gap nobody checks: llms.txt only covers English
- Schema and entity consistency across locales
- Different languages, different AI engines
- The real evidence from my own site
- Tell Claude or ChatGPT to do it: a multilingual GEO audit prompt
- What to skip
- The bottom line
- GEO for Multilingual Sites — FAQ
Why multilingual GEO isn’t SEO in 12 more languages
Classic international SEO has a settled playbook: hreflang tags, translated content, done. GEO adds a layer that playbook doesn’t cover, because an AI engine isn’t just indexing your page — it’s deciding, per query and per language, which single source to quote back to the user. That decision runs separately in every language the engine serves, against a different competitive set, a different citation-worthy source pool, and sometimes a completely different engine.
A ChatGPT answer in English is pulling from a different candidate pool than the same question asked in Japanese. Ignore that and you end up doing all the GEO work once, in English, and assuming it propagates. It doesn’t.
What actually breaks first: hreflang and x-default
This is the one that costs you visibility without ever showing up as an error. Two failure modes, both silent:
- Missing or wrong x-default. Every hreflang cluster needs an
x-defaultentry telling engines and crawlers which version to serve someone whose language doesn’t match any of your translations. Skip it and you’re telling every untargeted crawler “guess.” - hreflang pointing at pages that aren’t actually translations. This one is sneakier and more common. If your language switcher links to every locale’s homepage as a fallback when a translation doesn’t exist yet, and you tag those fallback links with
hreflang, you’re asserting that an English-only post is a Spanish translation of itself. It isn’t. Google’s crawler eventually stops trusting the whole cluster; an AI engine building a citation graph from your<link>tags inherits the same bad signal.
I had exactly this bug. My header’s language switcher used to emit hreflang on every locale link, including the ones that fell back to a locale’s homepage because no translation existed yet. Every English-only post was quietly claiming to have twelve translations it didn’t have. The fix was mechanical once found: only annotate hreflang when a real translation exists, and always emit x-default — falling back to the first available alternate when a translation cluster has no English member — so every real cluster has one.
Here’s the shape of the fix, as it actually renders in the page <head>:
<link rel="alternate" hreflang="es" href="https://example.com/es/post-slug/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/post-slug/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/post-slug/" />Three rules worth checking on your own site, in this order: every hreflang cluster has exactly one x-default; no hreflang link points at a page that isn’t a real translation; no two <link> tags in the same cluster share a code (Google discards the entire cluster if they do, not just the duplicate).
The gap nobody checks: llms.txt only covers English
llms.txt is the emerging convention for giving AI crawlers a clean, curated index of your best content instead of making them crawl and guess. I built one for this site months ago. I didn’t notice until I went looking for this piece that the endpoint only lists English posts — the filter that selects which posts go in the index checks lang === 'en' and stops there.
That means twelve-thirteenths of this site’s content is invisible to any crawler that respects llms.txt as an index rather than just a suggestion. Every non-English post still gets crawled through the sitemap and internal links, but the curated, high-trust index — the one specifically built to hand an AI engine your best pages — was English-only by omission, not by decision.
If you run a multilingual llms.txt, check this now: does the file (or files) actually enumerate your translated posts, or does the index quietly collapse to your source language the same way mine did? A single shared llms.txt that lists only English URLs isn’t wrong, exactly — it’s just not doing anything for the other languages your site exists in.
Schema and entity consistency across locales
The FAQPage, Article, and Person schema you’re already running (see my schema markup breakdown if you haven’t set this up yet) has to say the same thing about you in every language, because AI engines are building one entity graph across all of them.
Two things to get right:
- Keep identifiers untranslated, translate the human-facing strings. Your
PersonorOrganizationschema’s@id,url,sameAsarray, andjobTitlevalue should be identical across every locale’s JSON-LD — that’s what tells an engine “this is the same entity” across languages. Only the surrounding prose and any human-readable labels change. - Don’t let a stale translation lag the schema. If you update your Article schema’s
dateModifiedor add a new FAQ entry in English, the same change has to land in every locale’s JSON-LD, not just the prose. An engine that sees English content updated last week and a French version of the same page with six-month-old schema reads that as two different pages, not one page in two languages.
Different languages, different AI engines
The GEO conversation defaults to ChatGPT, Perplexity, and Google AI Overviews because that’s where the English-language conversation happens. That’s not the full picture once you’re publishing in Russian, Chinese, or Korean.
Yandex runs its own generative answer layer for Russian-language queries and has meaningfully more share of Russian search than Google does. Baidu’s ERNIE-based answers matter for Chinese. Naver’s AI summaries matter for Korean. If your GEO checklist only accounts for the US-centric engine trio, you’re optimizing for maybe 60% of the actual answer engines your international readers use — and you won’t notice, because none of those engines show up in Google Search Console.
I don’t have a clean way to check citation rates on Yandex or Baidu from here, and I’ll say that plainly rather than pretend otherwise. What I can say: don’t assume the same three-engine list you optimize English for is the complete list everywhere.
The real evidence from my own site
Here’s what I can measure. This is the same GEO-vs-SEO comparison post, same content template, same schema, translated into every locale — pulled from Search Console for 15 June–11 September 2026:
| Locale | Impressions | Average position |
|---|---|---|
| Spanish | 2,077 | 31.9 |
| Dutch | 3,370 | 46.6 |
| French | 1,393 | 25.1 |
| Japanese | 106 | 14.8 |
| Korean | 57 | 24.9 |
| German | 86 | 60.6 |
| Italian | 32 | 67.8 |
| English | 569 | 58.2 |
Same post, same structure, same schema template, and the ranking spread runs from position 14.8 to position 67.8. I want to be honest about what this does and doesn’t prove: these are classic Google positions from Search Console, not AI-citation data — I don’t have clean per-locale attribution for ChatGPT or Perplexity citations, and I don’t know anyone who does yet. What it does prove is that “translate it and the same optimization work applies evenly” is false on my own site. The Japanese translation, with a fraction of the impressions, outranks every other locale including the English original. Something about that page — competition, translation quality, how the entity resolves in Japanese — is working that isn’t working in German or Italian, and the schema template is identical across all of them.
Tell Claude or ChatGPT to do it: a multilingual GEO audit prompt
You don’t need to read hreflang specs to check this. Paste this into Claude or ChatGPT with your site’s URL:
I run a website with content in multiple languages. For [URL], check: (1) does the page emit an
x-defaulthreflang tag, and does every hreflang tag on the page point to an actual translation rather than a fallback homepage; (2) does the page’s JSON-LD schema (Person, Organization, or Article) use identical@id,url, andsameAsvalues across languages, or do they differ by locale; (3) if the site has anllms.txtfile, does it list pages in languages other than English. Tell me exactly which of these fail, and quote the specific tag or field that’s wrong rather than a general summary.
Check the answer against the actual page source before you trust it — a model will confidently describe an x-default tag that isn’t there if you don’t make it look.
What to skip
Don’t build thirteen separate llms.txt files unless you have actual evidence — server logs showing AI crawler hits per subdomain, not a hunch — that engines are treating your locales as separate properties. One well-scoped file that actually lists your translated URLs solves the gap above without the maintenance overhead of thirteen.
Don’t machine-translate a page just to have a locale filled in. A thin, literal translation is worse for GEO than no translation at all — it gives an AI engine a low-quality source to weigh against a competitor’s native-language content, and it’s the fastest way to end up quoted in a support forum as “the site with the weird translations.”
The bottom line
If your GEO checklist was written against one language, run it against your worst-performing locale before you trust it as a system. Mine had a real, silent hreflang bug and an English-only citation index sitting for months before I checked. Both were easy fixes. Neither would have shown up if I hadn’t gone looking with a second language in mind.
GEO for Multilingual Sites — FAQ
Does hreflang actually affect AI-engine citations, or just classic Google rankings?
Both, though the mechanism differs. For classic Google, hreflang tells the crawler which URL to serve which locale in search results. For AI engines, hreflang and your schema together are part of how the engine resolves “is this the same entity/content across languages” — get it wrong and you risk the engine treating your English and Spanish pages as unrelated sources rather than one topic covered twice.
Should every post get translated into every language my site supports?
No. Translate posts where the topic and search demand justify it in that market — a US-specific pricing guide may not need an Arabic translation, and a global GEO explainer probably should get one. Untranslated near-duplicates across locales are worse than fewer, fully-translated posts.
How do I know if my llms.txt is scoped correctly?
Open the file and check whether the URLs listed include any non-source-language paths. If every URL is in one language and your site publishes in several, the index is scoped to that language only, whether or not that was the intent.
Do I need separate schema for each language, or one schema block reused everywhere?
One entity, translated presentation. The identifying fields (@id, url, sameAs) stay identical across locales; the human-readable text (headline, description, FAQ answers) gets translated per locale. Treat it as one entity described in multiple languages, not multiple entities.
Related reading: Schema Markup for GEO · How to Translate One Blog Post Into 13 Languages With One Agent · GEO for Solo Operators
Want a second pair of eyes on your own multilingual setup? Get in touch — I run GEO audits for sites publishing across more than one language, or run the prompt above yourself with Claude if you want to check it today.
Every Wednesday. 28,400+ operators. Zero fluff.
✓ Check your inbox — click the confirmation link to complete sign-up.
✓ You're subscribed!
✓ You're already on the list.
Related posts
How to Add GEO to an Existing SEO Retainer
How an SEO agency adds real GEO work to an existing retainer — audit first, price it as its own line, and avoid relabeling the same deliverables.
SEOGEO Audit Pricing: What to Charge Clients
How I structure and price a GEO audit — the flat-fee scoping approach, what belongs in the deliverable, and when to convert it into a retainer.
GEOHow to Get Cited by AI Search Through Reddit
AI Overviews and ChatGPT lean on Reddit threads more than most company blogs. Here's how to show up in them without astroturfing, buying upvotes, or bans.
Get the AI playbook in your inbox
Every Wednesday. 28,400+ operators. Zero fluff.
Check your inbox.
We sent you a confirmation email — click the link inside to complete your subscription. Check spam if you don't see it within a minute.
You're subscribed.
Welcome — the next edition lands in your inbox soon.
You're already on the list — look for it every Wednesday.