# Multilingual GEO and hreflang for AI answers > hreflang tells engines which language version to serve. How it shapes AI answer engines, cross-language cannibalization, and per-locale entities. _Source: https://seomatrix.ai/blog/multilingual-geo/ · Updated: 2026-07-14_ --- In short: **Multilingual GEO** is getting an AI answer engine to cite the *right language version* of your page. When you publish the same topic in English, Russian and Spanish, three things decide which one an assistant quotes: the `hreflang` cluster that maps the variants, the language and region signals in the query, and whether each locale carries its own clean entities instead of a machine-translated shadow of the English page. Get those right and a Spanish question surfaces your Spanish page; get them wrong and your three locales quietly compete for one citation — or the model paraphrases a translation you never wrote. This site ships `en`, `ru` and `es`, so we run this on ourselves. ## What multilingual GEO actually means Classic multilingual SEO asks: *which URL does Google rank for a Spanish searcher?* Multilingual GEO asks a harder question: *which language body does an answer engine lift a sentence from — and does it attribute that sentence to the matching locale?* The unit of competition moved from the ranked link to the quoted passage, and a passage has a language. A model that pulls a definition from your English page to answer a Russian prompt is a worse experience than a ranked-but-not-clicked English link, because there is no click for the user to redirect. So the job is two-sided: make each locale independently *readable and citable*, and make the relationship between locales explicit so the engine knows they are the same content, not three thin duplicates. ## How an AI answer engine picks a language variant There is no published "language ranking factor" for AI answers, but the observable inputs are the ones retrieval has always used, in this rough order: | Signal | What it tells the model | Where it lives | |---|---|---| | Query language | the language to answer in | the user's prompt | | `hreflang` cluster | which URLs are the same page in other languages | `` or sitemap | | `` + content | the actual language of this document | the page itself | | Per-locale entities | that this variant is genuinely about the topic | headings, body, schema | | Region hints (`x-default`, ccTLD, `es-MX`) | which regional variant fits | hreflang, URL | The query language dominates: ask in Spanish, get Spanish. Everything below it is how the engine *finds* your Spanish page instead of translating your English one on the fly. hreflang is the map that connects the cluster; the per-locale content is what makes each node worth citing on its own. ## hreflang: still the load-bearing signal hreflang predates AI answers, but it does exactly the job multilingual GEO needs: it declares "these URLs are the same page in different languages/regions" so an engine treats them as one canonical concept with several language faces, not as duplicates fighting each other. The rules haven't changed: - **Reciprocal.** If `en` points to `es`, `es` must point back to `en`. One-way hreflang is ignored. - **Self-referential.** Each page lists itself in its own cluster. - **BCP 47 codes.** `es`, `es-MX`, `ru` — language, optionally language-region. Not `sp`, not `es_MX`. - **One `x-default`.** The fallback for a language you didn't publish. Ship hreflang in the ``, in an XML sitemap, or in HTTP headers — pick one and be consistent. Our [hreflang checker](/tools/hreflang/) exists because the single most common failure is a broken return tag that silently drops a whole locale out of the cluster. ## Cross-language cannibalization: the quiet failure Same-language cannibalization — two English pages fighting for one query — is well understood ([semantic cannibalization](/blog/semantic-cannibalization/)). The cross-language version is sneakier. It happens when your locales are near-identical machine translations with no hreflang binding them: to an engine they look like several thin pages on the same topic, so retrieval splits confidence across them and none is a confident citation. The fix isn't to prune — you *want* all three languages — it's to bind them with reciprocal hreflang so they read as one concept, and to make each locale substantively its own page. > **The machine-translation trap** — A locale that is a word-for-word MT of your English page, with no local examples, no local sources, and no hreflang link, is the worst of both worlds: it doesn't read as a genuine variant to a human, and it doesn't read as the *same page* to an engine. Either translate with real localization (examples, entities, sources in that language) or bind the MT tightly with hreflang — never ship a naked translated duplicate. ## Per-locale entities, not translated strings An entity is a thing an engine recognizes — a product, an org, a place — independent of the word used for it. Cross-language, the same entity has different surface strings ("Search Console" vs "Консоль поиска") but should resolve to the *same* node. Two rules make that work: - **Keep proper nouns and canonical brand/product names stable** across locales so the entity survives translation; localize the prose around them. - **Localize the supporting entities** — cite native-language sources on each variant, use region-appropriate examples — so the page is genuinely *about* the topic in that language, not an echo. It is the same [triples](/blog/triples/) discipline, applied per locale. ## We dogfood this: en / ru / es This post exists in three languages. Each is a real localization, not an MT pass; each links to its own locale's blog and tools (`/blog/…`, `/ru/blog/…`, `/es/blog/…`); all three share one `key` so the build binds them into an hreflang cluster automatically. That last part is the lazy win: derive hreflang from the content model, don't hand-maintain it. Our [hreflang checker](/tools/hreflang/) workflow is built around exactly that — translate a post, keep the key, and the return tags generate themselves. ## Checklist - [ ] Every localized page carries reciprocal, self-referential hreflang. - [ ] Language codes are BCP 47 (`es`, `ru`, `en`), region only when it matters. - [ ] Exactly one `x-default` per cluster. - [ ] `` matches the page's real language. - [ ] Each locale is a genuine localization, not a naked MT duplicate. - [ ] Proper-noun entities stay stable; supporting entities and sources are localized. - [ ] Internal links stay in-locale (a Spanish page links to Spanish pages). The point isn't the exact numbers — it's the shape: one missing reciprocal tag can collapse a three-language cluster down to whichever variant the engine happened to find, undoing the whole reason you published in three languages. ## In short - Multilingual GEO = getting AI answers to cite the *right language* version, attributed correctly. - The query's language decides the answer language; hreflang and per-locale content decide *which of your pages* fills it. - Reciprocal, self-referential, BCP-47 hreflang binds your locales into one concept instead of competing duplicates. - Cross-language cannibalization comes from naked MT duplicates with no hreflang — localize for real, and bind the cluster. - Keep proper-noun entities stable, localize the supporting ones, and derive hreflang from the content model so it never drifts. ## Sources - **Google Search Central — "Tell Google about localized versions of your page"** — the canonical hreflang rules (reciprocity, `x-default`, sitemap vs ``). - **Google Search Central — "Managing multi-regional and multilingual sites"** — language vs region targeting guidance. - **BCP 47 / RFC 5646, "Tags for Identifying Languages"** — the language-tag standard that hreflang and `` use. - **Aggarwal et al., "GEO", KDD '24** — [arXiv:2311.09735](https://arxiv.org/abs/2311.09735): citation depends on passage extractability, which per-locale clean content maximizes. ## FAQ ### Does hreflang affect AI answers? Not as a ranking factor, but as plumbing. hreflang declares that your language versions are the same page, so an answer engine treats them as one concept with several language faces instead of thin duplicates. That is what lets it retrieve your Spanish page for a Spanish prompt rather than translating your English one on the fly. ### How does an AI answer engine pick a language variant? The query language dominates: ask in Spanish, get Spanish. Below that, the engine uses your hreflang cluster to find the matching URL, the page's own language and content to confirm it, and region hints (x-default, es-MX, ccTLD) to choose between regional variants. Clean per-locale content is what makes each variant worth citing. ### Can my language versions cannibalize each other in AI answers? Yes, when they are near-identical machine translations with no hreflang binding them. To an engine they look like several thin pages on one topic, so retrieval splits confidence and none becomes a confident citation. The fix is not to prune - it is reciprocal hreflang plus real localization so each locale is its own page.