跳到正文

llms.txt

速览要点

它是什么
Answer.AI 的 Jeremy Howard 于 2024 年 9 月提出的一项发布约定:在 /llms.txt 提供一份经过筛选并去除网页噪声的 Markdown 文件,说明 LLM 应优先阅读哪些页面。它只提示阅读优先级,不负责访问控制,也不帮助引擎发现内容
采用与读取要分开看
站点确实在采用,而且数量还在增加:文档平台会自动生成,抽样研究中约 10% 的域名已经部署。但 AI 引擎是否真的会读取它,至今没有得到证实;没有任何主流 AI 厂商在文档中说明会读取该文件
AI 厂商是否正式使用它
截至 2026 年 5 月,没有任何公开确认。OpenAI、Anthropic、Google、Perplexity 的爬虫文档都未提及 llms.txt;Google 的 John Mueller 将它类比为早期的 keywords meta 标签(Reddit,2025 年 4 月)
是行业标准吗
不是。这仍是一项处于提案阶段的约定,尚未获得 IETF/W3C 批准;目前由社区维护,详见 llms.txt 工作组
它在 GEO 中的作用
它改善的是内容被采用之前的可读性和可检索性,不会直接提高可引用性。它适合以低成本预先部署,将来仍可沿用,不是今天就能带来引用的 GEO 手段

1. llms.txt 是什么:一项发布约定,不是访问控制

llms.txt 是放在站点根目录的 Markdown 文件(/llms.txt),由 Answer.AI 的 Jeremy Howard 于 2024 年 9 月提出(见 原始提案)。

GEO Wiki 工作定义:llms.txt 是一项尚处于提案阶段的发布约定。它用一份经过筛选并去除网页噪声的 Markdown 文件,告诉 LLM 应优先阅读哪些页面、去哪里获取干净文本。它让页面更易读取(减少 HTML 噪声,并在上下文窗口有限时节省空间),既不控制访问,也不帮助引擎发现内容。

提案将其表述为:「一个 Markdown 文件,提供简要背景和说明,并列出更多详细 Markdown 文件的链接」(见 Answer.AI)。

相关主题与对应条目如下:

议题详见
文件格式,以及发布端与读取端的实际采用情况本条目下文
怎么做:按 CMS/技术栈生成文件并保持更新部署 llms.txt
谁在维护规范、标准化进展及采纳者名单llms.txt 工作组
制定访问策略(llms.txt 不负责这项工作)robots.txt
AI 爬虫的工作机制AI 爬虫

2. 站点采用 ≠ 引擎读取

站点发布了文件,不代表 AI 引擎会读取它;这和 面向 AI 的 Schema.org §2 所说的「标记不是信号」是同一个道理。如果把站点端(站点发布该文件)和引擎端(AI 引擎是否真的读取它)混为一谈,就容易产生错误预期。

站点端引擎端
含义站点发布 /llms.txtAI 引擎在抓取或推理时读取并使用它
状态已有站点采用,而且数量还在增加:文档平台会自动生成;一项覆盖 30 万域名的研究测得约 10% 的采纳率(Search Engine Journal,2025-11-20)尚未得到证实:没有任何主流厂商在文档中说明会读取第三方的 llms.txt
证据Mintlify 会自动生成并托管该文件;Anthropic、Google、Perplexity 也都在各自的文档站点提供了该文件OpenAI(bots 文档)、Anthropic、Perplexity、Google 的爬虫文档都未提及 llms.txt

厂商在自家站点发布 llms.txt,容易让人误以为其爬虫也会读取这类文件。Anthropic 为自己的开发者文档发布了 llms.txt,但 ClaudeBot 的公开爬虫文档从未说明它会读取这个文件。站点自行发布一份,不代表其爬虫会读取其他站点的文件。GPTBot 和 PerplexityBot 的文档也是如此,对 llms.txt 均无说明。

因此,现阶段只能把 llms.txt 当作一项低成本且向前兼容的预先部署,不能指望它直接带来引用。发布成本约等于零;目前能够确认的并不是 AI 厂商会读取它,而是任何愿意读取它的工具,现在都能以低成本获取一份经过筛选并去除网页噪声的内容清单。

还有一项值得重视的质疑,但不能直接当作定论:Google 搜索布道师 John Mueller 曾公开把 llms.txt 类比为早期的 keywords meta 标签,「没有任何 AI 服务说过它们在用 llms.txt,看服务器日志就知道,它们根本不会去查它」(Reddit,2025 年 4 月,经 Search Engine Journal 报道)。不过,这仍不足以否定 §7 提到的低成本使用价值。

