llms.txtとは？役割・書き方・SEO効果とWordPressで導入する前の考え方

AIにウェブサイトの内容を伝える方法として、llms.txt というファイルを目にする機会が増えてきました。

「これからは llms.txt が必要になる」「設置するとAI検索で引用されやすくなる」といった説明を見かけることもあります。しかし、現時点では、そこまで単純に判断できるものではありません。

先に結論をお伝えすると、2026年7月28日時点の llms.txt は、Google検索やAI検索での表示・順位を改善する効果が確認された施策ではありません。一方で、AIエージェントがサイトの構造を把握したり、必要な情報を効率よく取得したりするための案内としては、実用例が出てきています。

つまり、llms.txt を「新しいSEO対策」として見るのか、「AIが利用しやすいウェブサイトを作るためのインターフェース」として見るのかで、評価が大きく変わります。

この記事では、llms.txt の基本的な役割から、Markdown版ページとの関係、Google検索での扱い、WordPressサイトに導入する場合の考え方まで、現時点で確認できる情報をもとに整理します。

この記事は2026年7月28日時点の公式情報をもとにしています。llms.txt やAIエージェントを取り巻く状況は変化が速いため、導入時には各サービスの最新情報もご確認ください。

llms.txtとは

llms.txt は、ウェブサイトの概要や重要なページへのリンクを、LLM（大規模言語モデル）やAIエージェントが読み取りやすい形で提供するために提案されているMarkdown形式のファイルです。

基本的には、次のようにウェブサイトのルートに置きます。

https://example.com/llms.txt

Googleの公式資料では LLMS.txt と大文字で表記される場合もありますが、提案されているパスとファイル名は小文字の /llms.txt です。この記事でも、ファイル名に合わせて小文字で表記します。

この仕組みは、Jeremy Howard 氏によって2024年9月3日に提案されました。llms.txtの公式提案では、LLMが推論時にウェブサイトの情報を利用しやすくすることが目的として示されています。

通常のウェブページには、本文だけでなく、ナビゲーション、広告、JavaScript、関連記事、フッターなど、さまざまな情報が含まれています。人がブラウザで見るためには必要なものでも、AIがサイトの概要や重要な情報を短時間で把握したい場合には、処理する情報量が増える原因になります。

そこで、llms.txt に次のような情報をまとめておきます。

• このサイトは何を扱っているのか
• サイトを理解するうえで重要な前提
• 優先して参照してほしいページ
• ドキュメントやFAQなどの分類
• 必要に応じて参照すればよい補助情報

イメージとしては、AIに向けて「このサイトを調べるなら、まずこの案内を見てください」と伝えるための地図に近いでしょう。

ただし、llms.txt は正式なウェブ標準として確立したものではありません。提案元でも「proposal」と表現され、仕様はコミュニティからの意見を受け付けている段階です。2026年7月時点では、実装例はあるものの、対応状況がサービスごとに異なる新しい規約と捉えるのが適切です。

llms.txtの基本的な書き方

llms.txt はMarkdownで記述します。提案されている基本構造は、次のようなものです。

# サイト名

> サイトの概要や、理解するために重要な情報

必要に応じて、サイトに関する補足説明を書きます。

## サービス

