Should a multilingual site have one llms.txt or one per language?

If your language versions live on separate paths, the cleanest pattern is a small root llms.txt that acts as an index and points to a per-language file such as /en/llms.txt and /de/llms.txt. Each of those files describes only the URLs under its own path, in the language of that version. If you have two or three languages and a short site, a single root file with one H2 section per language is perfectly valid and much less work to maintain.

Does the llms.txt spec say anything about multiple languages?

Not directly. The format is language-neutral: the H1, the summary blockquote and the link descriptions can be written in any language. What the spec does define is scope — a file covers the URLs under its path, and where more than one file applies, agents should use the most specific one. That single rule is what makes per-language subpath files work: /de/llms.txt covers everything under /de/.

Do I need separate llms.txt files for region variants like en-US and en-GB?

Almost never. Language is where llms.txt files earn their keep, because the file has to be readable by whoever the assistant is answering. Region variants of the same language usually share 90% of the same pages, so duplicating the file for en-US, en-GB and en-AU adds maintenance work without adding information. List the canonical page once and let your hreflang annotations handle the regional targeting.

Global SEO · September 2026

llms.txt for Multilingual Websites: One File or One Per Language?

Multilingual sites are the awkward case for llms.txt. English-only sites write one file and move on; global sites have to decide whether a single curated index can represent five languages, or whether each language version deserves its own. The spec does not answer the question — but it does give you the one rule that settles it.

The Rule That Settles It: Scope

The specification is explicit about what a file covers: an llms.txt file describes the URLs under its own path, and where more than one file applies to a given page, agents should use the most specific one. The file may sit at the root or at any subpath.

That is the whole ballgame. A root /llms.txt covers your entire domain, every language included. A file at /de/llms.txt covers everything under /de/ and wins for those URLs. The v2 spec revision (modified August 10, 2026) kept this wording unchanged — see what changed in v2 for the rest of the update, including the rel="describedby" link relation that lets a page point at the file covering it.

Note also that the format is language-neutral: nothing in it requires English. Descriptions should be written in the language of the content they describe, because the consumer is often a localised assistant answering a question in that language.

Three Structures That Work

Structure	Best for	Maintenance cost
A. Single root file, one H2 per language	2–3 languages, shorter sites	Lowest — one file to edit
B. Root index + `/en/llms.txt`, `/de/llms.txt` per locale	4+ languages, separate locale paths	Higher — one file per locale, but each stays short
C. Root file + `Optional` section for secondary languages	One dominant market, one or two minor ones	Low, but secondary languages are second-class

Structure B in Practice

The pattern that keeps showing up in practitioner write-ups is the sitemap-index shape: a small root file at the domain root whose job is to route agents to the right language file, plus one real file per language root. The root file stays stable for years because it changes only when you add or retire a language:

# Example Store

> Global retailer selling household goods in 6 languages.

## Language editions

- [English](https://example.com/en/llms.txt): full product and support content, primary market
- [German](https://example.com/de/llms.txt): full product and support content, DACH market
- [French](https://example.com/fr/llms.txt): product catalogue and shipping policy
- [Japanese](https://example.com/ja/llms.txt): product catalogue and support centre

Each locale file then does the real work under its own path — the top-level sections an assistant needs, with one-line descriptions, exactly as the best-practice rules describe. Keep the count of curated links per locale in the 20–40 range. If you are generating a first draft from a sitemap, the generator can start you off, but split the output by locale before you publish it — dumping six languages into one file is the failure mode this whole structure exists to avoid.

One caveat specific to subpaths: your locale directories must be real paths (/de/, /ja/), not cookie- or Accept-Language-based switching. If the language is decided at request time, there is no stable path for a file to cover, and there is no URL for an agent to cite.

Keep It Aligned With hreflang and Canonicals

List canonical URLs only. If /de/produkte/ is the German canonical, do not also list the parameterised or tracking variants.
One entry per language version, not per region. Your hreflang annotations already tell engines that de-DE and de-AT share a page. Duplicating it in llms.txt just adds noise.
Never list a page that redirects. A locale link that 301s to another language is worse than no entry at all — the agent burns a request and may cite the wrong version.
Self-reference with rel="describedby". Adding the link relation on localised pages (in the HTML head or as an HTTP Link: header) tells agents which file covers that page, which is how a deep /ja/... URL gets routed to /ja/llms.txt.

What Big Multilingual Sites Actually Ship

We checked a sample of global sites with curl on September 14, 2026. The picture is consistent: the root file is becoming normal, per-language files are not there yet — and the most multilingual site of them all publishes nothing at all.

URL checked	Status
`docs.stripe.com/llms.txt`	200, `text/markdown`, ~90 KB
`docs.stripe.com/de/llms.txt`	404
`developers.cloudflare.com/llms.txt`	200, `text/plain`
`developers.cloudflare.com/zh-cn/llms.txt`	404
`www.shopify.com/llms.txt`	200, `text/plain`
`www.shopify.com/de/llms.txt`, `/fr/llms.txt`	404 (both)
`about.gitlab.com/llms.txt`	200, `text/plain`, ~10 KB
`en.wikipedia.org/llms.txt`, `/es/`, `/ja/`	404 (all three)
`www.ikea.com/us/en/llms.txt`	404

Two lessons. First, publishing any valid file puts you ahead of most of the web. Second, if you already run locale paths, per-language files are a differentiator rather than a catch-up move: Stripe's single 90 KB file is genuinely useful for English-speaking developers, and useless to a German-speaking one asking about payment methods in German.

A Five-Minute Verification Pass

Check every path you claim to support, from one shell, and confirm the file is served as text and not as an HTML error page:

curl -sI https://example.com/llms.txt
curl -sI https://example.com/en/llms.txt
curl -sI https://example.com/de/llms.txt

# content type and first lines
curl -s https://example.com/de/llms.txt | head -20

Every URL returns 200 with text/plain or text/markdown — a 302 to your homepage counts as missing.
Every link inside each file resolves, and every link under /de/ really is German content.
The H1 and summary in each locale file are written in that locale, not machine-translated boilerplate.

Run the files through the llms.txt checker after each language launch, and re-run it whenever you add a locale. Structure follows content: add the language version first, then give it a file.

The short answer to the question in the title: one file if you have two or three languages, one file per language once locale paths are a real part of your site. Either way, make sure the file that applies to a page is the most specific one available — that is the only rule the spec asks you to respect.