Short answer. Retrieval is language-scoped. An assistant answering a question in Thai draws its candidate sources predominantly from Thai-language content, so a brand whose entire library is in English is not competing weakly on that surface — it is absent from it. Unlike ranked search, there is no lower position to occupy and no click for a motivated user to translate. The pipeline that fixes this is not a translation project: it is question collection per market, in-language production with in-market review, and enough published substance per language to be a plausible source. The constraint that stops most programmes is arithmetic — forty questions across six languages is 240 maintained pages, and that is a standing operation rather than a project.
This guide covers why language coverage is a retrieval problem, what has to be true before content helps, the pipeline in order, and the production volume nobody budgets for.
Why an English-only library is invisible rather than disadvantaged
A generative assistant retrieves before it generates. It gathers candidate sources, then synthesises. Those candidates are drawn overwhelmingly from content in the language of the query, because that is what matches.
The difference from ranked search is structural, not one of degree:
| Ranked search | Generated answer | |
|---|---|---|
| A foreign-language page can still | Appear at a lower position | Not appear |
| The user can | Click through and translate it | Not see it existed |
| Partial visibility | Exists as position 40 | Does not exist |
| Recovery path | Rank higher over time | Publish in the language |
There is no partial credit. This is why "we will localise later" is a different decision in an answer-engine context than it was in a search context: later means absent, not lower.
The two surfaces, and why conflating them makes programmes look failed
Retrieval — assistants reading the live web at query time — responds to what you publish, on a timescale of days to weeks.
Model memory — a model answering from training with no tools — reflects what was written about you elsewhere, and changes only at the next training run, on a timescale of months to model generations.
Publishing in a new language moves the first almost immediately and barely touches the second. A programme that publishes in Japanese and then measures how a browsing-disabled model describes the brand will report no result indefinitely, having done work that succeeded.
Report the two separately, per language. A single blended number for six markets and two surfaces is not a measurement; it is an average of things that move at different speeds in response to different actions.
What has to be true before content in a language helps
Two prerequisites, both cheap relative to content and both routinely skipped.
Entity resolution. An engine has to be confident that your trading name, legal name, domain and profiles refer to one organisation before it can name you as an answer. Declare the alternates in structured data rather than using them interchangeably; get the parent-and-division relationship right rather than duplicating the parent's identifiers onto a division; keep naming consistent across every property you control. A brand with strong content and unresolved identity gets described accurately when asked directly and never surfaced for its category — which reads from the inside like a content problem and is not one.
Delivery. The page has to arrive complete. Content that exists only after JavaScript hydration, and internal links rendered client-side, are absent for a meaningful share of fetchers. In a multilingual build this is worse than usual, because language switchers are frequently implemented as client-side state rather than as distinct URLs — which means the other languages are not separate pages at all.
What makes a passage worth quoting, in any language
The most-cited measurement here is Aggarwal et al., "GEO: Generative Engine Optimization", ACM SIGKDD 2024, which tested content modifications across a 10,000-query benchmark: adding statistics improved visibility by up to 40%, authoritative quotations by roughly 30%, and keyword stuffing scored −10% — worse than making no change.
Translated into production terms, the unit of optimisation is the passage, not the page.
| Page-level habit | What an answer engine needs |
|---|---|
| Build to a conclusion | The answer stated in the first two sentences |
| Keyword coverage | Specific, checkable claims — figures, dates, named sources |
| Authoritative tone | Attributable authority: name the source in the sentence, not only in the link |
| Long undifferentiated prose | Self-contained sections that survive being read alone |
| One page per keyword variant | One page per question, consolidated |
| English-first, translate later | In-language substance, produced for the market |
None of this conflicts with ordinary quality guidance. A page that opens with a direct answer, carries real figures and names its sources is a better page by any standard, which is why this is a content-quality programme rather than a trick.
The pipeline, in order
The order is the part that gets ignored. Teams that start at step four and reach step one late publish substantial libraries and see nothing move.
- Fix entity resolution. Canonical naming, declared alternates, correct parent-division relationships, consistent identity across owned properties.
- Collect the questions per market. From sales calls, support tickets and live assistant runs in that language — not from an English list translated. Questions differ by market in substance, not only in wording, and a translated list embeds the source market's assumptions about what buyers care about.
- Decide what is worth publishing, per market. Not every question deserves a page in every language. A shorter library that is genuinely useful outperforms a complete one that is thin, and it stays clear of scaled-content policy.
- Write answer-first, with specifics. Question as heading, answer in the opening sentences, figures and named sources throughout, each section self-contained.
- Produce in-language, with in-market review. Generate or write in the target language where model capability supports it, translate under review where it does not, and have someone in the market read the result against a defined rubric.
- Mark up what the page actually says. Accurate structured data helps an engine parse and attribute; inflated markup is a liability and is checkable.
- Build the link graph in static markup. Each language a real URL, each page linked from another crawlable page, no navigation that exists only after hydration.
- Measure per language and per surface. Retrieval and memory separately, with a baseline taken before any publishing.
The constraint nobody budgets for
The strategy above is not where these programmes fail. They fail on production volume, and the arithmetic is unforgiving.
Pages required = Questions worth answering × Languages sold in
Forty questions across six languages is 240 pages — each needing in-language substance, in-market review and periodic updating. That is a standing content operation, not a project. What happens instead is predictable: the programme ships the eight highest-priority pages in English, plans the rest, and the rest does not arrive. Eight pages do not change a candidate pool in six languages.
The honest options are two. Narrow the scope until it fits the capacity you have — three languages done properly beats six done partially, and choosing that deliberately is a good decision. Or acquire capacity. What is not an option is planning for 240 and staffing for eight, which is the default and the reason this category has a reputation for not working.
How Lifewood approaches this
Lifewood's core business is multilingual production and review at catalogue scale, which is the specific constraint described above: 50+ languages with region-native reviewers, 40+ delivery centres across 30+ countries, 56,788 registered contributors, and a dual-layer human-in-the-loop review process held to a 95%+ accuracy threshold. The 240-page problem is the problem that operation was already built for.
Two limits stated plainly. First, entity resolution and delivery are fixed before any publishing, because content published from an unresolvable entity onto pages that arrive incomplete produces no movement and no diagnosis. Second, if your constraint is knowing what your visibility currently is rather than producing content, the right purchase is a measurement platform — that is a genuinely different product.
See AEO services and GEO services.
Sources and further reading
- Aggarwal et al., "GEO: Generative Engine Optimization", ACM SIGKDD 2024 — the 10,000-query benchmark behind the statistics, quotation and stuffing figures.
- Google Search Central, guidance on generative AI content and on generative AI features — on quality expectations and scaled content.
- Schema.org,
Organization— includingalternateNameandparentOrganization, the properties that carry entity alternates and hierarchy. - Companion guides: Why Generative AI Gets Worse in Your Second Language and How to Choose Multilingual AI Visibility Services.