如果你最近在看 AI 搜索相关的建议，「加一个 llms.txt」大概出现过不止一次。这件事本身成本很低，问题在于很多人不清楚它是什么、谁在用、能解决什么。把这三件事说清楚，你就知道该把它排在待办清单的哪个位置。
它是什么：一份提案，不是协议
llms.txt 的提出者把它称为一份「提案」：主张在网站根目录（或任意子路径）放一个 markdown 文件，向代理说明这个站点有什么内容，并链接到更详细的 markdown 版本。文件本身是给人也能读的文本，同时按固定格式书写，以便程序解析；提案还建议给重要页面提供对应的 .md 版本。
提案页自己在 2026 年 8 月的修订版里说明了这两年的采用情况：已经有相当数量的站点发布了 llms.txt，一些文档平台会自动生成，浏览器的某个审计项也会检查它是否存在，AI 公司为自己的开发者文档站发布 llms.txt。这些都能在公开页面核对。
需要分清楚的是「有人用」和「协议」。目前的现状是没有一个强制性标准规定读取方必须读取它、也没有任何平台承诺按它来排序或引用。它更像是发布方递给读取方的一张名片，收不收、怎么用，由读取方决定。
Google 的明确表态：搜索不使用它
这一点在谷歌官方的生成式 AI 优化指南里写得非常直白。指南在「不需要做的事」清单里专门列了一条关于 llms.txt 的说明，大意是：要让内容出现在 Google 搜索（包括其生成式 AI 能力）中，你不需要创建新的机器可读文件、AI 文本文件、标记或 markdown，因为 Google 搜索本身不使用它们；谷歌同时也说明，它确实可能发现、抓取和索引 HTML 之外的各种文件类型，但这不代表这类文件会被特殊对待。
谷歌并没有把话说成「你不许做」。同一节里还有一句常被忽略的补充：如果你是为了其他服务或系统（确实会读这些文件的那种）而创建和维护 llms.txt，那完全没问题。所以正确的预期是：它对 Google 搜索既不加分也不减分，是一份与谷歌检索无关的额外文件。
其他平台：文档里没有把它当作控制手段
判断一个文件有多少实际作用，最直接的办法是看各平台自己的爬虫文档怎么描述「你能怎样影响我」。OpenAI、Anthropic、Perplexity 的爬虫说明里，控制手段是 robots.txt 里的 user-agent token 与来源 IP 段核对；llms.txt 没有被列为其中任何一项。Bing 的爬虫文档同样没有提到它。
另一个容易混淆的观察是：OpenAI、Anthropic 的开发者文档站自己提供 llms.txt 或类似的文档索引，让 AI 代理更快找到 API 文档。这属于「内容提供方为他人的读取方便做了结构化索引」，和「你写了一定会被搜索引擎读取」是两件事。同一个文件，在这两个场景里的作用完全不同。
什么情况下值得做，什么情况下先别做
值得做的情况比较具体：你的站点本身有大量结构化技术资料（产品手册、API 文档、选型说明），而你的目标读取方里有明确会读 llms.txt 的系统——例如开发者的编码代理、你正在对接的内部工具、或是已经声明支持该文件的服务。这种情况下它的收益来自「让对方更快找到对的页面」，成本也确实很低。
可以先放一放的情况同样具体：你的目标是「被 Google 的 AI 功能引用」或者「提升排名」。这两件事跟 llms.txt 没有关系。谷歌的立场是沿用基础 SEO 与内容质量原则，指南里还顺带否掉了另外几个流传很广的说法——不需要为 AI 把内容切成小块，不需要为生成式 AI 专门换一种写法，也不需要去买不真实的「提及」。
还有一个顺序问题：如果你的站点连基础抓取都有问题，先修抓取和索引，再考虑这类锦上添花的文件。判断哪些抓取该放行、哪些该限制，可以先看robots.txt 里 AI 爬虫 token 怎么写；如果站点是前端框架渲染的，优先确认关键内容在不在原始 HTML 里，这部分在渲染与脚本对可抓取内容的影响里展开。光算的 GEO 服务在诊断阶段会先确认站点基础，再决定要不要加上这类可选文件。
真要写的话，几个不浪费时间的写法
决定做之后，别把它当成第二份站点地图来堆 URL。提案的思路是「先给摘要，再给入口」，所以更实用的结构是：先用几句话说明这个站点是做什么的、面向谁；然后按内容类别分组，把真正希望被读取的少数页面写成带说明的链接，而不是把全部页面倒进去。如果某个类别下确实有更详细的文档，再链到对应的 markdown 版本。
另外三件事顺手核对一下，能避免大部分无效劳动。第一，路径放在站点根目录，文件名大小写跟提案一致，别自己发明变体。第二，跟 robots.txt 的分工别混：robots.txt 管的是「谁能抓」，这个文件管的是「有哪些值得读的内容」，两件事互不替代，也不能互相修正对方的错误。第三，留一份维护约定：谁负责更新、什么时间更新、页面下线时怎么同步，否则半年后它就会变成一份与人手维护的文档完全脱节的清单——那种文件对任何读取方都没有价值。
如果因为人手或工期原因只能先做一件事，我建议先处理站点上那些「写了但没被任何页面链接」的独立页，以及参数、规格、适配条件这类决策信息是否出现在原始 HTML 里。这两件事对搜索与 AI 检索都有直接影响，优先级比新增一个可选文件高。
这部分通常还要配合其他环节一起做：“已发现，尚未编入索引”怎么排查：从GSC状态到真实抓取日志。
参考来源
- The /llms.txt file, v2 — llmstxt.org — llms.txt 是提案而不是强制协议，作者是 Jeremy Howard，2024 年 9 月首次发布，2026 年 8 月修订为 v2。
- Optimizing your website for generative AI features on Google Search — Google 明确表示：不需要创建 llms.txt 这类特殊文件，Google 搜索本身不使用它们。
- Overview of OpenAI Crawlers — OpenAI 的爬虫文档给出的控制手段是 OAI-SearchBot 与 GPTBot 两个 robots.txt token，并未把 llms.txt 列为控制项；该文档站自身提供 llms.txt 作为文档索引。
- Does Anthropic crawl data from the web, and how can site owners block the crawler? — Anthropic 说明其控制方式是通过不同 robots 与 robots.txt 指令给站点选择权，文档中没有把 llms.txt 作为控制手段。
- Perplexity Crawlers — Perplexity 的管理手段同样是 robots.txt 标签，未提及 llms.txt。