llms.txt Language: Fixing Missing Language Declarations

A language model reading your llms.txt cannot see the flag icons or language switcher on your site. If the file does not say which language each linked page is in, a tool may send an English speaker to your German pages, or treat two translations of the same page as two different topics.

The llms.txt proposal has no special language field, so the fix is about using the parts it does have clearly. This guide covers single-language sites, bilingual UK sites, and international sites that need one file per locale.

By John Carlsson · Updated 28 September 2026 · About 13 minutes to read

📋 Demo 📘 Tutorial 📖 Guide 📚 Book 🔧 Fix

In this guide

Why language needs saying out loud
Choosing a layout for your site
Single-language sites: one sentence fixes it
Bilingual sites: one file, clearly labelled
The fix, step by step
International sites: one file per locale
Language mistakes to avoid
Plain wording helps every language
Questions and answers

Why language needs saying out loud

On a web page, language is declared in several places at once: the lang attribute on the html element, hreflang links between translations, sometimes a Content-Language header, and the visible language switcher. llms.txt has none of that. It is plain Markdown, and the proposal published by Jeremy Howard in 2024 defines an H1, a blockquote summary, free text and H2 sections of links. There is no language key or tag.

So a file that lists https://www.example.com/de/versand/ next to https://www.example.com/shipping/ gives a reader nothing but the URL to work out that one is the German version of the other. A model might guess from the /de/ folder. It might not. And many sites do not put the language in the URL at all.

When the auditor raises a language finding, it is pointing at one of these situations:

The file never says what language the site or the file is in.
Links to pages in different languages are mixed together with no labels.
The notes are in one language and the pages in another, with no explanation.
The same page appears several times, once per translation, as if they were separate topics.

💡 None of this is about ranking. As far as we know, no major AI search provider has confirmed reading llms.txt at all. It is about making the file unambiguous for the tools that do read it, which often run in a different language from your default.

Choosing a layout for your site

There are three workable patterns. The right one depends on how many languages you publish and how completely each one is translated.

Your site	Layout	Why
One language only	One file, with the language stated in the summary	A single sentence removes all doubt; nothing else changes
Two languages, fully or mostly translated, such as English and Welsh	One file, with a section per language or a language label on every entry	The file stays short and one place describes the whole site
Three or more languages, or separate country sites	One root file in the main language, plus a file per locale in each language folder	Each file stays readable in its own language and can list pages that only exist there
A main language with a few translated pages	One file in the main language, with the translated pages grouped in one labelled section	Avoids pretending to be fully bilingual

Whatever layout you pick, reuse the language codes you already use in your hreflang tags, such as en-GB, cy, fr-FR or de. These are BCP 47 tags: a language code, optionally followed by a region. Using the same codes everywhere means your site, your sitemap and your llms.txt all agree.

Single-language sites: one sentence fixes it

For most UK small businesses the fix takes a minute. Add the language to the blockquote summary, and if you serve customers abroad, say which languages you do not offer.

# Millbeck Upholstery

> Furniture reupholstery and loose covers from a workshop in Matlock,
> Derbyshire. All pages are in British English. We do not offer
> translated pages, but we deliver to customers in Ireland and France.

Stating British English is useful beyond the language itself: it tells a reader that spellings, dates and prices follow UK conventions, so a date such as 03/04 means 3 April and prices are in pounds. If notes elsewhere in the file mention measurements or prices, keep them in the same conventions the pages use.

Bilingual sites: one file, clearly labelled

Welsh and English sites are the most common bilingual case in the UK, and public bodies in Wales often publish in both. Here is a single file for a fictional guest house with full translations. The file itself is in English; each Welsh entry names the page in Welsh and says in the note which English page it matches.

# Tŷ Afon Guest House

> Bed and breakfast with six rooms near Betws-y-Coed, Conwy.
> The site is fully bilingual: every page is in English (en-GB) and
> Welsh (cy). This file is in English.

Welsh pages live under /cy/ and English pages at the root.

