--- title: "llms.txtとは？役割・書き方・SEO効果とWordPressで導入する前の考え方" canonical_url: "https://olein-design.com/blog/llms-txt-current-status-wordpress" language: "ja" date_published: "2026-07-28T10:17:40+09:00" date_modified: "2026-07-31T09:44:09+09:00" content_type: "post" author: "久野晃司" description: "AIやLLM向けの案内ファイルとして提案されているllms.txtについて、基本的な役割、robots.txtやsitemap.xmlとの違い、Markdown版ページ、Google検索での扱い、WordPressサイトへの導入判断を整理します。" taxonomies: category: - "備忘録" post_tag: - "llms.txt" --- # 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の公式提案](https://llmstxt.org/)では、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/): 関連する記事の一覧 ``` [公式提案のフォーマット](https://llmstxt.org/#format)では、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`](https://developers.google.com/search/docs/crawling-indexing/robots/intro?hl=ja) は、主にクローラーへクロールに関する指示を伝え、クロールのトラフィックを管理するために使われます。ただし、すべてのクローラーに動作を強制する仕組みではなく、ページを非公開にするセキュリティ機能でもありません。 [`sitemap.xml`](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview?hl=ja) は、検索エンジンに重要だと考えるページやファイル、その関係、最終更新日などの付加情報を伝えるためのものです。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](https://developers.cloudflare.com/fundamentals/reference/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のドキュメントに掲載された計測例](https://developers.cloudflare.com/style-guide/how-we-docs/ai-consumability/#saving-on-tokens)では、HTMLで15,229トークンだったページがMarkdownでは2,110トークンになっています。すべてのページで同じ割合になるわけではありませんが、少なくともこの事例では、AIへ渡す情報量を減らせることが確認できます。 ## llms.txt は SEO や Google の AI 検索に効果があるのか ここは、現在の `llms.txt` を考えるうえで特に重要な部分です。 Googleは2026年6月15日、`llms.txt` に関するガイダンスを明確にしました。 [Google検索の生成AI機能向け最適化ガイド](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide?hl=ja)では、**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の説明](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt?hl=ja)では、`llms.txt` をLLMやAIエージェント向けの機械可読な概要を提供する「新しい規約」としています。 ただし、`llms.txt` が存在しない場合は監査結果が「該当なし（N/A）」になります。現時点では提供が任意であり、存在しないことがエラーになるわけではありません。 これは、Googleの中で説明が矛盾しているというより、対象としている用途が異なります。 - Google検索：検索結果や生成AI検索での表示・ランキング - Chrome LighthouseのAgentic Browsing監査：AIエージェントがサイトを発見・操作しやすいかの確認 検索順位のためには使わなくても、AIエージェントがウェブサイトを利用する場面では役立つ可能性がある、という整理になります。 なお、[LighthouseのAgentic Browsingカテゴリ](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring?hl=ja)自体も、提案段階の技術を含む試験運用です。執筆時点では、このカテゴリのテストにChrome 150以降が必要と案内されています。**監査に追加されたことだけを根拠に、すべてのサイトで必須になったと考える必要はありません。** ## 実際の導入例として分かりやすいCloudflare `llms.txt` には、実運用されている事例もあります。そのひとつとして分かりやすいのがCloudflareです。 Cloudflareの開発者向けドキュメントでは、次の仕組みが実際に提供されています。 - サービスごとのドキュメントをまとめた `llms.txt` - ドキュメント全文をまとめた `llms-full.txt` - 各ページの `/index.md` - `Accept: text/markdown` によるMarkdownレスポンス - HTML版とMarkdown版のトークン数を示すレスポンスヘッダー [CloudflareのAI consumabilityに関する説明](https://developers.cloudflare.com/style-guide/how-we-docs/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](https://developer.wordpress.org/reference/functions/add_rewrite_rule/)を使えば、たとえば次のような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以外のさまざまなファイルも検出、クロール、インデックス登録する場合がある](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide?hl=ja)と説明しています。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（公式提案）](https://llmstxt.org/) - [Google検索の生成AI機能向けに最適化するためのGoogleのガイド](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide?hl=ja) - [Google検索セントラル ドキュメントの更新履歴](https://developers.google.com/search/updates?hl=ja) - [Google検索セントラル：robots.txtの概要](https://developers.google.com/search/docs/crawling-indexing/robots/intro?hl=ja) - [Google検索セントラル：サイトマップについて](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview?hl=ja) - [Chrome for Developers：llms.txt](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt?hl=ja) - [Chrome for Developers：Lighthouse Agentic Browsingのスコアリング](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring?hl=ja) - [Cloudflare Style Guide：AI consumability](https://developers.cloudflare.com/style-guide/how-we-docs/ai-consumability/) - [Cloudflare：Markdown for Agents](https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/) - [WordPress Developer Resources：add_rewrite_rule()](https://developer.wordpress.org/reference/functions/add_rewrite_rule/)