- [サービス紹介](https://example.com/service/): 提供しているサービスの概要
- [料金](https://example.com/price/): 料金と契約条件

## サポート

- [よくある質問](https://example.com/faq/): 利用前によくある質問
- [お問い合わせ](https://example.com/contact/): 相談や問い合わせの窓口

## Optional

- [ブログ](https://example.com/blog/): 関連する記事の一覧

公式提案のフォーマットでは、H1のタイトルだけが必須です。それ以外の概要、説明文、H2ごとのリンク一覧は、サイトに合わせて追加できます。

Optional という見出しには特別な意味があります。コンテキストを短くする必要がある場合に、省略してもよい補助的な情報を置くためのセクションです。

重要なのは、URLを大量に並べることではありません。

どのページが重要なのか、リンク先に何が書かれているのかを短く説明し、AIだけでなく人が見てもサイトの構造を理解できる内容にしておくことが大切です。

robots.txtやsitemap.xmlとの違い

llms.txt は、robots.txt や sitemap.xml と名前や設置場所が似ています。ただし、それぞれの目的は異なります。

ファイル	主な目的	主な内容
robots.txt	クローラーにクロールしてよい範囲の指示を伝える	Allow、Disallow など
sitemap.xml	検索エンジンに重要なURLや付加情報を伝える	URL、最終更新日など
llms.txt	LLMやAIエージェントにサイトの概要と重要な情報を伝える	サイト説明、分類されたリンク、補足

robots.txt は、主にクローラーへクロールに関する指示を伝え、クロールのトラフィックを管理するために使われます。ただし、すべてのクローラーに動作を強制する仕組みではなく、ページを非公開にするセキュリティ機能でもありません。

sitemap.xml は、検索エンジンに重要だと考えるページやファイル、その関係、最終更新日などの付加情報を伝えるためのものです。URLの発見を助けますが、掲載したURLのクロールやインデックス登録を保証するものではありません。

一方、llms.txt は「どの情報が重要なのか」「サイトをどのように理解してほしいのか」という文脈を添えた案内です。

そのため、llms.txt を設置しても、AIクローラーのアクセスを許可したり拒否したりすることはできません。また、AIによる学習を拒否するためのファイルでもありません。

この3つは置き換え関係ではなく、必要に応じて異なる目的で共存するものです。

Markdown版ページもあわせて提案されている

llms.txt の提案には、サイト全体の案内ファイルだけでなく、各ページの本文をクリーンなMarkdownで提供する考え方も含まれています。

たとえば、通常のページが次のURLにあるとします。

https://example.com/docs/getting-started.html

この場合は、元のURLに .md を追加します。

https://example.com/docs/getting-started.html.md

ファイル名のないURLについては、index.html.md を追加する形が提案されています。

https://example.com/blog/example/

↓

https://example.com/blog/example/index.html.md

つまり、役割を分けると次のようになります。

/llms.txt
    └ サイトの概要と重要ページへの案内

/blog/example/index.html.md
    └ 個別ページ本文のMarkdown版

llms.txt だけでも提案の最低限の形は作れます。さらに、リンク先にMarkdown版が用意され、対応するAIエージェントやツールがそれを取得する場合は、HTMLから本文を抽出する処理を減らせます。

ただし、Markdown版ページのURLは実装によって違いがあります。提案元は index.html.md を示していますが、Cloudflareの開発者向けドキュメントでは、各ページの末尾に /index.md を付ける方法も採用されています。

ここは「どのURL形式が唯一正しいか」よりも、AIやツールが安定して取得でき、元のページとの関係が分かりやすく、継続して更新できる設計になっているかを考えたいところです。

Markdownで提供することには技術的な意味がある

個人的には、現時点では llms.txt そのものよりも、ページ本文をMarkdownで取得できることの方が、技術的なメリットを説明しやすいと感じています。

HTMLには、サイトの見た目や操作に必要な情報も含まれています。

• ヘッダーやフッター
• グローバルナビゲーション
• JavaScriptやCSSの参照
• パンくずリスト
• 関連記事
• 広告や計測用のコード
• タブや折りたたみ表示のためのマークアップ

AIが本文を利用したい場合、これらを解析して必要な部分だけを取り出さなければなりません。Markdown版をサイト側から提供できれば、見出し、文章、リスト、コードなどを比較的簡潔な構造で渡せます。

Cloudflareは、機能が有効になっているサイトに Accept: text/markdown を付けてリクエストすると、HTMLを動的にMarkdownへ変換する「Markdown for Agents」を提供しています。

curl https://developers.cloudflare.com/docs-for-agents/ \
  -H "Accept: text/markdown"

この仕組みでは、レスポンスの Content-Type が text/markdown; charset=utf-8 になり、HTML版とMarkdown版をキャッシュで分けるために Vary: Accept も付与されます。

Cloudflareのドキュメントに掲載された計測例では、HTMLで15,229トークンだったページがMarkdownでは2,110トークンになっています。すべてのページで同じ割合になるわけではありませんが、少なくともこの事例では、AIへ渡す情報量を減らせることが確認できます。

llms.txt は SEO や Google の AI 検索に効果があるのか

ここは、現在の llms.txt を考えるうえで特に重要な部分です。

Googleは2026年6月15日、llms.txt に関するガイダンスを明確にしました。

Google検索の生成AI機能向け最適化ガイドでは、Google検索（生成AI機能を含む）に表示されるために、llms.txt のような新しい機械可読ファイルやAI向けテキスト、特別なMarkdownを作成する必要はなく、Google検索自体はそれらを使用しないと説明しています。

さらに、Google検索での表示やランキングに、プラスにもマイナスにも影響しないことが明記されています。

したがって、少なくともGoogleについては、次のような効果を期待して導入する根拠はありません。

• 通常の検索順位が上がる
• AIによる概要に引用されやすくなる
• AIモードで表示されやすくなる
• llms.txt が新しいランキング要因になる

Google検索での可視性を考えるのであれば、llms.txt より先に、クロール可能な状態、分かりやすい内部リンク、重要な情報をテキストで提供すること、内容と一致した構造化データ、独自性と信頼性のあるコンテンツなど、基本的な取り組みを優先する必要があります。

llms.txt を設置すること自体が問題になるわけではありません。Googleも、ほかのサービスやシステムのために維持することは問題ないと説明しています。ただし、SEOやGEOの効果を約束する施策として扱うのは避けた方が良いでしょう。

Google検索は使わないが、Chrome Lighthouseは確認している

少し分かりにくいのが、Google検索は llms.txt を使用しない一方で、ChromeのLighthouseには llms.txt の監査が追加されている点です。

Chrome for Developersの説明では、llms.txt をLLMやAIエージェント向けの機械可読な概要を提供する「新しい規約」としています。

ただし、llms.txt が存在しない場合は監査結果が「該当なし（N/A）」になります。現時点では提供が任意であり、存在しないことがエラーになるわけではありません。

これは、Googleの中で説明が矛盾しているというより、対象としている用途が異なります。

• Google検索：検索結果や生成AI検索での表示・ランキング
• Chrome LighthouseのAgentic Browsing監査：AIエージェントがサイトを発見・操作しやすいかの確認

検索順位のためには使わなくても、AIエージェントがウェブサイトを利用する場面では役立つ可能性がある、という整理になります。

なお、LighthouseのAgentic Browsingカテゴリ自体も、提案段階の技術を含む試験運用です。執筆時点では、このカテゴリのテストにChrome 150以降が必要と案内されています。監査に追加されたことだけを根拠に、すべてのサイトで必須になったと考える必要はありません。

実際の導入例として分かりやすいCloudflare

llms.txt には、実運用されている事例もあります。そのひとつとして分かりやすいのがCloudflareです。

Cloudflareの開発者向けドキュメントでは、次の仕組みが実際に提供されています。

• サービスごとのドキュメントをまとめた llms.txt
• ドキュメント全文をまとめた llms-full.txt
• 各ページの /index.md
• Accept: text/markdown によるMarkdownレスポンス
• HTML版とMarkdown版のトークン数を示すレスポンスヘッダー

CloudflareのAI consumabilityに関する説明では、llms-full.txt の用途として、オフラインでのインデックス作成、まとめてベクトル化する処理、大きなコンテキストを扱えるモデルでの利用などが挙げられています。

なお、llms-full.txt はCloudflareなどが提供している全文版の実装例であり、llms.txt の公式提案で必須とされているファイルではありません。llms.txt と同じ仕様上の必須要素だと混同しないようにしたいところです。

この事例を見ると、llms.txt とMarkdown版ページは、不特定多数のAI検索で上位表示を狙うためのものというより、開発者やAIエージェントが大量のドキュメントを効率よく扱う場面で価値を発揮しやすいことが分かります。

現時点で、何に対して有効なのか

ここまでを目的別に整理すると、次のように考えられます。

目的	現時点での評価	理由
Googleの検索順位を上げる	期待できない	Googleが使用せず、表示やランキングにも影響しないと明記
Googleの生成AI検索に引用されやすくする	期待できない	AIによる概要やAIモードを含めて、特別なファイルは不要
AIサービスに自動発見してもらう	対応状況による	処理方法は提案仕様で定められておらず、サービスやツールごとに異なる
AIエージェントにサイトの概要を伝える	条件付きで有用	対応するエージェントやツールが取得すれば、案内として利用できる
HTMLより簡潔な本文を提供する	有用性が分かりやすい	解析処理やトークン量を減らせる場合がある
大規模な技術文書やナレッジベースを提供する	相性が良い	索引、分類、Markdown本文をまとめて提供しやすい
将来に備えて低コストで試す	条件付きで合理的	自動生成と更新の仕組みを作れるなら維持負担を抑えられる

大切なのは、「llms.txt は効果があるか」という一問だけで判断しないことです。

何に対する効果を期待するのか、誰がそのファイルを利用するのか、導入後に内容を更新し続けられるのかまで分けて考える必要があります。

導入を検討しやすいサイト

llms.txt やMarkdown版ページは、情報量が多く、情報の分類がはっきりしているサイトと相性が良いと考えられます。

たとえば、次のようなサイトです。

• 開発者向けドキュメント
• APIリファレンス
• 製品マニュアル
• FAQやナレッジベース
• 技術ブログ
• 多数の専門記事を持つメディア
• AIエージェントから参照されることを想定したサービス

ページ数が多いサイトでは、対応するAIエージェントが llms.txt から目的に近いセクションを見つけ、Markdown版の本文を取得できれば、すべてのURLを順番に探索するより効率的に情報を絞り込める可能性があります。

一方で、会社概要、サービス紹介、お問い合わせなど、少数のページで構成される事業サイトでは、優先順位はそれほど高くないでしょう。

まずは、次のような基本的な状態を整える方が、利用者、検索エンジン、AIエージェントのいずれに対しても役立ちます。

• ページのタイトルと見出しが内容に合っている
• サービス内容や料金、対象者が文章で説明されている
• 重要なページへ内部リンクで移動できる
• 古い情報や矛盾した説明が残っていない
• 画像の中だけに重要な情報を書いていない
• HTMLが意味に沿って構造化されている
• sitemap.xml や robots.txt が適切に設定されている

llms.txt がなくても、元のサイトが分かりやすく整理されていれば、さまざまな仕組みから利用しやすくなります。反対に、元の情報が古かったり矛盾していたりする状態で llms.txt だけを追加しても、問題の根本的な解決にはなりません。

WordPressでは物理ファイルを置かなくてもよい

WordPressで llms.txt やMarkdown版ページを提供する場合、すべてのファイルをあらかじめ生成し、サーバー内に保存しておく必要はありません。提案仕様はURLから取得できる内容を示していますが、その生成方法までは定めていません。

WordPressはURLへのアクセスを受けて、その時点の投稿や固定ページの情報からレスポンスを作れます。WordPressのRewrite APIを使えば、たとえば次のようなURLをWordPressで処理できます。

/llms.txt
/blog/example/index.html.md

仕組みとしては、次のような流れです。

Markdown版URLへアクセス
    ↓
WordPressがリクエストを判定
    ↓
対象の投稿・固定ページを取得
    ↓
本文をMarkdownへ変換
    ↓
text/markdownとして返す

つまり、.md は必ずしもサーバー上に置かれた物理ファイルではなく、同じコンテンツを別の形式で表現するためのURLとして実装できます。

ただし、.txt や .md で終わるURLがWordPressへ渡されるかどうかは、ウェブサーバーやCDNの設定にも左右されます。Rewrite APIだけで完結するとは限らず、環境によってはサーバー側のルーティングやキャッシュ設定の調整も必要です。

動的に生成すれば、記事を更新した内容がMarkdown版にも反映されやすくなります。ただし、アクセスのたびに変換すると処理が増えるため、実運用ではキャッシュも検討したいところです。

Markdown版へアクセス
    ↓
キャッシュを確認
    ├ あり：保存済みの内容を返す
    └ なし：生成して保存してから返す

投稿の更新時に該当するキャッシュを削除する設計にすれば、更新への追従と表示速度を両立しやすくなります。

静的ファイルとして生成する方法にも、WordPressを通さず配信できるメリットがあります。動的生成と静的生成のどちらが良いかは、ページ数、更新頻度、サーバー構成、キャッシュ環境によって変わります。

WordPressで導入するなら段階的に考える

WordPressサイトで試すのであれば、最初からすべての投稿をMarkdown化する必要はないと思います。

1. 元のコンテンツを整理する

まず、サイト説明、サービス内容、運営者情報、FAQ、主要記事など、AIに限らず利用者にとって重要な情報を確認します。

古い記事や内容の重複が多い場合は、llms.txt を作る前に整理した方が良いでしょう。

2. 小さなllms.txtを作る

最初は、サイト概要と重要なページだけを載せた小さな llms.txt で十分です。

すべての記事を自動で並べると、sitemap.xml と役割が変わらなくなってしまいます。主要なページを選び、短い説明を添えることに意味があります。

3. 必要なページだけMarkdown版を提供する

FAQ、技術資料、詳しいサービス説明など、AIエージェントから参照される可能性が高いページから試します。

HTMLからMarkdownへ変換した結果に、ナビゲーションや不要なショートコードが混ざっていないか、人が実際に取得して確認することも必要です。

4. 更新とアクセスを確認する

記事を修正したときに、llms.txt とMarkdown版が更新されるかを確認します。

また、サーバーのアクセスログを確認できるのであれば、どのクローラーやツールが llms.txt やMarkdown版へアクセスしているかを見ることで、自分のサイトで本当に利用されているかを判断できます。

効果が分からないまま作り続けるより、維持コストと実際の利用状況を見ながら範囲を調整する方が現実的です。

導入前に確認したい注意点

llms.txt やMarkdown版ページは、設置するだけで終わるものではありません。運用では、次の点に注意が必要です。

公開してよい情報だけを載せる

アクセス制限を設けず、通常の公開URLとして提供すれば、人でもBotでも取得できます。Markdown版は「AIだけが読める非公開形式」ではありません。

会員限定の記事、社内資料、下書き、個人情報、購入者だけに提供しているコンテンツなどが誤って含まれないようにしてください。

WordPressで自動生成する場合は、公開済みの投稿だけを対象にすることに加え、パスワード保護、閲覧権限、カスタム投稿タイプごとの公開条件も確認する必要があります。

また、GoogleはHTML以外のさまざまなファイルも検出、クロール、インデックス登録する場合があると説明しています。Markdown版を別URLで公開するなら、AI専用だから検索エンジンには見つからないと決めつけず、検索対象として扱いたいURLなのかも含めて設計する必要があります。

robots.txtの代わりにはならない

llms.txt にリンクを載せなかったからといって、そのページへのアクセスを拒否できるわけではありません。

クローラーへのクロール指示、検索結果への表示制御、認証によるアクセス制限、AI学習やAIサービスでの利用に関する設定は、それぞれ役割が異なります。対象となるBotやサービスの公式情報を確認し、別々に考える必要があります。

HTML版と内容を同期する

HTML版は更新されているのに、Markdown版や llms.txt だけが古い状態になると、異なる説明を提供することになります。

手作業で更新する場合は確認手順を決め、自動生成する場合は公開・更新・削除に追従できる仕組みを用意したいところです。

変換結果を確認する

WordPressの本文には、ブロック、ショートコード、埋め込み、フォーム、表、独自プラグインの出力などが含まれる場合があります。

単純にHTMLタグを削除するだけでは、見出しの関係が崩れたり、リンク先が分からなくなったり、操作できない文字列だけが残ったりすることもあります。

Markdownとして取得できるだけでなく、内容が正しく伝わるかまで確認する必要があります。

キャッシュとレスポンスを設計する

Markdown版を別URLで提供する場合は Content-Type、キャッシュ、有効期限、エラー時のステータスコードなどを確認します。

同じURLで Accept: text/markdown に応じて内容を切り替える場合は、HTML版とMarkdown版がキャッシュで混ざらないよう、Vary: Accept を含めた配信設計が必要です。

自分で確認できること

専門的な実装を始める前に、サイト運営者自身でも次の点は確認できます。

• https://自分のドメイン/llms.txt に現在何が表示されるか
• 既存のプラグインやサービスが自動生成していないか
• llms.txt に掲載したい重要ページはどれか
• 各ページの情報が最新になっているか
• 公開してはいけないページが混ざっていないか
• Google検索の順位向上だけを目的にしていないか
• 導入後に誰が内容を更新するか

llms.txt が404になっていても、現時点ではそれだけでサイトに問題があるわけではありません。まずは、自分のサイトにとって利用場面があるかを考えてみてください。

制作会社や専門家に相談した方がよい状態

次のような場合は、WordPressやサーバーの構成を確認できる制作会社・開発者へ相談した方が安全です。

• 投稿や固定ページから llms.txt を自動生成したい
• ページごとにMarkdown版を動的配信したい
• 会員限定コンテンツや複雑な閲覧権限がある
• 多言語サイトや複数のカスタム投稿タイプを使っている
• CDNやページキャッシュを利用している
• HTMLからMarkdownへの変換結果に崩れがある
• アクセスログを使って利用状況を検証したい
• 現在のSEOやクローラー制御との関係を整理したい

相談する際には、対象サイトのURL、利用中のWordPressテーマ・主要プラグイン、キャッシュやCDNの有無、Markdown化したい投稿タイプ、公開対象から除外したい情報をまとめておくと話が進めやすくなります。

まとめ

llms.txt は、ウェブサイトの概要と重要なページを、LLMやAIエージェントへ伝えるために提案されているMarkdown形式の案内ファイルです。

2026年7月28日時点では正式なウェブ標準として確立したものではなく、提案元でも処理方法はアプリケーション次第とされています。Google検索は llms.txt を利用せず、通常の検索や生成AI機能での表示、ランキングにも影響しないと明記しています。

一方で、Chrome LighthouseはAIエージェント向けの任意の監査項目として扱い、Cloudflareは llms.txt、llms-full.txt、ページ単位のMarkdown版を実際のドキュメント配信に利用しています。

現時点では、llms.txt を「AI検索で上位表示するためのファイル」と考えるより、AIエージェントがサイトを効率よく利用するための案内として捉える方が自然です。

特に、開発ドキュメント、FAQ、ナレッジベース、技術ブログなどでは検討する価値があります。小規模な事業サイトでは、まず元のページ構成、文章、内部リンク、情報の鮮度を整える方が優先度は高いでしょう。

WordPressであれば動的生成やキャッシュを使って、維持コストを抑えながら試すこともできます。ただし、公開範囲、更新同期、変換結果、キャッシュなど、運用まで含めた設計が必要です。

流行しているから急いで設置するのではなく、自分のサイトでは誰が、どの情報を、どのように利用するのかを考える材料になれば嬉しいです。

参考資料

• The /llms.txt file（公式提案）
• Google検索の生成AI機能向けに最適化するためのGoogleのガイド
• Google検索セントラル ドキュメントの更新履歴
• Google検索セントラル：robots.txtの概要
• Google検索セントラル：サイトマップについて
• Chrome for Developers：llms.txt
• Chrome for Developers：Lighthouse Agentic Browsingのスコアリング
• Cloudflare Style Guide：AI consumability
• Cloudflare：Markdown for Agents
• WordPress Developer Resources：add_rewrite_rule()