Multilingual AI Search Visibility: Your Site Speaks English, Half the Questions Do Not

Multilingual AI search visibility is the part of this work that almost nobody has looked at yet, and the numbers behind it are not subtle. OpenAI published aggregated usage data on June 30, 2026 showing that users who mostly work in a language other than English now make up more than half of active ChatGPT users, with Spanish, Portuguese and Arabic leading the non-English group. On the supply side, W3Techs measured English at 49.5% of all websites whose content language it can identify as of September 9, 2026, with Spanish at 6.0%, Portuguese at 4.1% and Arabic at 0.6%. Demand has gone global. The pages the engines have to choose from mostly have not. If you sell into more than one language market off a single English site, you are not competing badly in those markets. A lot of the time you are not in the running at all.

Does translating your website help AI search visibility?

Yes, and for a mechanical reason rather than a goodwill one. Retrieval systems have to pick a handful of passages to hand the model before it writes anything, and published research shows they do that badly when the passages are not in the language of the question. A team at the Technology Innovation Institute tested Arabic and English retrieval over two real corporate corpora, UAE legislation and UAE travel guidance, and reported the results in a paper called “The Cross-Lingual Cost,” updated on arXiv on October 27, 2025. On the legal corpus with one common multilingual embedding model, end-to-end answer accuracy was 68% when the question and the supporting document shared a language and 49% when they did not. With a second embedding model the same-language figure was 69% and the cross-language figure fell to 29%.

The authors traced the failure to a specific place. It is not that the retriever cannot understand a question in one language and a document in another. When they restricted the search to the correct language, performance was almost identical across every language pairing. The breakage happens when the retriever has to rank documents written in different languages against each other, and in that comparison it tends to favor passages in the language the question was asked in. One model leaned toward English whenever the query was English. The other leaned toward whichever language the user typed.

Read that back as a marketing problem. A buyer in Mexico City asks a question in Spanish. Your English page is the best answer that exists anywhere on the web. It still has to win a ranking contest against Spanish pages that are worse, judged by a system with a thumb on the scale for Spanish. Sometimes it wins. Often it does not, and you never learn that the comparison happened.

Do AI engines cite content written in other languages?

They can, and they do, but the answer usually gets assembled from sources that match the language of the question. That is the pattern in the retrieval research above, and it is also how the engines describe themselves. When Google took AI Mode into Hindi, Indonesian, Japanese, Korean and Brazilian Portuguese on September 8, 2025, the announcement was explicit that the work went past translation: building a global search product, in Google’s words, requires a nuanced understanding of local information, not a language swap.

Which is a polite way of saying the model is looking for locally grounded material, not a rendered copy of an American page. The practical effect for a brand is that each language behaves like a partly separate shelf. Authority you earned in English does not transfer cleanly onto the Japanese shelf, because the thing being compared is the passage in front of the retriever, and you do not have one there.

This is the same distinction we drew when we wrote about being mentioned versus being cited. A model may well know your company exists and say your name from memory in any language. Being the source it pulls from is a different job, and it is decided per language, per question.

Is machine translation good enough for AI search?

Raw machine output pushed live at scale is a risk, not a shortcut. Google’s spam policies, last updated August 28, 2026, name translation directly: producing many pages through automated transformations such as synonymizing or translating, where little value is added for users, is listed as an example of scaled content abuse. The test is not the tool. It is whether a person in that market gets something worth reading.

There is a second, quieter problem that has nothing to do with policy. Google says it determines a page’s language from the visible content, not from the lang attribute and not from the URL. Translating navigation and headers while the body stays in English gives you a page that reads as mixed, serves nobody well, and can put near-identical content into results under different boilerplate languages. Google’s guidance is to keep one language per page for both content and navigation, and to avoid side-by-side translations.

So the workable version looks like this. Machine translation as a first draft, then a human who actually sells in that market fixing the terminology, the examples, the currency, the objections and the names of things. Those are the details that make a passage look locally grounded instead of imported, and they are also the details a buyer notices in the first three seconds.

Which languages should you translate first?

Start where demand and supply are furthest apart, then apply your own revenue data. Two public datasets bracket the question. OpenAI reported in June 2026 that Spanish, Portuguese and Arabic are the leading non-English languages among ChatGPT users, that growth has been fastest in Africa and Asia, and that Uzbek, Kazakh and Burmese saw the largest gains in share of active users since July 2023 among languages with at least a million users. W3Techs, meanwhile, shows how thin the published web is in some of those languages.

Arabic is the line worth staring at. It is one of the three leading non-English languages on ChatGPT and it accounts for 0.6% of identifiable website content. Whatever the exact ratio, the shelf is close to empty in a language a very large number of buyers are asking in. For most companies the honest first cut is narrower than that: take the two or three markets where you already have revenue, sales coverage or a distributor, and translate the pages that answer questions rather than the pages that make claims. Homepages and pricing pages get translated first everywhere and they are the least useful assets in this game.

Does hreflang still matter when the traffic comes from an AI answer?

Yes, because hreflang is not a ranking favor, it is how you tell Google that these pages are versions of each other. Google’s international documentation asks for a distinct URL per language version and hreflang annotations, in tags, headers or sitemaps, to connect them. Without that, near-duplicate content in the same language across regional URLs turns into a canonicalization problem, and Google may serve the wrong version to the wrong market.

A few specifics from that documentation are worth pinning to the wall:

1. Give every language version its own URL, and pick a structure on purpose. Country domains, subdomains and subdirectories all work; URL parameters are not recommended.
2. Do not automatically redirect a visitor from one language version to another. Link between them instead, and let people choose.
3. Set an x-default so visitors in markets you have not targeted land somewhere sensible.
4. Do not rely on IP analysis to adapt content. Google says it is unreliable and that most Google crawls originate in the United States.
5. Support the language claim with local signals: local addresses and phone numbers, local currency, local links, a business profile where one applies.

That last point is the one teams skip, and it is the one that makes a translated page look native rather than exported. Google lists local language and currency, local addresses and phone numbers, and links from other local sites among the signals it uses to work out who a page is for. A Spanish page with a New York phone number and prices in dollars is a translated American page, and it reads that way to a person and to a machine.

How do you tell whether you are losing non-English AI answers?

You have to go and ask. There is no report that will tell you, because the loss shows up as an answer you were never part of, in a language nobody on your team searches in. The measurement work is the same shape as the English version of this job, run once per language.

1. Write down the ten questions that precede a purchase in your category, in the actual language of each target market, phrased the way a buyer would type them rather than translated from your English keyword list.
2. Ask them in the engines your buyers use, and record which domains get cited. Local publishers, local marketplaces and local forums usually dominate, which tells you what kind of page wins there.
3. Check whether you appear at all, and whether the description of you is right. A wrong description in a language you cannot read is worse than absence.
4. Inventory what you actually have in that language. Count resource and blog pages, not just the homepage and the product pages.
5. Translate and localize the three pages that answer the questions you lost, then re-ask the same ten prompts a month later.

If your team is running the English version of this loop already, this adds a column to the same tracker rather than a new program. It belongs inside your AI search work next to the rest of the retrieval questions. And if publishing capacity is the constraint, the fastest interim move is often the one we described in our piece on LinkedIn and AI citations: publish in-language on a high-authority third-party surface while the slower site work gets scheduled.

One trap to name before it costs you. A citation can land on a translation proxy or an aggregator that republished your content rather than on your own page, in which case the answer is right, the buyer is served, and you see no visit and get no credit. Owning the in-language URL is what stops that.