3. 规范的文件格式

不同技术栈的具体生成方法见 部署 llms.txt;按照 llmstxt.org,llms.txt 的标准结构如下。

# 项目名称

> 一段简短的项目摘要(blockquote):读懂下文所需的关键信息。

零或多段自由说明文字(不带标题),用于补充上下文。

## Docs

- [快速开始](https://example.com/quickstart.md): 如何上手
- [API 参考](https://example.com/api.md): 完整端点列表

## Optional

- [更新日志](https://example.com/changelog.md): 上下文紧张时可跳过
元素是否必需用途
# H1 项目名是,唯一必需的元素说明文件对应的项目或实体
> blockquote 摘要建议提供简要说明阅读下文所需的关键信息
自由说明段落可选补充上下文,不带标题
## H2 链接列表小节可选;可设置多个经过筛选的链接列表,每条为 [名称](url): 备注
## Optional 小节可选优先级较低的链接,上下文窗口空间不足时 LLM 可以跳过(llmstxt.org)

llms.txt 与 llms-full.txt 并不相同,而且目前最常见的 llms-full.txt 这个名称其实不在规范中。官方提案定义的是两个经处理生成的扩展文件 llms-ctx.txt 和 llms-ctx-full.txt,由 llms_txt2ctx 工具从 llms.txt 生成(见 Answer.AI)。目前广泛部署的 llms-full.txt 会把所有文档正文合并成一个文件;这是 Mintlify 推广后形成的通行约定,并非原始规范(Mintlify,2024-11-20)。更准确地说,llms.txt 是一份经过筛选的内容索引;全量变体则是一份可以整段交给模型的正文合集,但也可能超出上下文窗口容量(见 §6)。

4. llms.txt、robots.txt 与 sitemap.xml:三个文件,三种职责

最常见的误解,就是把这三个根目录文件混为一谈。它们的职责并不重叠,彼此也不能替代。

文件主要用途不能做什么
robots.txt访问控制:机器人能否抓取某个路径(机制详见 robots.txt)不负责内容筛选、呈现或排名;这些规则表达访问要求,但不能强制爬虫遵守
sitemap.xml内容发现与完整覆盖:完整列出供索引的内容(Sitemap 与 IndexNow)不负责筛选,也不授予访问权;它不是精选清单
llms.txt内容筛选与简洁呈现:用一份去除网页噪声的 Markdown 文件,说明应优先阅读这些页面不授予或拒绝访问,不保证完整列出所有内容,也不是排名信号

所以,llms.txt 不是面向 AI 的 sitemap(否则会混淆内容筛选与完整覆盖),也不是面向 AI 的 robots.txt(否则会混淆阅读提示与访问规则)。抓取权限与访问规则见 robots.txt,相关的爬虫机制见 AI 爬虫;llms.txt 既不会允许,也不会阻止任何一次抓取。

5. llms.txt 能做什么、不能做什么

根据现有证据,llms.txt 的作用可以归纳如下。和 可引用性 §5、面向 AI 的 Schema.org §6 一样,以下结论都有证据支持,不作夸大。

llms.txt 能llms.txt 不能
提供一份经过筛选、去除网页噪声且占用 token 较少的阅读清单授予或拒绝爬虫访问(≠ robots.txt)
让自己能够控制的工具今天就能以低成本读取正确页面阻止训练,或保证抓取、索引、引用
以约等于零的成本先备好内容,供日后可能读取它的引擎使用供浏览器或终端用户读取
向任何愿意遵循这项约定的工具说明站点结构充当排名或引用信号
已知情况应如何理解
采用它的站点越来越多,文档平台会自动生成该文件这只能证明站点端确有采用,不能证明引擎端会读取;发布不等于会被读取
Anthropic、Google、Perplexity 都发布了 llms.txt这只说明它们在自家文档站点上托管了该文件;其爬虫文档并未说明会读取你的文件
一项覆盖 30 万域名的研究测得约 10% 的采纳率采纳确实存在,但研究没有发现它目前会影响引用(SEJ,2025-11-20)
一项为期 90 天、覆盖 10 个站点的研究跟踪了部署前后的 AI 流量研究建议把它当作类似 sitemap 的基础设施,而非增长手段(Search Engine Land,2026-01-20)

不同引擎对 llms.txt 的处理可能不同,具体见 ChatGPT Search、Perplexity AI、Claude。截至 2026 年 5 月,没有任何厂商在文档中说明会读取 llms.txt。

6. 常见误用:哪些做法会适得其反或没有效果

以下做法看似合理,实际却要么无效,要么适得其反。根源在于误解了文件的职责、没有保持内容最新,或忽视了 token 的使用效率。

常见误用为什么看起来合理实际问题
用 llms.txt 来「阻止 AI 训练我的站点」看到文件是为 AI 准备的这是最严重的职责混淆:它只提示阅读优先级,不负责访问控制;用于访问控制的文件是 robots.txt
期待发布 llms.txt 后就能被引用其他面向 AI 的文件会影响可见度引擎是否会读取它至今未获证实(§2);它只适合预先部署,以备未来使用,不能直接提高引用。内容能否被引用仍取决于页面本身(可引用性)
继续使用与线上站点脱节的陈旧 llms.txt文件发布时内容准确一份内容错误的精选清单比没有这份文件更糟,它会让愿意读取它的工具读取失效或过时的 URL
把整个 sitemap 塞进 llms.txt想尽量多列链接,覆盖更多内容这会失去筛选的意义;llms.txt 用于精选内容,sitemap.xml 才负责完整列出页面
llms-full.txt 内容多到超出上下文窗口,或塞满导航杂项希望把全部内容交给模型这会失去节省 token 的优势,而节省 token 正是这个文件的核心价值
本该由构建过程生成,却改成手工维护误以为文件很少变化这样很容易与站点实际内容脱节,正确做法见 部署 llms.txt

llms.txt 的价值完全取决于内容是否经过筛选并保持最新;未经筛选或无人维护的 llms.txt 弊大于利,它会让愿意读取该文件的工具访问错误页面,反而降低该文件在这些工具中的可信度。

7. 它对 GEO 的价值有多大

如 SEO vs GEO 所述,SEO 的现有基础仍然有效,llms.txt 只是一项尝试性补充;不应夸大它的实际价值。

发布 llms.txt 的合理之处,在于节省上下文窗口空间。一份经过筛选并去除网页噪声的内容清单,能降低任何会读取它的 LLM 工具处理站点内容时的成本,包括你自己的 RAG、AI 编码代理,以及愿意遵循这项约定的第三方工具。如果日后有厂商开始读取,现有文件也能继续使用。发布成本(尤其是自动生成时)约等于零,潜在损失也约等于零;未来若有引擎采用,也可以直接使用现有文件。

因此,llms.txt 在 GEO 中适合以低成本预先部署,不是直接带来引用的手段。发布它,是因为它成本低、将来仍可沿用,而不是因为它今天能带来引用;规模最大的两项实测都没有发现它会影响引用(SEJ,30 万域名;Search Engine Land,10 站点)。在内容处理流程中,llms.txt 先解决可读性/可检索性问题;页面被读取后能否被采用,则属于 可引用性问题。完整流程见 Answer Loop。

围绕这项约定的支持与质疑,与 生成式引擎优化 面临的讨论相似。支持者认为,这项约定虽要走很长的路,但不宜断言它不会成功(Search Engine Land,2025-03-28);§2 中的质疑者则指出 robots.txt 和 sitemap 已经覆盖了大部分需求。这两种判断并不冲突:llms.txt 值得以低成本部署,却不足以单独构成一套策略。

8. 如何使用与后续维护

需要完成的事相关条目或工具
根据线上站点生成初稿llms.txt 生成器
按技术栈生成并部署它部署 llms.txt
了解规范维护方式、采纳者名单与标准化进展llms.txt 工作组
制定访问策略(llms.txt 不负责访问控制)robots.txt
了解相关的爬虫机制AI 爬虫
查找用于内容发现与完整覆盖的文件Sitemap 与 IndexNow
确认某个具体引擎是否会读取它ChatGPT Search · Perplexity AI · Claude
了解页面被读取后能否获得引用可引用性
把这些工作纳入完整的 GEO 方法生成式引擎优化

如果能以低成本保持文件更新,就值得发布 llms.txt;访问策略应写入 robots.txt,内容能否获得引用仍取决于页面本身。llms.txt 只是站点主动提供的一份精选阅读清单,它既不能授予访问权,也不能直接使页面获得引用。

参考资料

提案与规范:

厂商爬虫文档(截至 2026-05,均未说明会读取 llms.txt):

站点发布情况与文件变体:

质疑与独立测试:

综合分析:

常见问题

发布 llms.txt 能让我的内容被 AI 引用吗?
现有证据表明,不能。没有任何公开信息确认主流 AI 引擎会读取 /llms.txt,规模最大的两项实测也都没有发现它会影响引用:覆盖 30 万域名的研究得出的结论是,它「似乎并不直接影响 AI 引用频次,至少目前还没有」;为期 90 天、覆盖 10 个站点的研究则建议把它当作类似 sitemap 的基础设施,而不是增长手段。内容能否获得引用,仍取决于页面本身。发布 llms.txt 的理由是成本低、向前兼容,而不是它能带来引用。
ChatGPT、Claude、Perplexity 或 Gemini 会读我的 llms.txt 吗?
截至 2026 年 5 月,没有任何厂商公开说明其爬虫或推理环节会读取第三方的 /llms.txt。OpenAI、Anthropic、Perplexity 和 Google 的官方爬虫文档都未提及它;Google 的 John Mueller 说,服务器日志显示这些 AI 服务「根本不会去查它」。不过,Anthropic、Google 和 Perplexity 都为自家文档发布了 llms.txt,容易让人误以为它们的爬虫也会读取这类文件。实际上,这只能说明它们在自己的站点上托管了该文件,不能证明它们的爬虫会读取你的文件。
llms.txt 是 robots.txt 或 sitemap.xml 的替代品吗?
不是。三个文件都放在根目录,但各有职责。robots.txt 负责访问控制,决定机器人能否抓取某个路径。sitemap.xml 帮助引擎发现内容,完整列出供索引的页面。llms.txt 负责筛选内容,以去除网页噪声的 Markdown 说明应优先阅读哪些页面。三者不能互相替代:llms.txt 既不是面向 AI 的 sitemap(否则会混淆内容筛选与完整覆盖),也不是面向 AI 的 robots.txt(否则会混淆阅读提示与访问规则)。
llms.txt 是官方标准吗?
不是。它由 Answer.AI 的 Jeremy Howard 于 2024 年 9 月提出,目前由社区非正式维护,未经 IETF 或 W3C 批准。规范托管在 llmstxt.org,社区登记处列出了采纳者。确实已有站点采用,但范围仍然有限:一项覆盖 30 万域名的研究发现,约 10% 的抽样域名部署了它。采用者虽然逐渐增多,但它仍处于提案阶段,还不是已经定型的标准。
那我还值得发布 llms.txt 吗?
值得,但要满足两个前提:成本足够低(最好由构建过程自动生成),而且文件能与线上站点保持同步。发布它,并不是因为已经有 AI 厂商承诺读取,而是因为它几乎没有成本,将来若有引擎开始读取,现有文件也能继续使用;它现在也能供你控制的工具使用,包括自有 RAG、AI 编码代理,以及愿意遵循这项约定的第三方工具。不过,文件必须经过筛选并保持最新。陈旧或未经筛选的 llms.txt 弊大于利,会让愿意读取它的工具访问错误页面,反而降低这些工具对该文件的信任。

延伸阅读

参考来源

一手来源

  1. The /llms.txt file — a proposal to provide information to help LLMs use websites · Answer.AI · 2024-09-03
  2. The /llms.txt file — specification · Answer.AI · 2024-09-03
  3. Overview of OpenAI Crawlers (GPTBot / OAI-SearchBot / ChatGPT-User) · OpenAI
  4. Does Anthropic crawl data from the web, and how can site owners block the crawler? · Anthropic · 2026-04-07
  5. Perplexity Crawlers (PerplexityBot / Perplexity-User) · Perplexity AI
  6. Overview of Google crawlers and fetchers (user agents) · Google Search Central · 2026-02-09
  7. Simplifying docs for AI with /llms.txt · Mintlify · 2024-11-20

二手来源

  1. Google Says LLMs.Txt Comparable To Keywords Meta Tag · Search Engine Journal
  2. llms.txt Shows No Clear Effect On AI Citations Based On 300K Domains · Search Engine Journal
  3. Does llms.txt matter? A 90-day study across 10 sites · Search Engine Land

三手来源[观察]

  1. Meet llms.txt, a proposed standard for AI website content crawling
首次发布: 2026-05-19 最近更新: 2026-08-17 作者: Ray Yang 主题: 基础设施