Multilingual Sites and AI Search: Which Version Gets Cited

When someone asks an AI assistant a question in Spanish and your site has a Spanish page, you want the assistant to read and cite the Spanish page. Whether it does depends mostly on signals search engines have used for over a decade: each language at its own URL, hreflang annotations that connect the versions, one entity behind all of them, and content written for each language rather than mechanically translated. Get those right and search engines and assistants can pick the right version. Get one wrong and they guess.

This post covers how crawlers decide which language version to use, the technical rules that most often break, what is different about AI assistants, and a checklist you can run on any site. It is part of our guide to agent-ready websites. The story of how we built our own three-language site is in How We Built a Multilingual Website With MCP.

How a crawler decides what language a page is in

A crawler meets your site one page at a time. For each page it has to answer three questions: what language is this, are there other versions, and which one fits this reader.

Google's guidance on multi-regional and multilingual sites is clear about the first question: it determines a page's language from the visible content, not from the lang attribute or the URL. That has a practical consequence. A Spanish page with an English navigation, English buttons and an English footer around a short Spanish paragraph sends mixed signals. Translate the whole page, including the interface.

The lang attribute on the <html> element is still worth setting correctly. Screen readers depend on it, browsers use it for translation prompts and hyphenation, and other crawlers may read it even if Google does not rely on it.

The rules that matter

Each language at its own URL

A page that switches language based on the visitor's browser setting or location, at a single URL, is one page to a crawler. It sees whichever version it was served and may never learn the others exist. Google's crawler mostly requests pages from US IP addresses without an Accept-Language header, so a site that redirects by location or browser language can hide its other versions from Google entirely, as its documentation on locale-adaptive pages explains.

Each language needs its own address. The three common structures:

Structure	Example	Good for	Trade-off
Subfolder	example.com/es/	Most sites	Shares the domain's authority; one site to manage
Subdomain	es.example.com	Separate teams or hosting per language	Treated more like a separate site
Country domain	example.es	Strong country targeting	Separate authority, more cost and admin

For most small and medium sites, subfolders are the right choice. Use parameters like ?lang=es only if nothing else is possible; Google discourages them.

Localize the slug too. /es/funciones/webs-multidioma tells a Spanish reader and a crawler this is a Spanish page. /es/features/multi-language-support says it is an English page with a prefix.

Let people switch, do not force them

Offer a visible language switcher and remember the choice. Do not redirect people automatically based on IP or browser language. If you want to help, show a small banner suggesting the other language and let the visitor decide. That keeps every version reachable for crawlers and for travellers, expats and anyone using a borrowed computer.

hreflang, complete and reciprocal

hreflang is the annotation that says "this page has these other language versions." Google's documentation on localized versions sets three rules that catch most sites:

Each version lists itself and every other version. Three languages means three hreflang entries on every page.
Every link must be returned. If the Spanish page points to the English page but the English page does not point back, the pair may be ignored.
Use valid codes. Language in ISO 639-1 format, optionally followed by a region in ISO 3166-1 Alpha 2. es is Spanish for everyone, es-MX is Spanish for Mexico. A region alone is invalid, and a common mistake is en-UK instead of the correct en-GB.

A complete set in the page head looks like this:

<link rel="alternate" hreflang="en" href="https://example.com/features/multi-language" />
<link rel="alternate" hreflang="tr" href="https://example.com/tr/ozellikler/cok-dilli" />
<link rel="alternate" hreflang="es" href="https://example.com/es/funciones/multidioma" />
<link rel="alternate" hreflang="x-default" href="https://example.com/features/multi-language" />

x-default names the version to show readers whose language you do not serve. Usually that is your original language, or a language selection page.

hreflang can live in the HTML head, in HTTP headers, or in the XML sitemap. Pick one method and be complete. The numbers explain why this breaks by hand: a site with 40 pages in three languages has 120 URLs, each needing four alternates. Add a page, rename a slug or remove a language, and every related entry has to change.

Not every search engine uses hreflang the same way. Bing's documentation says it treats hreflang and the content-language meta tag as signals among others, so the visible content and a correct lang attribute matter there too.

Canonicals: never across languages

A canonical tag tells search engines which URL is the main version of duplicate content. Translations are not duplicates. Each language version should have a self-referencing canonical. Pointing the Spanish page's canonical at the English page tells Google to ignore the Spanish page, and hreflang cannot override that. This is one of the most common multilingual mistakes, and it is often caused by a plugin default.

