llms.txtのベストプラクティス: 10のルールとよくある間違い

10のルール

キュレーションする。 価値の高い少数のページは、質の低いページを長く並べるより有効です。10～30リンクは出発点の目安になりますが、件数は想定タスクに基づいて決めてください。
絶対URLを使用する。 常に https://yourdomain.com/...。相対URLは技術的には許可されているが、不安定である。
プロダクトの表面ごとにグループ化します。 。製品, 料金, 開発者向け ユーザー（および LLM）の考え方を反映させます。ブログ／ドキュメント／ガイドという分類が実際のナビゲーションに対応していない限り、そのような分類は避けてください。
要約は事実に基づいて記述してください。 H1の後の引用ブロックは、ランディングページのヒーロー文ではなく、Wikipediaの冒頭文のように記述してください。
項目ごとに1文にする。 コロンで始まる注記は、マーケティングではなく区別のためのものです。
マーケティング目的で使います。 Optional ラベルは控えめに使用してください。 。プレス、ブランドアセット、アーカイブの明確な編集上の置き場所になりますが、v2では特別な機械的意味はありません。
安定したURLを反映する。 ページが llms.txt 移動、更新、またはリダイレクトを行わないでください。古いURLはファイルの評判を損ないます。
公開 llms-full.txt 定義された取り込み要件にのみ適用されます。 。統合されたドキュメントは既知の利用者に役立ち得ますが、サイズ、鮮度、セキュリティのコストも増加します。
実行しますバリデーター CI内。 ファイルを壊すコンテンツ移行では、ビルドを失敗させる必要があります。
ファイルに日付を記載する。 次のような短い注記： 「2026-04-01 に最終確認」 を本文に入れると、人にもクローラーにも役立ちます。

よくある間違い

H1がない。 H1要素のみが必須です。これが欠けている場合、ファイルは無効となります。
H1 が複数あります。 セクションにはH2を使用してください。H1は必ず1つだけにします。
カスタム・フロントマター。 YAMLおよびJSONヘッダーは公開仕様の文法外にあり、準拠パーサーがファイルを拒否したり誤読したりする原因になります。
貼り付けられた Markdown の表や画像。 前文は要点に絞り、H2セクション内ではリンクリストを使用してください。余分な構造は解析の曖昧さを増し、多くの場合リンク先ページの内容と重複します。
認証が必要なURLを含みます。 ページにログインが必要なら掲載しないでください。LLMがそこで行き詰まります。
長すぎる説明。 「次世代の相乗的変革を実現する、世界最先端のAI搭載プラットフォーム」と書いても、誰の役にも立ちません。各注記は、リンク先を区別するのに必要な長さにとどめてください。
範囲を示さずに500個のURLを列挙する。 タスクを再確認し、実際のコンテンツ境界に沿ってパス単位のファイルに分割するか、既知の利用者向けに全文を収録した別のリソースを提供してください。
意図せずにリソースをブロックしてしまうこと。 宣言された各ルートまたはパスレベルのファイルが、意図するクロールポリシー下で確実にアクセス可能であることを確認してください。

多言語サイト

この提案では、国際化アーキテクチャを1つに規定していません。一般的な設計は2つあります：

ルートに置くデフォルト言語のファイルを一つ。 。掲載するリソースと想定利用者が同じ言語を使用する場合に最も簡単な選択肢です。
ロケール別のバリエーション。 配信します。 /llms.txt （デフォルト）、 /fr/llms.txt, /es/llms.txt。ルートファイルの本文または任意セクション、または適用されるファイルを以下のように宣言する rel="describedby" をローカライズされたページに指定します。

どちらのパターンを選んでも、ロケール間でURL群を重複させないでください。各派生ファイルは、それぞれのページのローカライズ版を指す必要があります。

セキュリティとプライバシー

すべてを llms.txt は公開情報です。 このファイルは不特定多数への公開情報として扱ってください。
ステージング環境やプレビュー用のURLは決して記載しないでください。 公開ファイルを取得するクライアントはすべて閲覧できます。
クエリ文字列に秘密情報を含むURLを掲載しないでください。 これは当然のことのように思えますが、実際にそのような事例を目にしてきました。
ページが認証の背後でユーザーデータを公開するなら、ここに含めるべきではありません。
リリースのたびにファイルを監査してください。 下書き URL の漏えいは、最も一般的なセキュリティ上の誤りです。

このファイルは外部設定として扱い、エージェントがそれに従うと仮定してはならない。Ahrefsによる 137,210ドメインの分析において、調査対象カテゴリーで最も多かったユーザーエージェント文字列は prompt-injection-survey/1.0。そのラベルは攻撃や実行者のいずれをも証明しませんが、コンテンツを事実に即したものに保ち、変更を確認し、利用するエージェントを制約するための有用な注意喚起です。

CIにおける自動化

取り扱い llms.txt を他の成果物と同様に扱い、生成、検証し、リリース条件に組み込んでください。

コンテンツソース（CMS、MDXコレクション、データベース）から生成します。
実行しますバリデーター CI で実行し、エラーがあればビルドを失敗させます。
リリース間でファイルを比較し、大きな削除があればドキュメント担当者に知らせます。
デプロイ後に本番 URL をスモークテストします: curl -fsS https://yourdomain.com/llms.txt | head -1.

利点と制約、何を期待でき、何を期待できないかを説明します。
実際の例、うまくいく方法を取り入れます。
バリデータ.