llms.txt 完全指南：写什么、放哪里、实际有没有用

近两年做官网的人多多少少都听过 llms.txt 这个词。它被反复提起，却又经常被误解：有人把它当成「面向 AI 的搜索引擎提交入口」，也有人觉得它只是又一个没人会读的文件。两种理解都不准确。

先把结论放在前面：llms.txt 是一份放在站点根目录的纯文本说明文件，用 Markdown 的格式，向大模型和 AI 检索工具说明「这个站点是做什么的、有哪些重要页面」。它不是一个官方强制标准，也替代不了 robots.txt；它的价值在于用低成本把站点的关键信息显式地告诉机器。理解它的作用与边界，比争论它「有没有用」更重要。

一、llms.txt 是什么

llms.txt 的主张很简单：既然站点会给搜索引擎提供 sitemap.xml、给爬虫提供 robots.txt，那也可以给大语言模型提供一份专供阅读的说明文件。

这个约定的提出者是 Anthropic，其思路是：与其让模型在一堆 HTML 里猜测站点结构，不如由站点主动提供一份简洁、结构化的说明。文件本身采用 Markdown 格式，通常包含一段站点简介，再按若干分区列出重要页面及其链接和一句话说明。

生成式引擎在处理与站点相关的问题时，可能借助类似资料来理解「这是哪家公司、提供什么、有哪些关键内容」。需要注意措辞：是「可能借助」，不是「一定读取」。llms.txt 目前不是被各家厂商普遍承诺支持的协议，它的效果取决于具体产品的实现。把它当作一份「低成本的补充说明」，而不是「确定生效的开关」，才是合理的预期。

从工程角度看，站点与机器之间天然存在一次「信息不对称」：站点清楚自己的全部内容，而机器只能看到被它抓取到的那一部分，剩下全靠推断。llms.txt 的用意就是主动缩小这个不对称——不等机器来猜，而是直接说明。这个思路和给搜索引擎提供 sitemap.xml 是同一逻辑：与其被动等待被发现，不如把清单交出去。理解这一点，就不会对它抱有不切实际的期待，也不会因为它不是标准就完全否定。

二、它解决什么、不解决什么

要说清楚边界，一个直接的办法是把两边各自列出来。

它可能解决的问题：

• 让机器快速知道站点的主体是谁、主营什么，减少对站点的猜测。
• 把最重要的页面集中列出，帮助模型在需要时找到入口。
• 统一站点的对外口径，尤其是公司名称、业务范围这类容易在多处写得不一样的信息。

它不能解决的问题：

• 它不能保证内容被收录或被引用。模型的检索仍取决于抓取能力、内容质量与产品策略。
• 它不能替代 robots.txt。robots.txt 管的是「能不能抓」，llms.txt 管的是「如果你要了解我，这里是简介」，职责不同。
• 它不能替代结构化数据。JSON-LD 是写在页面里、与人可见内容一一对应的标注；llms.txt 是站点层面的总览，两者层级不同。
• 它不能掩盖内容问题。站点内容空洞、口径混乱时，再工整的 llms.txt 也无济于事。

一句话：llms.txt 是「锦上添花」的说明文件，不是「雪中送炭」的补救措施。

三、文件结构与字段写法

基本格式

llms.txt 使用 Markdown 语法，整体结构通常是：

• 一个一级标题，写站点或组织名称。
• 一段简短的说明，概述站点是做什么的。
• 若干二级标题分区，每个分区下列出链接条目。
• 每个链接条目的格式是「链接文字 + 括号内的绝对 URL」，后面可以接一句简短说明。

需要强调的是：这里的「一级标题」是文件内部的 Markdown 写法，与我们网站文章正文不使用 # 的规则是两回事，不要混淆。

各字段的含义

• 标题：对应站点的正式名称，建议与官网、结构化数据里的名称完全一致。
• 概述段落：一句话讲清楚「谁、做什么、服务谁」，控制在两三句内，不要写成营销文案。
• 分区标题：按用途分组，例如「核心页面」「服务」「文档」。
• 链接条目：使用绝对 URL，链接文字用页面标题或简短的语义名称，便于阅读。
• 可选的补充说明：在链接后加一句话，说明这个页面能回答什么问题。

一个最小可用的示例

下面用占位标签表示层级（[H1] 对应 Markdown 的一级标题，[H2] 对应二级标题，正式文件里写对应的井号语法即可）：

```text [H1] 公司名称

一句话说明公司是做什么的、服务哪类客户。

[H2] 核心页面

• 首页: 站点入口与总体介绍
• 关于我们: 公司简介与团队情况

[H2] 服务

• 服务总览: 全部服务一览

[H2] 说明

• 常见问题: 常见问题汇总

```

关键在于「信息准确、结构清晰、链接可用」，而不在于把文件写得多长。文件越长，越容易出现与官网不一致的内容，反而增加机器判断的负担。

常见写法错误

在实践中，下面几类写法比较常见，也容易带来反效果，值得避开。

• 写成营销文案：把概述段落写成广告语，机器提取不到有效信息，人读了也不信任。
• 链接堆砌：为了「覆盖更多页面」把几十个链接全列进去，重点被淹没，等于没重点。
• 使用相对链接：只写 /about.html 而不写完整域名，机器无法确认指向哪里。
• 口径与官网不符：文件里写「某某科技」，官网写「某某科技有限公司」，反而制造混乱。
• 长期不更新：官网已经改版，文件还停在旧版本，链接失效、描述过期。

与其他文件的写法对照

文件	回答的问题	主要格式	位置
robots.txt	哪些路径可以抓	指令行	站点根
sitemap.xml	有哪些页面	XML	站点根
llms.txt	这是什么、重点在哪	Markdown	站点根

