AI Discovery Files Get the files
In Practice

Multilingual sites

The upstream llms.txt format defines the Markdown structure of a file but no discovery pattern for language variants. This project defines one: language-path files, linked from the root.

Multilingual specification Swedish example

The core rule

Language variants live at language paths, not under variant filenames. Three things make a multilingual setup discoverable:

  1. 1

    A primary llms.txt at the site root

    For the default language. This stays concise and authoritative.

  2. 2

    A language-path llms.txt for each other language

    At /fr/llms.txt, /sv/llms.txt and so on — matching the language paths your site already uses.

  3. 3

    Links from the root file to each variant

    Under a dedicated ## Language-Specific llms.txt Files heading, in normal link-list format.

/llms.txt 
## Language-Specific llms.txt Files

- [French llms.txt](https://www.yourdomain.com/fr/llms.txt): French-language AI discovery file.
- [Swedish llms.txt](https://www.yourdomain.com/sv/llms.txt): Swedish-language AI discovery file.

The linking rule that trips people up

The root file's language section links to language-path llms.txt files only. It does not link localized copies of the other discovery files.

Not this

## Language-Specific llms.txt Files

- [French llms.txt](/fr/llms.txt)
- [French FAQ](/fr/faq-ai.txt)
- [French ai.txt](/fr/ai.txt)

This

## Language-Specific llms.txt Files

- [French llms.txt](/fr/llms.txt)
- [Swedish llms.txt](/sv/llms.txt)

Localized versions of faq-ai.txt, ai.txt and the rest are linked from their own language-path llms.txt. Each language file acts as the hub for its own language, which keeps the root file short and the structure predictable.

What each language-path file needs

Same format, target language

Follows the same Markdown structure as the root file, written in the target language for descriptions and link notes.

Links within its own language path

Point at localized pages where they exist, rather than sending a French reader back to English pages.

A link back to the root

Recommended, so a consumer that lands on a variant can find the primary file and the rest of the set.

Decide whether you need this at all

Every extra language multiplies the files you must keep consistent, and inconsistency is the failure these specifications exist to prevent. Most sites do not need language variants.

If your situation is Publish Shape
One language, one market A single set of files at the root. Nothing else to do. /llms.txt
One primary language, a few translated pages A single root set. Link the translated pages from within llms.txt rather than duplicating the whole file set. /llms.txt
Genuinely multilingual, each language a full site section A root llms.txt for the primary language, plus a language-path llms.txt for each other language, linked from the root. /llms.txt + /fr/llms.txt
Separate legal entities per market Separate domains, each with its own complete set. Do not try to represent two legal entities in one identity.json. Per-domain sets

The cheap middle path

Keep one root llms.txt in your primary language and link your translated pages from its normal link sections, with the language named in the link text. An AI system gets one unambiguous identity plus a map of where the other languages live — most of the benefit, none of the drift.

This page summarises the multilingual profile defined in specs/multilingual-sites.md . The specification document is the authority — where the two differ, it is correct.