llms.txt 是什么？怎么写一份规范的 llms.txt

这份提案到底规定了什么

llms.txt 想解决的是上下文问题，不是抓取问题。当模型或智能体需要基于你的站点回答问题时，它面对的是有限的上下文窗口和相当不友好的输入：塞满导航、Cookie 提示条、侧边栏、广告和 JavaScript 渲染内容的 HTML 页面。把一个大型站点转换成模型能够推理的形态，既有信息损耗，成本也高。

llms.txt 规范 提出了两项互补的做法。第一，在 /llms.txt 放一个 Markdown 文件，作为人工筛选过的索引 —— 这个项目是做什么的，哪些页面重要，按优先级排列。第二，在可预测的 URL 上发布单个页面的干净 Markdown 版本（/docs/setup 同时可通过 /docs/setup.md 访问），这样智能体从索引里选中链接后，取回的是纯文本而不是模板。

也要看清它不是什么。它不包含任何指令，没有 allow 或 disallow 规则，也不授予任何权限。它只是你主动提供的一份阅读清单，任何使用方都可以选择无视。规范刻意采用 Markdown 而非 JSON 或 XML，正是因为目标读者是语言模型，同时人类也要能手工维护它。

• 实际采用情况到了哪一步
• paragraphs
• bullets

实际采用情况到了哪一步

任何声称 llms.txt 已成为排名因素的说法，都值得怀疑。Google 的 John Mueller 曾公开把它类比为早已废弃的 keywords meta 标签，并表示 Google 搜索不使用它，相关报道可参见 Search Engine Roundtable。Google 自己的抓取与索引文档也从未提到这个文件；它明确记录用于控制爬虫的文件是 robots.txt。

从消费端看，实话是：没有任何主流助手厂商发布过文档，说明其爬虫或检索层会用 /llms.txt 来决定抓取什么、引用什么。真正被验证在用的是另一个方向：开发者把 llms.txt 的 URL 粘进对话框，或者让编码智能体指向它，智能体顺着链接往下读。这是真实存在的工作流，也正是规范当初为之设计的工作流。

发布端的采用情况在开发者文档里最明显，一部分原因是 Mintlify 这类文档平台会为托管站点自动生成该文件。如果你要交付文档，这是配一份 llms.txt 的好理由 —— 但绝不是断定生态已经标准化的理由。一项采用成本几乎为零的约定，说明不了到底有没有人在消费它。

llms.txt 怎么写：完整格式规范

规范定义了严格的文档顺序，而顺序本身就是关键 —— 使用方应当能用一个普通的 Markdown 解析器读懂它，而不必依赖各种启发式猜测。

唯一必需的元素是一个包含站点或项目名称的 H1。之后的内容都是可选的，但位置受约束：H1 之后紧跟一段可选的引用块，用简短摘要交代理解后文所需的关键信息；接着是零个或多个 Markdown 段落或列表，补充细节，其中不允许出现任何标题；最后是零个或多个 H2 小节，每节包含一组链接列表。

链接行的写法是 Markdown 列表项，包含一个超链接，冒号后跟可选说明：名称、URL，然后用一句话说明什么时候该读它。这些说明是真正干活的部分 —— 模型正是靠它决定在你的十五个链接里把上下文花在哪两个上，所以要把它写成调度指令，而不是营销文案。

有一个 H2 具有特殊含义：标题为 Optional 的小节。当上下文需要压缩时，该小节下的链接可以被跳过。更新日志、深度参考资料，以及读者不看也能回答问题的内容，都适合放这里。另有一项约定 llms-full.txt，把文档全文拼接成一个文件，在文档平台中很流行，但它不属于核心规范 —— 请把它当作附加项，只有当你的内容确实塞得进当代上下文窗口时才发布。

• 部署在域名根目录，路径为 /llms.txt，以 text/plain 或 text/markdown 通过 HTTPS 提供。
• 保持简短。十到三十条精选链接胜过一整份站点地图导出；如果你需要列出每一个 URL，你本来就有 XML sitemap。
• 说明文字要能区分彼此：写“定价档位与用量上限”，而不是“了解更多 Growli 信息”。
• 只链接公开可访问且稳定的页面。精选索引里出现死链，比没有索引更糟。
• 如果文档每周都在变，就在构建流程里自动生成，别手工维护。

实例拆解：Growli 自己的文件

我们的版本刻意做得很小。Growli 衡量的是 AI 助手如何提及和推荐企业，因此智能体需要的页面只有这几类：产品做什么、测量方法怎么运作、定价，以及界定我们术语的研究文章。其余内容都不够格占一个位置。

作为文件来读，它是一个 H1、一段引用块摘要，然后两个 H2 小节 —— 第二个就是 Optional。下面每一行都是该文件中的一行：

• # Growli
• > Growli 追踪 AI 助手 —— ChatGPT、Gemini、Claude、Perplexity、Copilot 和 Grok —— 如何提及、比较和推荐企业，并把发现的差距转化为按优先级排序的行动项。
• ## Core
• How it works：测量方法 —— 提示词集合、运行频率，以及提及与推荐的评分方式。
• AI visibility：该指标的定义、什么能撬动它、什么不能。
• ## Optional
• Blog：关于助手行为、引用模式与测量方法论的研究文章。

它和 robots.txt、结构化数据各自的位置

这三个文件回答的是三个完全不同的问题，把它们混为一谈，是我们在审计中见得最多的错误。

robots.txt 回答的是“你可以抓这个吗” —— 它是爬虫访问控制文件，解析行为由来已久且有正式文档，你要允许或禁止某个具名 AI 爬虫，就在这里操作。如果你想限制训练或抓取，那要写在 robots.txt 和你的服务条款里，绝不是写在 llms.txt 里。结构化数据回答的是“这是什么” —— 用 JSON-LD 承载的 Schema.org 词汇，让你毫不含糊地声明自己是一个 Organization，叫什么名字、有哪些产品、什么价格、有哪些评价，这类机器可读的事实在被摘要之后依然能保留下来。llms.txt 只回答一个问题：“我该先读什么”，而且面向的是已经决定要读你的使用方。

从投入产出比看，顺序虽不性感但一贯有效：先解决可抓取性和服务端渲染内容，再做实体层面的结构化数据，最后才是 llms.txt。一份列满了“不开 JavaScript 就一片空白”的页面链接的文件，对谁都没有帮助。

那你到底要不要发布一份？

要发，如果你有技术文档、API、开发者产品或知识库 —— 成本是几分钟，文件人眼可读，而“有人把你的 llms.txt 链接丢给智能体”这种工作流已经很常见了。发布它，保持内容准确，然后继续做别的事。

大概不值得优先做，如果你是本地服务商、电商商品目录，或者只有十二个页面的营销站。目前没有证据表明它会影响助手是否推荐你，这份精力更该花在助手确实会读的东西上：不依赖 JavaScript 就能渲染的页面、明确的对比与定价内容、站内与第三方名录之间一致的实体事实，以及模型在回答“某场景下最好的 X”时所倚重的评测站点与盘点文章中的曝光。

真正诚实的检验方式是测量。跟踪助手多久提到你一次、在哪些提示词下提到、提到时引用了哪些来源 —— 这正是我们的 AI visibility 追踪要解决的问题，而 how it works 解释了具体方法。如果发布 llms.txt 让这些数字动了，你会看得见；如果没动，你也不过花了二十分钟，还搞清了一件确凿的事。

FAQ