多言語サイトの llms.txt：1 本にするか言語別に分けるか

30 秒で分かる結論：llms.txt は言語ごとに 1 本、ページと同じプレフィックスに置く

ルートの /llms.txt は既定の言語、つまり hreflang で x-default にしている言語で公開します。他の言語は、ページと同じプレフィックスにファイルを置きます。/ja/ 配下のページなら /ja/llms.txt、言語別サブドメインなら ja.example.com/llms.txt です。各ファイルはその言語で書き、その言語のページにリンクし、互いへのリンクは Optional に置きます。

仕様は言語に一言も触れずにこれを成り立たせています。ファイルはそのパス配下の URL を扱い、エージェントは最も具体的なファイルを使うことになっているからです。/ja/guides/wordpress に着いて最も近い llms.txt を探す読み手は、日本語のファイルに辿り着きます。もう一方の選択肢である 1 本の混在ファイルは、すべての読み手にすべての言語分のコストを払わせます。

仕様が言っていることと、言っていないこと

2026 年 8 月に改訂された v2 の仕様は、ファイルはルートでも任意のサブパスでもよく、ファイルはそのパス配下の URL を扱い、複数が当てはまる場合はエージェントが最も具体的なものを使うべきだと述べています。また 2 つのリンク関係を推奨しています。HTML ページからその Markdown 版へは text/markdown 型の rel="alternate"、ページからそれを扱う llms.txt へは rel="describedby" で、<link> 要素か HTTP の Link ヘッダで示します。

言語、ロケール、翻訳は本文のどこにも出てきません。ファイルの言語を示すフィールドも、2 つのファイルが互いの翻訳だと宣言する方法も、ルートのファイルをどの言語にすべきかの指針もありません。この先の内容は、その空白を慣習で埋めるものです。

3 つの構成と 3 つの答え

サイトの構成	公開するもの	ファイル同士のつなぎ方
主要言語が 1 つで、翻訳ページが数枚	主要言語の /llms.txt を 1 本	「他の言語」セクション（または Optional）で翻訳ページにリンク
サブパスごとに完全なロケール（/ja/、/de/）	既定言語の /llms.txt に加え、/ja/llms.txt、/de/llms.txt をそれぞれの言語で	ルートは Optional で各ロケールのファイルへ。各ロケールのファイルはルートと他のロケールへ
サブドメインや別ドメインごとに完全なロケール	ホストごとにそのホストの言語でルートの llms.txt	各ファイルは Optional で他のホストへ。ページの rel=describedby は同一ホスト内に留める

2 行目がドキュメントサイトや SaaS で最も多い構成で、ドキュメントプラットフォームが生成するのもこの形です。たとえば Mintlify はルートの索引を英語のままにし、ロケールごとの索引ファイルを /_llms/ 配下に出してルートからリンクします。一方、ローカライズ版のファイルをまったく公開していない多言語ドキュメントサイトも多く、2026 年 10 月時点で Vue と Astro のドキュメントの日本語版はロケールの llms.txt に 404 を返します。日本語の読み手が得られるのは英語の索引か、何もないかです。

hreflang との整合

検索エンジンに対しては、ローカライズ版をすでに 3 つの方法のいずれかで宣言しているはずです。HTML の head の link rel="alternate" hreflang、HTTP の Link ヘッダの同じもの、あるいは sitemap の xhtml:link です。各言語版は自分自身と他のすべてを列挙しなければならず、x-default はどの言語にも一致しないときの既定を指します。

llms.txt にはこれに相当する仕組みはなく、必要でもありません。役割が違うからです。1 つの言語のページをよく説明するもので、言語をまたいでページを対応づけるものではありません。2 つの仕組みを整合させる規則は 2 つです。1 つ目、ルートの llms.txt の言語を x-default の言語にします。エージェントが既定で見つけるファイルと、検索エンジンが既定で見せるページの言語が揃います。2 つ目、各ローカライズ済みページから自分のロケールのファイルを rel="describedby" で指し、ページと索引の言語を一致させます。

<!-- /ja/guides/wordpress の <head> 内 -->
<link rel="alternate" hreflang="en" href="https://example.com/guides/wordpress" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/guides/wordpress" />
<link rel="alternate" hreflang="x-default" href="https://example.com/guides/wordpress" />
<link rel="describedby" href="https://example.com/ja/llms.txt" />

このサイトの構成

KnownByLLM はサブパス方式で 9 言語を公開し、ルートは英語です。表の 2 行目の構成を、手書きではなく生成で実現しています。

ロケールごとにルートハンドラを 1 つ。app/llms.txt/route.ts が英語を、app/ja/llms.txt/route.ts から app/pt/llms.txt/route.ts までが残り 8 言語を配信します。中身はどれも数行で、共通のビルダーにロケールを渡し、結果を text/markdown で返し、ビルド時に描画されるよう force-static を付けるだけです。
ビルダーは 1 つ、辞書は 9 つ。ビルダーはロケールを受け取り、サイトの説明、セクション名、ページ名をそのロケールの辞書から取り、そのロケールの URL にリンクします。本文がまだ翻訳されていない設置ガイドは説明文が英語にフォールバックしますが、リンク先はローカライズ済みページなので、索引はどの言語でも完全です。
相互リンクは Optional に。どのファイルも末尾の Optional に仕様へのリンクと、他の 8 言語のトップページをそれぞれの言語の名前で並べています。ルートが英語なのは、英語がこのサイトの x-default だからです。
hreflang は sitemap から。sitemap は全ページをロケールごとに 1 回ずつ、xhtml:link の代替と英語 URL を指す x-default つきで列挙しています。検索エンジンから見た既定と llms.txt から見た既定が同じになります。

