Multilingual AEO: How hreflang, Translation Quality, and Entity Consistency Shape AI Answers

Ask ChatGPT a question in German and it answers in German - and when it retrieves sources, it strongly prefers German-language pages. That single behavior drives almost everything about multilingual AEO. If your product has English content only, you are effectively invisible for prompts asked in French, Japanese, or Portuguese, even when the underlying question is one your English pages answer perfectly.

The fix is not "add hreflang and move on." hreflang helps AI-adjacent retrieval less than it helps classic Google, and it does nothing for a training crawler reading raw HTML. What matters more: genuinely useful translated pages that can stand alone as citable sources, a per-locale entity story that stays consistent (same organization name, same product names, same facts in every language), and locale-aware supporting files like llms.txt. This post walks through the mechanism and the implementation order.

How AI engines pick a language

There is no ranked "international index" the way classic search has one. Two separate pipelines decide what an AI engine says in a given language.

The model's parametric knowledge. Training corpora are dominated by English, but every major model trains on large non-English corpora too. What a model "knows" about your brand in Spanish comes from whatever Spanish-language text about you existed at training time - your Spanish pages, Spanish press coverage, Spanish forum threads. If none existed, the model either falls back on translated English knowledge or knows nothing.

Live retrieval. When ChatGPT search, Perplexity, or Gemini fetch sources for a prompt, the query they issue is derived from the user's prompt - which means it is usually in the user's language. Retrieval then surfaces pages in that language first. You will occasionally see an engine cite an English page in a Dutch answer and translate on the fly, but in our audits this is the exception, typically appearing when same-language coverage of the topic is thin. In competitive topics, same-language sources crowd out foreign-language ones.

The practical consequence: every language you sell in is a separate citation market with its own competitors. A German competitor with mediocre German content routinely beats your excellent English content for German prompts, because they showed up in the language of the query and you did not.

What hreflang actually does for AI search

hreflang annotations - the link rel="alternate" hreflang="x" cluster documented in Google's localized-versions guide - tell classic Google which locale variant to show which searcher. Its role in AI search is narrower, and it is worth being precise about it.

Where hreflang still matters. Google AI Overviews and AI Mode sit on top of Google's index, and that index uses hreflang to cluster locale variants and select the right one per user. Getting hreflang wrong there can mean AI Overviews in Spain cite your Mexican Spanish page, or worse, treat near-duplicate locale pages as competing content. Gemini benefits from the same index plumbing.

Where it does little. GPTBot, ClaudeBot, and PerplexityBot read your pages as HTML documents; there is no public evidence any of them build a Google-style hreflang cluster from your annotations. A retrieval bot answering a French query finds your French page because that page exists, is crawlable, and matches the query in French - not because an hreflang tag pointed at it.

So implement hreflang correctly (bidirectional annotations, self-references, x-default), but treat it as table stakes for the Google-side surfaces, not as your multilingual AEO strategy. The strategy is the content itself.

The machine-translation quality bar

The question every team asks: can we machine-translate our top pages and get cited in ten languages?

Argue it from mechanism. An AI engine deciding whether to quote your German page evaluates that page as a German document. Modern machine translation produces grammatically clean output, so raw fluency is rarely the blocker anymore. What breaks is everything around fluency.

• Terminology drift. MT often translates your product terms, feature names, and category vocabulary inconsistently across pages - one page says "Antwortmaschinenoptimierung", another leaves "Answer Engine Optimization" in English. Inconsistent terminology weakens the entity associations that citations depend on.
• Untranslated context. Screenshots, code comments, testimonial quotes, and structured data frequently stay English inside a "translated" page. A page that is 70% German and 30% English reads as low-effort to humans and models alike.
• Locale-blind facts. Pricing in dollars on a page for a euro market, US-specific legal claims, examples referencing US-only tools. The words are translated; the substance is not localized.

The workable bar: machine-translate, then have a fluent reviewer fix terminology against a per-language glossary, localize the facts, and translate the metadata - title, description, heroAlt, schema text fields, FAQ answers. That gets you a page that can genuinely be quoted verbatim in a German answer, which is the actual test. If you cannot review a language, publish fewer languages. Ten shallow locales earn less than three solid ones, because each locale competes on its own merits in its own market.

llms.txt for multilingual sites

The llms.txt spec is a single Markdown file at your root that curates your most important pages for language models. It has no formal multilingual mechanism - no hreflang equivalent, no per-locale variant convention that agents are known to check. So handle languages inside the file structure the spec already gives you.

