What the one available evaluation found
There is exactly one study we could locate that measures assistant behaviour across languages and was not produced by a company selling visibility services. It is worth going through carefully, because it is the whole evidential basis for everything anyone says about this.
“Evaluating Commercial AI Chatbots as News Intermediaries”, by Mirac Suzgun, Emily Shen, Federico Bianchi, Alexander Spangher, Thomas Icard, Daniel E. Ho, Dan Jurafsky and James Zou, is an arXiv preprint dated 21 May 2026 from Stanford-affiliated authors. The design: a fourteen-day evaluation, 9 to 22 February 2026, of six commercial chatbots — Gemini 3 Flash and Pro, Grok 4, Claude 4.5 Sonnet, GPT-5 and GPT-4o mini — on 2,100 factual questions derived from same-day BBC News reporting across six regional services: US & Canada, Arabic, Afrique, Hindi, Russian and Turkish. That is 12,600 model-question instances.
The headline result is that the systems are good at this: “the best systems achieve over 90% multiple-choice accuracy on questions about events reported hours earlier”, though they “lose 11–13% under free-response evaluation, and 16–17% across the cohort”.
The result that matters for this guide is the first of three failure patterns the authors characterise, and we quote it in full because it is short and unambiguous: “every model achieves its lowest accuracy on Hindi (79% vs. 89–91% elsewhere) and citations indicate an Anglophone retrieval bias (e.g., models answering Hindi queries cite English Wikipedia more than any Hindi outlet)”.
The second failure pattern tells you where the problem lives: “retrieval, not reasoning, failures drive over 70% of all errors. When models retrieve a correct source, they often extract the correct answer; the problem is to land on the right source in the first place.” Read those two findings together and the shape of the answer appears. These systems are not bad at Hindi in the sense of not understanding it. They are bad at finding Hindi sources. That is a supply-and-selection problem in the retrieval layer, and a publisher or a communications team operates in exactly that layer. The general problem of retrieval landing on the wrong document is the subject of how often AI search tools cite the wrong source.
The paper publishes percentage citation shares only for a few regional comparisons, and they are small numbers that repay attention. On Hindi-language queries the single most-cited domain was English Wikipedia, at 3.1%. On Russian-language queries, English Wikipedia and The Guardian between them accounted for 5.4% of citations, while the leading Russian-language outlet, rbc.ru, took 2.2%. We examined the same paper's global ranking in which sources AI assistants actually cite, where English Wikipedia is described as the single most-cited source globally and the paper publishes no global share for any domain.
% of citations, by regional query panel
Source: Suzgun, M., Shen, E., Bianchi, F., Spangher, A., Icard, T., Ho, D. E., Jurafsky, D. and Zou, J., 2026. Evaluating Commercial AI Chatbots as News Intermediaries, arXiv preprint 2605.22785v1, 21 May 2026. Six chatbots, 2,100 questions, 9–22 February 2026.
These are the only percentage shares the paper publishes; it ranks the global top ten without shares. Questions were derived from BBC reporting, which may advantage BBC-adjacent and English-language sources — a known feature of the design, acknowledged by the authors, and a reason to treat the size of the Anglophone effect as uncertain even though its direction is clear. Preprint, not peer-reviewed.
Why the retrievable web leans English
A retrieval bias towards English is easier to understand once you look at what is available to retrieve. Three independent measurements, one of which anyone can reproduce in a minute, all point the same way.
Common Crawl is the open web archive that sits underneath a great deal of language-model work, and it publishes the language composition of every monthly archive. The identification is done by Compact Language Detector 2, which handles 160 languages and up to three per document, and only HTML pages are passed to it. In the latest archive at the time of writing, CC-MAIN-2026-39, English is the primary detected language of 41.86% of pages. Russian is 6.70%, German 5.73%, Japanese 5.17%, Spanish 4.74%, French 4.68%, Chinese 4.23%, Portuguese 2.49%, Italian 2.46%, Polish 2.03%. Arabic is 0.67%. Hindi is 0.21%. A further 3.06% could not be identified. What Common Crawl is and why publishers increasingly block it is covered in what is Common Crawl.
A second, differently constructed measurement agrees on the direction. W3Techs, a commercial technology survey run by Q-Success, reports English at 49.5% of “all the websites whose content language we know”, followed by Spanish at 6.0%, German 5.9%, Japanese 4.9%, French 4.5%, Portuguese 4.1% and Russian 3.4%; Arabic is 0.6% and Hindi falls below the 0.1% reporting floor. This is a vendor survey of a sample of sites rather than a census, its subject is sites rather than pages, and it is included here because it corroborates a shape, not because it settles a magnitude.
% of HTML pages, archive CC-MAIN-2026-39
Source: Common Crawl, Statistics of Common Crawl Monthly Archives — Distribution of Languages, archive CC-MAIN-2026-39, read 26 September 2026. Languages identified by Compact Language Detector 2; only the primary language returned per document is counted; only HTML pages are passed to the detector.
Common Crawl is a sample of the crawlable web, shaped by its own seed lists and politeness rules, not a measurement of the web's true composition. Comparing it to the four regional panels in the Suzgun study is suggestive, not a controlled comparison: the study's languages and Common Crawl's shares were produced by different projects for different purposes.
The third measurement is the one to run yourself, because it concerns the single source the Suzgun paper found most-cited. Querying each Wikipedia's own API on 26 September 2026: English Wikipedia holds 7,244,795 articles. German holds 3,154,036, French 2,781,499, Spanish 2,139,533, Russian 2,119,323, Arabic 1,333,430, Turkish 701,309 and Hindi 171,706. English is roughly 42 times the size of Hindi Wikipedia by article count.
That single ratio explains a great deal of the finding in the previous section without any appeal to model behaviour at all. If a retrieval system reaches for reference material first — and every measurement of citation patterns we have seen says it does — then on a Hindi query it is choosing between a reference work with 7.2 million articles in the wrong language and one with 172,000 in the right one. The choice it makes is not evidence of prejudice. It is evidence of a corpus. The role reference sources play in this machinery is the subject of Wikipedia and reference presence and, for the sourcing rules that govern what gets into them, Wikipedia's perennial sources.
Articles, read from each project's API on 26 September 2026
Source: live reads of the MediaWiki siteinfo statistics endpoint on en, de, fr, es, ru, ar, tr and hi wikipedia.org, 26 September 2026.
Article counts measure volume, not quality, depth or currency; a count is not a claim that one edition is better than another. The eight editions shown were chosen to cover the regional panels in the Suzgun study plus the largest European editions, and are not the complete list.
What hreflang and language markup actually do
This is where most international SEO advice quietly inverts the documentation, so it is worth quoting Google directly.
From Google's page on telling it about localized versions: “Google doesn't use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language.” From its multi-regional and multilingual guidance: “Google uses the visible content of your page to determine its language. We don't use any code-level language information such as lang attributes, or the URL.”
So hreflang is not a language label. It is a mapping between variants you have already written, used to decide which one a given searcher is shown. Its stated purpose is that it “will help Google Search point users to the most appropriate version of your page by language or region”. If you have one page in one language, hreflang has nothing to do. If you add an hreflang annotation claiming a Spanish variant that does not exist, you have not gained Spanish visibility; you have described a page that is not there.
Three implementation rules from that page are worth knowing because each one silently voids the annotation. Annotations must be reciprocal: “each language version must list itself as well as all other language versions”, and “if two pages don't both point to each other, the tags will be ignored. This is so that someone on another site can't arbitrarily create a tag naming itself as an alternative version of one of your pages.” URLs must be fully qualified, including the scheme. And there should be a fallback: the x-default value exists “to match any language not explicitly listed by an hreflang tag on the page”. Google notes that the three delivery methods — HTML link elements, HTTP headers and sitemaps — are “equivalent from Google's perspective” and that there is “no benefit in Search” to using more than one.
One further line is useful for anyone weighing a translation project against a localisation project: “Localized versions of a page are only considered duplicates if the main content of the page remains untranslated.” Translating the navigation and leaving the article in English creates the duplicate problem; translating the article does not.
On the assistant side there is a vocabulary property and no documented mechanism. Schema.org defines inLanguage as “the language of the content or performance or used in an action”, expects an IETF BCP 47 code, and applies it to CreativeWork and therefore to Article. Marking it is free and correct. But no assistant operator publishes a rule in which a language declaration changes retrieval, and Google has told us it reads the visible text rather than the code. Treat inLanguage as metadata hygiene, not leverage — the same conclusion we reached about markup generally in does schema markup affect citation.
The crawler is in America and speaks no language at all
Two sentences in Google's multilingual documentation deserve more attention than they get, because they break a common architecture outright.
“If you prefer to dynamically change content or reroute the user based on language settings, be aware that Google might not find and crawl all your variations. This is because the Googlebot crawler usually originates from the USA. In addition, the crawler sends HTTP requests without setting Accept-Language in the request header.” And, in the geotargeting section: “Don't use IP analysis to adapt your content. IP location analysis is difficult and generally not reliable … Most, but not all, Google crawls originate from the US, and we don't attempt to vary the location to detect site variations.”
Put those together. A site that serves German to German IP addresses and English to everyone else will be crawled, by default, in English. A site that keys off Accept-Language will be crawled in whatever it serves when that header is absent. A site that auto-redirects a visitor to a locale homepage may prevent the crawler from reaching the others at all — which is why Google's guidance says to “avoid automatically redirecting users from one language version of a site to a different language version” and to offer links instead.
Google's remedy is the boring structural one: “use different URLs for different language versions”, one language per page, no side-by-side translations, and an explicit language or region selector. That advice is about Googlebot, and Google is the only operator that documents its crawling geography in this detail. Whether other retrieval crawlers behave the same way is not published; what we know about how each of them identifies itself is collected in which AI crawlers publishers name and how to verify a crawler is real. The reasonable default is to assume any crawler is a first-time anonymous visitor from an unknown country with no language preference, because that is what the one documented case looks like.
And the eligibility rule at the end of the chain is the same in every language. Google's guidance for its AI features states that to be shown as a supporting link a page “must be indexed and eligible to be shown in Google Search with a snippet”, and that there are “no additional requirements … nor other special optimizations necessary”. A local-language page that the crawler never reaches cannot clear that condition, however good the coverage behind it was. The timing of that chain is covered in how fast coverage reaches AI answers.
Should a multi-market company seek local-language coverage?
Here the honest answer requires separating two questions that are usually sold as one.
The first question is whether local-language coverage is worth having. Yes, and the case does not depend on anything in this guide. Local coverage reaches local buyers, local regulators, local candidates and local journalists, who are the people who make decisions in that market. A German trade title read by German procurement managers is doing a job that no amount of English-language coverage does. That argument stands on its own and is the one we would make first; the general case for narrower, better-read outlets is in do trade publications outperform national outlets.
The second question is whether local-language coverage increases the chance of being cited by an assistant, and here the evidence genuinely cuts both ways. We are going to lay out both directions rather than pick one, because picking one would be an invention.
The case against: retrieval favours English. The only measurement available found an Anglophone retrieval bias explicit enough to put in an abstract, and the corpus figures explain why. If a system reaches for English Wikipedia even when answering in Hindi, then an English-language article about your company is closer to the centre of the retrievable web than a Hindi one, and a company with a fixed budget might rationally put it into English coverage and English reference material.
The case for: the queries are not in English. Users ask in their own language, the assistant's retrieval is at least partly steered by the query language, and the competing corpus in that language is much thinner. A well-sourced Turkish article about your company competes against 1.28% of the crawled web rather than 41.86% of it. Thin corpora cut both ways — less competition, but also less machinery reaching into them — and nobody has published which effect dominates.
What nobody has is the experiment. No published study varies a company's local-language coverage and measures the resulting change in what an assistant says about it, in any language. We looked, and if such a study exists we did not find it. Anyone quoting a figure for the AI-visibility return on local-language PR is extrapolating from a corpus statistic to a causal effect, which is precisely the step the evidence does not support. That is the same gap we identified in can a company influence what AI says.
Three practical notes that do follow from documented facts. Machine-translating your site is not market coverage; it produces pages whose visible content is in the target language, which is what Google reads, but it produces no third-party sources in that language and no reason for anyone local to link to it. Reference material in the local language is probably the highest-leverage single asset available, because the measurement we do have shows reference sources being reached for first and shows the local editions to be thin — though we note that this is an inference from two facts, not a measured result. And keep the English material, because the retrieval layer the research measured is the one you are actually operating in.
Methodology and limitations
Figures come from four sources, all read or re-read on 26 September 2026. The cross-language evaluation is “Evaluating Commercial AI Chatbots as News Intermediaries” by Suzgun, Shen, Bianchi, Spangher, Icard, Ho, Jurafsky and Zou, arXiv preprint 2605.22785v1, dated 21 May 2026: six commercial chatbots, 2,100 questions derived from same-day BBC News reporting across six regional services, fourteen days from 9 to 22 February 2026, 12,600 model-question instances. All quoted accuracy figures and the Anglophone retrieval-bias finding are from its abstract; the regional citation shares are the only percentage shares the paper publishes, and we report them as we did in our earlier guide to the same paper. Corpus composition is from Common Crawl's own published statistics for archive CC-MAIN-2026-39, where languages are identified by Compact Language Detector 2, only the primary language per document is counted, and only HTML pages are passed to the detector. The website-level comparison is W3Techs' content-language report of 26 September 2026. Wikipedia article counts were read directly from each project's MediaWiki siteinfo statistics endpoint on the same day. The hreflang, language-detection and crawler-geography statements are quoted verbatim from Google Search Central's Tell Google about localized versions of your page and Managing multi-regional and multilingual sites, and the AI-features eligibility rule from Top ways to ensure your content performs well in Google's AI experiences. Eight limitations should be read alongside the findings. First, and decisively, no published study varies a company's local-language coverage and measures the effect on assistant output, so this guide describes mechanisms and corpus asymmetries, not returns. Second, the Suzgun paper is a preprint and has not completed peer review. Third, its questions were derived from BBC News reporting, which plausibly advantages BBC-adjacent and English-language sources; the authors treat this as a known design feature, and it means the direction of the Anglophone effect is clearer than its size. Fourth, the paper covers six regional panels and six models over fourteen days in February 2026; it is not a general measurement of every language or a current snapshot of products that change monthly. Fifth, Common Crawl is a sample of the crawlable web shaped by its own seeds and politeness rules, not a census, and CLD2 misidentifies languages, especially on short or mixed pages — 3.06% of pages in the archive were not identified at all. Sixth, W3Techs is a commercial survey by Q-Success covering sites rather than pages and only those whose language it can determine; it is included to corroborate a direction and not to fix a magnitude. Seventh, Wikipedia article counts measure volume and say nothing about depth, accuracy or currency, and we did not attempt to compare quality across editions. Eighth, Google's documentation describes Google; no other operator publishes its crawling geography, header behaviour or language-detection method, so the crawler-geography section should be read as one well-documented case rather than a general rule.
Conclusion
Coverage in another language is worth having, and the reason is not artificial intelligence. It reaches the people who make decisions in that market, which is the whole justification and does not need a second one. On the narrower question this guide was asked, the evidence is unusually clear about the mechanism and silent about the return. Retrieval favours English: the one independent evaluation available says so in its abstract, and the corpus figures make it unsurprising — 41.86% of the latest Common Crawl is English, against 0.21% Hindi, and English Wikipedia is 42 times the size of the Hindi edition. Retrieval is also where the errors are, with over 70% of failures coming from landing on the wrong source rather than misreading the right one. What none of that tells you is whether a Turkish article about your company makes a Turkish answer more likely to mention you, because nobody has run that test. The documented actions are dull and safe: write real content in each language you actually operate in, give each language its own URL, make the visible text unambiguous because that is what Google says it reads, wire hreflang reciprocally or it is ignored, and stop expecting a lang attribute to do work that Google has said in writing it does not do.
Frequently Asked Questions
Do AI assistants retrieve across languages or default to English?
They retrieve across languages and still lean English. The only independent evaluation we located — Suzgun and colleagues, a Stanford-affiliated arXiv preprint dated 21 May 2026 — put 2,100 questions to six commercial chatbots over fourteen days and reports that “citations indicate an Anglophone retrieval bias (e.g., models answering Hindi queries cite English Wikipedia more than any Hindi outlet)”. Every model scored its lowest accuracy on Hindi, at 79% against 89–91% elsewhere. It is a preprint and has not completed peer review.
Does hreflang tell Google what language a page is in?
No, and Google says so in one sentence: “Google doesn't use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language.” Its multilingual guidance repeats it: “Google uses the visible content of your page to determine its language. We don't use any code-level language information such as lang attributes, or the URL.” hreflang decides which of your existing variants is served to which searcher. It does not label a page's language, and it does not create visibility in a language you have not written in.
Why is the retrievable web so English?
Because it is, measurably. In Common Crawl's latest monthly archive, CC-MAIN-2026-39, English is the primary detected language of 41.86% of HTML pages, against 6.70% Russian, 5.73% German, 5.17% Japanese, 4.74% Spanish, 0.67% Arabic and 0.21% Hindi. W3Techs, a commercial survey by Q-Success, puts English at 49.5% of the websites whose content language it can identify as of 26 September 2026. And English Wikipedia held 7,244,795 articles on the day we checked, against 171,706 in Hindi — a ratio of about 42 to 1 in the single source the one available evaluation found to be the most-cited globally.
Does a crawler even see my local-language site?
Google documents two facts that work against it. “The Googlebot crawler usually originates from the USA” and “the crawler sends HTTP requests without setting Accept-Language in the request header”. Elsewhere: “Most, but not all, Google crawls originate from the US, and we don't attempt to vary the location to detect site variations.” A site that decides which language to serve from the visitor's IP address or Accept-Language header is therefore likely to show the crawler one version only. Google's stated fix is structural: “use different URLs for different language versions” rather than swapping content at one URL.
Should a company operating in several markets seek local-language coverage?
Yes, for reasons that mostly are not about AI visibility. Local-language coverage reaches local buyers, regulators, recruits and journalists, and that is a sufficient case on its own. On the narrower question of whether it increases the chance of being cited by an assistant, the evidence cuts both ways: retrieval demonstrably favours English sources, which argues for English-language coverage; but the assistants are answering queries in the local language, where the competing corpus is far thinner, which argues for local coverage. Nobody has published a test that varies a company's local-language coverage and measures the change in an assistant's answers, so we cannot give you a ratio.
Is there any markup that declares a page's language to an assistant?
There is a vocabulary property, and no documented retrieval consequence. Schema.org defines inLanguage as “the language of the content or performance or used in an action”, taking an IETF BCP 47 code, and it applies to CreativeWork and therefore to Article. Marking it is good hygiene and costs nothing. But Google's own statement is that it determines language from visible content and not from code-level information, and no assistant operator publishes a rule in which a language declaration affects retrieval. Anyone selling inLanguage markup as an AI-visibility lever is describing a mechanism that is not documented.
What is the safest thing to do about language and visibility?
Write real content in each language you actually operate in, put each language on its own URL, and make each page's visible text unambiguously in one language, because that is what Google says it reads. Add reciprocal hreflang annotations with an x-default fallback, remembering Google's rule that “if two pages don't both point to each other, the tags will be ignored”. Do not machine-translate a site and call it market coverage. And do not drop your English-language material, because the retrieval layer the research measured still reaches for English first.
Sources
- academic Suzgun, M., Shen, E., Bianchi, F., Spangher, A., Icard, T., Ho, D. E., Jurafsky, D. and Zou, J., 2026. Evaluating Commercial AI Chatbots as News Intermediaries. arXiv preprint 2605.22785v1, 21 May 2026. Six commercial chatbots, 2,100 questions from same-day BBC News reporting across six regional services, 9–22 February 2026. Anglophone retrieval bias; Hindi accuracy 79% against 89–91% elsewhere; retrieval failures over 70% of errors. Preprint, not peer-reviewed.
- dataset Common Crawl, Statistics of Common Crawl Monthly Archives — Distribution of Languages. Archive CC-MAIN-2026-39; languages identified by Compact Language Detector 2; primary language per document only; HTML pages only. Read 26 September 2026.
- vendor survey W3Techs (Q-Success), Usage statistics of content languages for websites, 26 September 2026. English at 49.5% of websites whose content language is known. A commercial survey of a site sample, not a census.
- live technical read Wikimedia Foundation, MediaWiki siteinfo statistics endpoint, queried on the en, de, fr, es, ru, ar, tr and hi projects on 26 September 2026. Article counts as reported by each project.
- documentation Google Search Central, Tell Google about localized versions of your page. The statement that Google uses neither hreflang nor the lang attribute to detect language; reciprocity requirement; x-default; the equivalence of the three delivery methods; the duplicate-content rule for untranslated main content. Read 26 September 2026.
- documentation Google Search Central, Managing multi-regional and multilingual sites. Language determined from visible content, not code; Googlebot originating in the USA and sending no Accept-Language header; the warning against IP-based adaptation and automatic language redirects; the recommendation to use different URLs per language. Read 26 September 2026.
- documentation Google Search Central, Top ways to ensure your content performs well in Google's AI experiences. The eligibility rule that a page must be indexed and snippet-eligible, with no additional requirements. Read 26 September 2026.
- vocabulary Schema.org, inLanguage. Definition, expected IETF BCP 47 values, and the types it applies to including CreativeWork. Version 30.1, read 26 September 2026.