One entity, in every language

The business behind the Spanish page is the same business behind the English page, and the structured data should say so, with the same @id on every language version. Translate the description, keep the name, address and identifiers identical. If the English homepage declares an Organization and the Spanish one declares nothing, or declares it with a different id, an assistant answering in Spanish has a page but no reliable way to connect it to your business. The details are in Entity Schema for Small Sites.

Titles, descriptions and first paragraphs per language

A title translated word for word rarely matches what people search for in another language. Our Spanish title for the multi-language page leads with "Webs multidioma sin coste por idioma" because that is how a Spanish speaker phrases it, not because it is the literal translation of the English.

Research keywords separately for each language. The same applies to the meta description and to the first paragraph under the main heading, which is where both search snippets and AI answers most often take their sentence.

Pages that stay in one language

Legal pages, and sometimes a personal page like a founder's story, may exist in only one language. The cleanest solution is not to create translated URLs for them at all. Link to the original from the other languages, and leave them out of the hreflang set.

If your platform generates a URL for every language anyway, the untranslated copy really is a duplicate of the original, so a canonical pointing to the original is appropriate. Some sites also add noindex. Google's John Mueller has advised against combining the two, because noindex says "drop this page" while canonical says "consolidate it into another," so choose one. Either way, keep the untranslated URL out of your hreflang annotations and your sitemap.

Machine translation and quality

Machine translation is far better than it was, and many multilingual sites start from it. Google's spam policies target content produced at scale mainly to manipulate rankings without adding value, which can include unreviewed automated translation. A translated page that a fluent speaker has reviewed and adapted is a normal, valuable page.

The practical test is simple: would a native speaker believe this page was written in their language? Units, currencies, date formats, examples and phone number formats all need adapting, not just the words.

What AI assistants add to the picture

Assistants rely on largely the same signals, with some differences worth knowing.

The question sets the language. A search engine infers language from the browser and the query. An assistant knows the language of the question directly, and when it searches the web it tends to look for sources in that language. hreflang and localized URLs help it find your version.

Assistants quote. They look for a sentence that answers the question, in the language of the question. A Spanish page whose first paragraph is a clear, natural answer is easy to quote. A page that reads like a translation is easy to pass over.

Assistants can translate on the fly. If no good source exists in the question's language, many assistants read English sources and answer in Spanish. That means a missing translation does not always mean invisibility, but it does mean the assistant is paraphrasing your English page through its own translation, with the risk of errors, and may link a Spanish reader to an English page.

Most AI crawlers do not run JavaScript. If your language versions are rendered in the browser by a translation widget, those crawlers see only the original language. Translations should be in the HTML the server sends.

How each assistant weighs these signals is not publicly documented. What can be said is that the sites that do well are the ones that are unambiguous: one URL per language, connected with hreflang, with content that reads natively.

A checklist for a multilingual site

Every language at its own URL, with localized slugs, in subfolders unless you have a reason not to.
No automatic redirects by IP or browser language; a visible language switcher instead.
Full page translation, including navigation, buttons and footer, rendered in server HTML.
hreflang on every page, listing itself and all other versions, with return links, valid codes and an x-default.
Self-referencing canonicals on every language version.
A sitemap that includes every language version.
The same entity @id in the structured data of every language.
Titles, descriptions and first paragraphs researched and written for each language.
Single-language pages left out of hreflang, with either a canonical or noindex on any untranslated copies, not both.
A native speaker's read of the key pages in each language.

To test hreflang, view the source of a page in each language and confirm the entries match. Google Search Console no longer has a dedicated international targeting report, so third-party crawlers such as Screaming Frog or Ahrefs Site Audit are the practical way to check a whole site for missing return links.

How this works in Beste

Beste publishes each language at its own subfolder URL with a localized slug, renders every translation in the server HTML, and adds complete, reciprocal hreflang with x-default to every page. Every language version gets a self-referencing canonical and appears in the sitemap, and the entity structured data carries the same id across languages. Slugs, titles and descriptions are per-language fields you set yourself, or ask an agent to set across the site. Pages that should stay in one language can be kept out of the other languages entirely, and they are then left out of the hreflang set and the sitemap automatically. More than 50 languages are supported on every plan with no fee per language. Details are on the multi-language support page, and our own approach to choosing languages and reviewing translations is in How a Multilingual Website Builder Should Work.

Sources

Checked in October 2026.