Multilingual GEO and hreflang for AI answers

The one-line version, for anyone who scrolls: Multilingual GEO is getting an AI answer engine to cite the right language version of your page — and the plumbing that decides it is older than the engines themselves.

The question behind this post is an awkward one. I was running this very post through our hreflang checker — this site ships en, ru and es, so we run this on ourselves — and realised I could not say which of the three an assistant would quote to a Spanish speaker, or why. 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.

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. Simple to state; judging by how often return tags turn out broken, hard to do.

How an AI answer engine picks a language variant

There is no published “language ranking factor” for AI answers, so this is my reconstruction, not a spec — 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	<head> or sitemap
<html lang> + 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. Could the engine find the Spanish page without the map? Sometimes, probably — but “sometimes” is not a strategy for a third of the site.

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 <head>, in an XML sitemap, or in HTTP headers — pick one and be consistent. Our hreflang checker exists because the single most common failure is a broken return tag that silently drops a whole locale out of the cluster. Silently is the operative word: nothing errors, nothing warns, the page renders beautifully!

Cross-language cannibalization: the quiet failure

Same-language cannibalization — two English pages fighting for one query — is well understood (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.

Here is how I go looking for it. Hypothesis: the locales are cannibalizing. First I check whether the variants are bound at all — do the return tags exist, and are they reciprocal? Then I read the Spanish page next to the English one and ask whether anything in it could only have been written for a Spanish reader — a local source, example or price. Two answers of “no” and I have found it — three pages the engine likely sees as one thin page, three times.

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 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 (I have hand-maintained it — never again!). Our hreflang checker workflow is built around exactly that — translate a post, keep the key, and the return tags generate themselves. Is our Russian version perfectly localized everywhere? Honestly, probably not; but it is a Russian page written for Russian readers, which is the bar, and the cluster binding it here is generated, not typed.

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.
• <html lang> 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).

Reciprocal hreflang 3 langs

One return tag missing 1 lang

source: industry estimates / internal audits, 2026

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. Three translations, one line of markup, and everything hinges on the line — does that seem proportionate? No — which is why it gets missed.

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.

And the Spanish speaker from my first paragraph? If the plumbing holds, they get the Spanish page and never learn how close they came to a machine-translated one — the best outcome infrastructure gets: nobody notices it worked.

Sources

• Google Search Central — “Tell Google about localized versions of your page” — the canonical hreflang rules (reciprocity, x-default, sitemap vs <head>).
• 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 <html lang> use.
• Aggarwal et al., “GEO”, KDD ‘24 — arXiv:2311.09735: citation depends on passage extractability, which per-locale clean content maximizes.