真似する価値があるのはコードではなく形です。ページ一覧の情報源を 1 つにし、言語ごとに 1 本を言語のプレフィックスに置き、既定の言語を 2 つの仕組みで揃えること。それだけです。

避けること

言語が混在したファイル。引用ブロックが書けなくなり、どの読み手のコストも 2 倍 3 倍になります。
ページより先に索引を翻訳する。リンク先が英語ページの日本語 llms.txt は読み手を欺きます。ローカライズ済みページがある場合だけそこにリンクし、なければ既定言語のページに一言添えてリンクします。
ルートのファイルでコンテンツネゴシエーション。同じ URL で Accept-Language によって言語を変えると、キャッシュもバリデータも混乱します。言語ごとの固定 URL が、クローラーにも人にも読み解けるものです。
ページを足したときにロケールのファイルを忘れる。sitemap と同じ一覧からファイルを生成すれば、新しいページは公開したその日にすべての言語の索引に載ります。

確認の仕方

for p in "" /ja /de; do curl -s -o /dev/null -w "$p/llms.txt %{http_code} %{content_type}\n" "https://example.com$p/llms.txt"; done
curl -s https://example.com/ja/llms.txt | head -3
curl -sI https://example.com/ja/guides/wordpress | grep -i 'rel="describedby"'

各ロケールが text 系の型で 200 を返すこと、各ファイルの冒頭がそのロケールの言語であること、ローカライズ済みページがローカライズ済みの索引を指していることを確認します。そのあと各ロケールのファイルを別々にバリデータに通します。ルートが有効でも、他のファイルについては何も分かりません。

言語ごとの llms.txt を検証する

example.com/ja のようにロケールの URL を貼ると、そのパスの llms.txt を取得して仕様に沿った構造かを確認し、見つかったリンクをすべて一覧にします。

バリデータを開く →

よくある質問

llms.txt の仕様は言語について何か決めていますか？

いいえ。v2 の仕様はファイルの形を定め、ルートでも任意のサブパスでも置けること、ファイルはそのパス配下の URL を扱うこと、複数ある場合はエージェントが最も具体的なものを使うことを述べています。言語、ロケール、翻訳という言葉は一度も出てきません。この記事の内容はすべて、そのサブパスの規則と、検索エンジン向けにすでにある hreflang の仕組みの上に組んだ慣習です。

全言語を 1 本の llms.txt にまとめてはだめですか？

できますが、読みにくくなります。英語、日本語、ドイツ語のセクションが交互に並ぶファイルは、必要な言語を見つけるためにアシスタントに全言語分のコストを払わせますし、引用ブロックの要約はどれか 1 つの言語でしか書けません。1 ファイル 1 言語にします。サイトの大半が 1 言語で、翻訳ページが数枚しかないなら、その言語の 1 本に短い「他の言語」セクションを付ければ十分です。

言語別のファイルはどこに置けばよいですか？

ページと同じプレフィックスです。日本語ページが /ja/ 配下なら /ja/llms.txt、ja.example.com にあるなら ja.example.com/llms.txt を公開します。「ファイルはそのパス配下の URL を扱う」という仕様の規則がこれを成り立たせます。/ja/getting-started を取得したエージェントが最も近い llms.txt を探すと、日本語のファイルが見つかります。

hreflang とはどう関係しますか？

hreflang は検索エンジンに「どのページがどのページの翻訳か」を伝えるもので、各言語版が自分自身と他のすべての言語版を列挙する決まりがあります。llms.txt にはその仕組みがなく、必要でもありません。役割は 1 つの言語のページをよく説明することです。2 つを整合させるには、hreflang で x-default にしている言語をルートの llms.txt の言語にし、各ローカライズ済みページから自分のロケールのファイルを rel=describedby で指します。

ルートの llms.txt を Accept-Language で訪問者の言語にして返すべきですか？

いいえ。クローラーやキャッシュは Accept-Language を確実には送らず、尊重もしません。リクエストヘッダで中身が変わるファイルは検証しにくく、誤ったキャッシュも起きやすいです。ルートは既定のロケールの 1 言語に固定し、他の言語にはそれぞれ固定の URL を与えます。

次に読む

→ llms.txt の仕様を 1 行ずつ読む（サブパスの規則と rel=describedby を仕様の言葉で）
→ Next.js / Astro / Hugo で llms.txt をビルド時に生成する（このサイトがロケールごとに使っているルートハンドラの型）
→ llms.txt の Optional セクションには何を書くか
→ 解説記事の一覧へ戻る