三者都以站点根为家，但分工不同：一个管准入，一个管清单，一个管自述。它们可以并存，不建议互相替代。

四、和 robots.txt 的关系

这是最容易被混淆的一点，单独讲清楚。

• robots.txt：告诉爬虫「哪些路径可以抓、哪些不要抓」，管的是访问权限。它是搜索引擎广泛遵守的约定。
• sitemap.xml：列出站点希望被收录的页面清单，管的是「有哪些页面」。
• llms.txt：用自然语言加链接的形式介绍站点，管的是「这是什么、重点在哪」。

三者的关系是互补而不是替代：robots.txt 决定机器能不能进来，sitemap.xml 告诉机器有哪些内容，llms.txt 帮助机器理解内容的组织与重点。实践中，一个常见的错误是只加了 llms.txt，却让 robots.txt 误拦了关键路径——那样的话，说明文件写了也没用。

关于抓取与索引的基础处理，我们在 技术能力 中有更系统的分层说明。

五、放在哪里、怎么验证

部署位置

llms.txt 按约定放在站点的根目录，即 https://你的域名/llms.txt。这一点与 robots.txt、sitemap.xml 一致，都要求返回 HTTP 200 且内容类型为纯文本。如果你的站点部署在子路径下（例如 https://example.com/site/），文件仍应放在该站点根下，而不是整站域名根下混放。

验证方法

部署后建议做几项基础验证：

1. 可访问性：直接访问 https://域名/llms.txt，确认返回 200 且显示纯文本内容，而不是 404 或下载文件。
2. 内容类型：确认响应头的 Content-Type 是 text/plain，避免被当成二进制下载。
3. 链接有效性：逐个检查文件里的链接，确保都能打开且指向的页面存在。
4. 口径一致性：把文件里的公司名称、业务描述与官网、结构化数据比对，确认三处一致。
5. 格式校验：确认 Markdown 没有明显的语法错误，尤其是链接的括号与 URL 是否完整。

这几项都不涉及复杂工具，手工核对一遍即可完成。

另外两点容易被忽略。其一，站点若同时存在 http 与 https、或带不带 www 的多个版本，应确保任一版本访问 llms.txt 都能得到同一份内容，避免出现「有的地址有、有的地址没有」的尴尬。其二，文件更新后要留意缓存，CDN 或浏览器缓存可能仍返回旧版本，必要时先刷新缓存再验证，否则容易误判为「没生效」。

六、实际有没有用

这是最需要诚实回答的一节。

从公开信息看，llms.txt 目前是一个由厂商提出、社区讨论、逐步被部分工具尝试采纳的约定，它还不是所有主流 AI 产品都承诺支持的标准。不同产品是否读取、以什么方式读取，都可能有差异。因此在现有阶段，比较稳妥的判断是：

• 成本极低：写好一份准确的 llms.txt 只需要不长的工时，且不影响其他任何优化。
• 收益不确定：它可能在部分场景下帮助机器理解站点，但不能指望它单独带来可见度提升。
• 不写也不致命：如果站点基础薄弱，优先补可抓取、结构化数据与内容质量，收益通常更直接。

换一个角度看：llms.txt 的价值不只在「被读取」，还在于它强迫团队把站点的对外口径统一梳理一遍。这份梳理本身就是内容治理的一部分，即便某个引擎没读它，梳理的成果也会体现在官网各处。

还有一个判断角度：把 llms.txt 看作「AI 可读性的最低配置」，而不是「优化手段」。最低配置的意思是——它让你不至于因为「站点没有向机器做任何自述」而吃亏，但它不承诺额外收益。真正的收益仍然来自内容本身：能不能把用户真正关心的问题讲清楚。把 llms.txt 当成地基的一部分去补，而不是当成一次「优化动作」去期待回报，心态会更稳。

顺带说明一个常见的落地方案：如果站点规模不大，llms.txt 完全可以手工维护，不必引入自动生成工具。手工的好处是内容可控、口径好核对；等到站点页面成百上千再考虑自动化也不迟。过度工程化反而会让这份本该简洁的文件变得难以维护。

七、落地建议

如果决定把 llms.txt 做起来，可以按下面的顺序推进。

• 先统一口径：把公司全称、简称、业务范围、联系方式确定为一套说法，所有地方以这套为准。
• 再列关键页面：只放真正重要的页面，避免列出几十个链接造成噪音。
• 保持与官网一致：文件里的名称与描述必须与官网、结构化数据完全对齐。
• 纳入发布流程：把 llms.txt 的更新与官网改版绑定，避免站点改了、文件没改。
• 定期复核：每隔一段时间检查链接是否失效、口径是否还准确。

关于站点信息如何被机器理解的整体思路，可以参考 GEO 生成式引擎优化服务 的方法说明；具体执行中的疑问，我们在 常见问题 中也有汇总，进一步沟通可走 联系我们。

八、小结

llms.txt 不是万能钥匙，也不是无用装饰。它是一份低成本的站点自述：把「我是谁、我有什么」用机器能读的格式讲清楚。它的上限取决于模型产品的采纳情况，但它的下限很低——即使只被当作一次口径梳理，也值得做。

对企业的实际建议是：把基础工程（可抓取、结构化数据、口径一致、内容质量）放在优先位置，llms.txt 作为其中的一环顺手补齐。不要因为它「可能有用」就高估它，也不要因为它「不是标准」就完全忽略。

本文由广州科芃科技有限公司技术团队整理。我们建议把 llms.txt 纳入站点基础设施统一管理，先保证口径一致与可抓取，再考虑这类补充说明文件，顺序不要颠倒。