Does llms.txt support multiple languages?

No, not in the spec itself. There is no language field and no worked example with more than one language. That does not mean you cannot serve a multi-language site well, it means the structure is up to you, and one popular guess about how to do it does not actually work.

What the spec says, checked directly

I read the current text at llmstxt.org before writing this. It defines an H1 with the project name, an optional blockquote summary, optional markdown sections of prose, and optional H2-delimited sections that each hold a bullet list of links. Nothing in that list is a language marker, a locale attribute, or a rule about serving different content to different requesters. The spec is silent on the question, not restrictive about it.

Why /fr/llms.txt does not do what people expect

llms.txt follows the same fetch convention as robots.txt and sitemap.xml: a crawler asks the host directly for /llms.txt at the root, once. That convention is host-scoped, not path-scoped. If your languages live on one domain under paths, such as example.com/fr/, there is still only one /llms.txt for the whole domain, because nothing in the convention fetches example.com/fr/llms.txt or a sibling file named llms-fr.txt. Writing one there is not wrong, it is just invisible to anything that follows the standard convention, the same way a robots.txt placed at /fr/robots.txt is invisible to a crawler that only ever checks the root.

If your languages live on separate subdomains instead, such as fr.example.com and de.example.com, each of those is a distinct host, and each one can serve its own /llms.txt at its own root. That is the one setup where a genuinely separate file per language works with the standard fetch behavior, no workaround needed.

Three structures that actually work

One file, one dominant language, with the rest linked out. Write the H1, the summary and the main sections in whichever language you expect an assistant to reason in most reliably, and add a short section near the top pointing at the other language homepages. This is the lowest-effort option and it is what most sites publishing an llms.txt today appear to do, based on the ones I have read while building the generator and validator: an English file regardless of the site's primary audience, since English text is the safest common ground for a model that may be reasoning in English regardless of the user's language.

One file, one H2 section per language. This suits the exact case of hand-translating a few key pages while leaving the rest machine-translated, which is a reasonable thing to want and does not require anything nonstandard, since it is still one file at the normal path:

# Example Company

> Example Company makes widgets. This file lists hand-translated key pages in each language; the rest of the site is machine-translated from English.

## English

- [About](https://example.com/en/about): Company overview and contact details.
- [Pricing](https://example.com/en/pricing): Current plans and terms.

## French

- [A propos](https://example.com/fr/about): Presentation de l'entreprise.
- [Tarifs](https://example.com/fr/pricing): Plans et conditions actuels.

Separate files per subdomain. If the site already splits languages by subdomain, give each subdomain its own /llms.txt written natively in that language, with no cross-linking required, since each is a self-contained root file. This is the only option that gives a model a file already in its own language without asking it to skim past sections meant for someone else, and it costs nothing extra structurally since the subdomains already exist as separate hosts.

What I would not do

I would not maintain a nonstandard path like /llms-fr.txt hoping a crawler finds it on its own; nothing fetches it by convention, so it only helps a model that already followed a link to it from somewhere else, which you could do more simply by putting that same link inside the one real /llms.txt at the root. I also would not machine-translate the file itself and call it done. The value of llms.txt, such as it is, comes from a short, accurate, hand-checked map of what matters. A machine-translated map of a machine-translated site adds a second layer of drift on top of the first.

The short version: the spec has no language mechanism. Use one file with the other languages linked or sectioned in if everything lives on one domain, or one native file per subdomain if the site is already split that way. Skip any path that is not the plain root /llms.txt, since nothing standard will find it.

None of this changes whether the file affects citations at all. Google has confirmed it does not, for Search or its AI features; the other engines have not said either way, and that question is covered in what is llms.txt, and do you actually need one. If crawler access is the more pressing question, start with the free checker.