• Keep one /llms.txt at the root, written in your primary language.
• Add an H2 section per additional language ("## Deutsch", "## Francais") listing that locale's key pages, with the one-line descriptions written in that language. A model scanning the file for German material should find German link descriptions, not English ones.
• If your locales live on separate hostnames (de.example.com, example.de), each host is its own origin and should serve its own llms.txt in its own language - agents fetching example.de/llms.txt will not fall back to your .com file.
• List locale pages you actually maintain. A curated file pointing at abandoned half-translated pages is worse than one that honestly lists three languages.

If you already generate llms.txt, our guide on how to generate llms.txt covers the base format, and the free llms.txt checker will validate what you ship, per host.

Per-locale entity consistency

Citation is downstream of entity recognition: the engine must connect your German page, your English page, and third-party mentions to one brand. Translation is where that connection quietly breaks.

• Never translate the brand or product names. "Citevera" is "Citevera" in every language. Teams localizing marketing copy sometimes localize product names too, and each variant becomes a separate weak entity instead of one strong one.
• Ship the same Organization schema everywhere. Every locale page should carry Organization markup with the identical @id, identical name, and the same sameAs links. Use schema's inLanguage and translated description fields for what varies; keep the identity fields byte-identical. Our Organization schema deep dive covers the base pattern - the multilingual rule is simply: one @id, many languages.
• Keep facts synchronized. If your English pricing page says one thing and the stale French translation says another, engines retrieving in different languages will contradict each other about your product - and a model that notices conflicting claims about an entity treats both less confidently.
• Localize the surrounding evidence. Same-language third-party mentions (local directories, local press, local review sites) do for each locale what English mentions did for your home market. An entity that only exists in English-language sources is an English-only entity, whatever your site says.

An implementation order that matches the mechanism

Step 1 - pick markets, not languages. Choose the two or three locales where you have customers and can maintain content, and commit to full depth there.

Step 2 - translate your citable core first. Not the homepage. The pages that win citations: definition pages, comparison pages, FAQ-rich guides. Localize facts, metadata, and schema text along with body copy.

Step 3 - wire the plumbing. Bidirectional hreflang with x-default, per-locale sitemaps, language-sectioned or per-host llms.txt, identical Organization @id across locales.

Step 4 - verify crawlability per locale. Locale subdomains and country domains often sit behind different CDN configs; a bot rule that is fine on .com can be blocking on .de.

Step 5 - monitor per language. Run your tracked prompts in each target language, not just English. A brand can be well-cited in English and absent in German for the same question, and you will never see it if you only test in English.

Frequently asked questions

Do AI engines translate English sources into other languages when answering?

Sometimes, but you should not rely on it. When same-language sources are thin, engines will retrieve an English page and translate its substance into the answer. In competitive topics, same-language sources dominate retrieval, and the English-only site drops out. Treat cross-language citation as a fallback behavior, not a strategy.

Is hreflang required for AEO?

It is required for the Google-side surfaces - AI Overviews and AI Mode inherit Google's index, which uses hreflang to pick locale variants. For retrieval bots like GPTBot, ClaudeBot, and PerplexityBot there is no public evidence hreflang changes behavior; they find locale pages by crawling and by query-language match. Implement it correctly, then invest your real effort in the translated content itself.

Should llms.txt be translated for each language?

Keep one root llms.txt per host. On a single-host site with subdirectory locales, add a section per language listing that locale's key pages with descriptions written in that language. On separate hostnames per locale, each host needs its own llms.txt because agents fetch it per origin and will not fall back to another domain's file.

Is machine translation good enough to get cited?

Raw MT fluency is usually fine; what fails is consistency and substance. Pass MT output through a fluent reviewer with a terminology glossary, localize prices, examples, and legal claims, and translate metadata and schema text. A page only earns citations in a language if it can be quoted verbatim in that language without embarrassment.

How do I keep one brand entity across ten languages?

Never localize brand or product names, ship Organization schema with an identical @id and sameAs set on every locale page, and keep core facts synchronized across translations. Then build same-language third-party mentions in each market, because entity strength in a language comes from that language's corpus.

Check each locale the way an engine sees it

Multilingual AEO fails silently: everything looks fine in English while a stale translation, a blocked locale host, or a translated product name quietly costs you every non-English citation. A Citevera audit scores each locale's crawlability, schema consistency, and answer-readiness separately, and the free AI crawler access checker takes any locale URL - .de, .fr, or a subdirectory - and shows you exactly which engines can fetch it. Run it against every market you claim to serve.