## English pages
- [Rooms](https://www.example.co.uk/rooms/): six en-suite rooms, prices per night, dog-friendly room
- [Booking](https://www.example.co.uk/book/): availability, deposits, cancellation terms
- [Contact](https://www.example.co.uk/contact/): phone, email, directions and parking

## Welsh pages (cy)
- [Ystafelloedd](https://www.example.co.uk/cy/ystafelloedd/): Welsh version of Rooms
- [Archebu](https://www.example.co.uk/cy/archebu/): Welsh version of Booking
- [Cysylltu â ni](https://www.example.co.uk/cy/cysylltu/): Welsh version of Contact

The pattern does three jobs. The summary lists both languages with their codes. The details line explains how URLs are organised. And each translated entry points back to its equivalent, so a tool knows the two pages cover the same thing instead of treating them as separate topics.

If you prefer, you can keep one section per topic and add a label to each entry instead, such as - [Archebu](https://www.example.co.uk/cy/archebu/): booking, in Welsh (cy). That works well when only some pages are translated. Pick one style and use it for the whole file.

⚠️ Do not write notes in a language you cannot check. A machine-translated note that says something slightly different from the page is worse than an English note that says "Welsh version of Booking".

The fix, step by step

Step 1

Decide which languages the file covers

List every language your site publishes in and, for each one, roughly how much of the site is translated. Take the language codes from your existing hreflang tags or your multilingual plugin settings rather than inventing new ones. Then choose a layout from the table in this guide: one file with a sentence for a single language, one labelled file for two languages, or a root file plus one file per locale for three or more.

Step 2

State the language in the summary

Add a plain sentence to the blockquote under the H1 saying which language the file is written in and which languages the site offers, with their codes, for example All pages are in British English (en-GB) or The site is in English (en-GB) and Welsh (cy). If URLs follow a pattern such as /fr/ or a separate domain per country, explain that in one line of free text below the summary.

Step 3

Label every entry with its page language

On a site with more than one language, every link whose page is not in the file's own language needs a label. Either place those entries in a section whose heading names the language and code, or end the note with the language in brackets. For a translation, say which page it matches, so a reader can see that Archebu and Booking are the same content rather than two unrelated pages.

Step 4

Split into sections or files per language

If the file has become a long mix of languages, split it. With two languages, one H2 section per language is enough. With three or more, create a separate llms.txt inside each language folder, such as /fr/llms.txt, written entirely in that language with its own H1 and summary, and listing only pages in that language, including pages that exist only there and have no English equivalent at all.

Step 5

Link the language files from the root file

Tools look at the root first and do not go hunting in folders, so the root file must point to the others. Add a section such as ## Other languages with one entry per locale file, naming the language in its own words and in English, for example - [Français](https://www.example.com/fr/llms.txt): French site, prices in euros. Each locale file can link back to the root in the same way.

Step 6

Serve each file as UTF-8 with no language redirect

Save every file as UTF-8 so accented letters and characters such as ŷ or ß survive, and check with curl that each one returns 200 with charset=utf-8. Make sure your server does not redirect /llms.txt by browser language or visitor location, which gives different tools different files. Then run the llms.txt Auditor on the domain and confirm each linked file is reachable.

International sites: one file per locale

A shop selling into several countries often has different products, prices, delivery terms and even legal pages in each market. Squeezing all of that into one English file produces a long list where most entries are irrelevant to any given reader. Separate files are cleaner.

The root file

# Harrowby Tweed

> Tweed fabric and clothing woven in West Yorkshire. This file covers the
> UK site in British English (en-GB). Separate files describe our French
> and German sites, which have their own prices and delivery terms.

## Products
- [Jackets](https://www.example.com/jackets/): cuts, sizes, fabric weights
- [Fabric by the metre](https://www.example.com/fabric/): patterns, widths, samples

## Other languages
- [Français](https://www.example.com/fr/llms.txt): French site (fr-FR), prices in euros
- [Deutsch](https://www.example.com/de/llms.txt): German site (de-DE), prices in euros

The French file, in French

# Harrowby Tweed (France)

> Tissus et vêtements en tweed tissés dans le West Yorkshire. Ce fichier
> décrit le site français (fr-FR). Prix en euros, livraison depuis le
> Royaume-Uni.

## Produits
- [Vestes](https://www.example.com/fr/vestes/): coupes, tailles, grammage des tissus
- [Tissu au mètre](https://www.example.com/fr/tissu/): motifs, largeurs, échantillons

## Clients
- [Livraison et retours](https://www.example.com/fr/livraison/): délais, frais, retours

## Other languages
- [English](https://www.example.com/llms.txt): UK site (en-GB), prices in pounds

Notice that the French file has its own delivery page, which the UK file does not list, and that it uses French section headings. Keep the heading that links between languages the same in every file, so a tool can find the way between them. Only publish a locale file when someone who reads that language has checked it.

Separate domains per country

If each market has its own domain, such as example.fr and example.de, give each domain its own root llms.txt in its own language. You can still cross-link them in an Other languages section, but each file stands on its own at its own root.

Language mistakes to avoid

Automatic language redirects on the file. Many multilingual set-ups redirect visitors by Accept-Language header or location. If that rule covers /llms.txt, a tool running on a French server may receive the French file, or an HTML page. Exclude all llms.txt paths from language redirects.
Translating URLs in the file. Always copy the real address of each page. Translating a slug by hand, for example writing /fr/livraison/ when the live page is /fr/expedition/, creates a broken link.
Listing every translation of every page. Ten languages times twenty pages is two hundred entries. Use per-locale files instead, so each file stays short.
Mismatched codes. Writing en-UK in llms.txt when your hreflang uses the correct en-GB. The region code for the United Kingdom is GB.
A summary that only says "multilingual". Name the languages. "Available in several languages" tells a reader nothing useful.
Mixed plugin output. Some multilingual plugins generate one llms.txt per language automatically, others only for the default language. Check every address the plugin claims to create, and see the WordPress guide for plugin behaviour.

Plain wording helps every language

A file that will be read by tools working in many languages benefits from notes that translate cleanly. Short noun phrases survive translation far better than idioms and brand slang. "Delivery times, costs and returns" is understood everywhere; "Get it to your door in a flash" is not, and it says nothing specific even in English.

Hard to read across languages	Clearer
Our fab new SS26 drop	Spring and summer 2026 clothing range
Everything you need to know, sorted	Sizing, fabric care and returns
The nitty-gritty on pricing	Prices, VAT and payment options
Pop in and see us	Shop address, opening hours and parking

Wider advice on writing useful notes is in the thin content guide. For language, the rule is simpler: say which language, say it the same way every time, and never leave a reader to guess from a URL.

Questions and answers

1. Does llms.txt have an official language field?

No. The proposal defines an H1, a blockquote summary, optional free text and H2 sections containing lists of links, and none of those is a language field. That is why the fix relies on plain statements in the summary and clear labels on entries. If a future version of the proposal adds a formal way to declare language, you can adopt it then; stating the language in words will still be understood by any tool that reads the file.

2. What language should the root llms.txt be written in?

Write it in the main language of the site, usually the language of your home page and default URLs. For most UK businesses that is British English. If your site has no single default, for example a Belgian site in French and Dutch, pick the language most of your audience uses, say in the summary that other files exist, and link them from an Other languages section so a reader can move to the version they need.

3. Where should per-language llms.txt files live?

Put each one at the root of its language section, matching how your site organises languages: /fr/llms.txt for a folder layout, or the root of fr.example.com or example.fr for subdomains and country domains. The root llms.txt must link to each of them, because tools start there and will not discover files in folders by themselves. Use the same URL pattern as your pages so the arrangement is predictable for anyone reading it.

4. Should I translate the notes or keep them in English?

Keep notes in the language of the file they sit in. In a single bilingual file written in English, notes for Welsh or French pages can stay in English and say which page each one matches. In a separate locale file, write everything in that file's language. The important rule is accuracy: only publish text in a language someone on your team can read and check, because a wrong note is worse than a plain one.

5. Do I need to change my hreflang tags as well?

Not for llms.txt itself, since the two are separate. But your hreflang tags are the best record of which pages are translations of which, so use them as the source when you label entries and choose language codes. If you find while doing this that hreflang tags are missing or pointing at the wrong pages, fix them too, because search engines rely on them to show the right language version in results.

6. Is it a problem if the Content-Language header is missing?

For llms.txt it matters very little. The header is optional, and we are not aware of llms.txt tools that rely on it. What matters is that the file says its language in words and is served as UTF-8 so characters display properly. If you want to add the header to per-locale files, set it to the same code you use in the summary, but do not treat that as a substitute for the written statement.

7. Can one llms.txt cover a site in ten languages?

It can, but it quickly becomes too long to be useful, because every important page appears ten times. Beyond two or three languages, a short root file in the main language, with one entry per locale file, is far easier for both people and tools to follow. Each locale file then lists only pages in that language, including pages that exist in one market but not the others, such as local delivery terms.

Audit every language version of llms.txt

The llms.txt Auditor fetches your /llms.txt and /llms-full.txt files, validates them against the proposed format, checks that each linked URL responds, confirms robots.txt allows the relevant AI crawlers and scores the quality of the content.

Open llms.txt Fixes →