llms.txt生成器怎么用？逐字段填法、分区设计与部署验证

摘要：这篇讲的是怎么用生成器做出一份格式合规、内容够用的llms.txt——逐字段该填什么、分区怎么排、条目描述怎么写才有信息量、生成之后放哪儿和怎么验证。至于这个文件到底值不值得做、Google那边什么态度，站里另有一篇专门算过账，这里不重复；结论一句话带过：成本低到十分钟能出，当成一次内容盘点顺手做掉即可，但别指望它影响排名。

先把定位说清楚：这篇不讨论要不要做

llms.txt是一份放在网站根目录的Markdown清单，用来告诉大模型“这个站最值得读的内容在哪里”。它由Jeremy Howard在2024年9月3日提出，形式上借鉴了robots.txt和sitemap.xml——固定文件名、放根目录、机器可读。

关于它值不值得做，站里已经算过两笔账：一笔是实测账，llms.txt到底有没有用？10个站90天实测给的答案用日志数据回答了“部署之后到底有没有人来读”；另一笔是信号账，Google说搜索不需要llms.txt，Chrome却偷偷在查它拆了官方表态与浏览器行为之间的矛盾。要判断做不做，先看那两篇。

这篇的定位不同：假设你已经决定做了，接下来就是怎么把它做对。下面全部是操作层面的东西——字段怎么填、内容怎么选、生成之后怎么部署和验证。

提案规定的结构长什么样？

官方规范对顺序有明确要求，但必填项少得出人意料：

• 一个H1，写项目或站点名称。规范原文说这是唯一必需的部分，其余全部可选。
• 一个引用块，用一两句话概括这个站是做什么的。虽然可选，但模型读到的第一段就是它，省掉相当可惜。
• 若干不带标题的普通段落，补充说明用。
• 若干H2分区，每个分区下是链接列表，格式为减号加中括号标题、圆括号网址，冒号后跟可选说明。
• 一个名为Optional的分区。规范对它的定义是：这里的网址在需要更短上下文时可以被跳过。换句话说，它是给模型的“这部分不是核心，装不下就别装”的信号。

结构简单到几乎不需要工具。那为什么还要生成器？因为手写容易在细节上翻车——引用块忘了写、条目少个冒号、分区标题用了三个井号、链接写成相对路径。这些单看都不致命，但堆在一起就是一份格式松散的文件。

生成器的界面对应哪些字段？

把工具打开，编辑区从上到下依次是站点名称、站点描述、补充说明，下面是内容分区，再下面是实时预览和导出按钮。每一块都严格对应规范里的一个位置。

站点名称：写名称，别写口号

这个字段会变成文件的第一行H1，是唯一的必填项。它应该是项目或站点的名字，简洁明确。

常见的写法失误是把它填成一句营销话术——“专业的一站式数字营销解决方案提供商”这种。模型从这句话里拿不到任何有效标识，人也看不出这是哪个站。名称就写名称，八个字以内通常够用。

站点描述：模型读到的第一段实质内容

这个字段生成的是紧跟H1的引用块。虽然规范说可选，但它是整份文件里信息密度最高的一句话，值得多花两分钟。

好的写法交代三件事：这个站做什么领域、提供什么形态的内容、面向谁。比如“聚焦Google SEO与生成式搜索优化的实战笔记，含免费在线工具与逐款教程，面向外贸独立站与内容运营者”——领域、形态、受众都齐了。

差的写法是堆形容词：“业界领先的专业平台，值得信赖的优质内容。”这句话换到任何一个站都成立，等于没说。顺带一提，这类绝对化表述在中文场景下还有合规风险，站里有专门的广告法违禁词检测，文案定稿前可以顺手过一遍。

补充说明：解释清单的取用方式

这个可选字段生成的是不带标题的普通段落，位置在引用块之后、第一个分区之前。它适合放两类信息：一是这份清单的组织逻辑（比如“按使用场景分区，每条附一句适用说明”），二是取用提示（比如“全文版见某某地址”）。

不适合放的是公司简介、联系方式、版权声明——那些内容对模型理解你的站没有帮助，只会稀释信息密度。

内容分区：一个分区一个主题

点添加分区，填分区名，就会生成一个H2。分区名要能概括这一组内容的共同点，“文档”“教程”“工具”“案例”这类具体的名词最好用。

每个分区下面可以继续添加条目，每条填网页标题、网址和可选的描述。工具会自动拼成规范要求的格式，不需要自己敲中括号和圆括号。

条目描述怎么写才有信息量？

每条链接后面那句描述，是最容易糊弄、也最影响效果的部分。判断标准只有一条：只看这句话，能不能判断出什么场景下该点开它。

对照着看差别

写描述时有个省力的办法：把这一条的目标读者的问题想一遍，用一句话回答“这篇能帮他解决什么”。这比对着标题改写要快，写出来也更有用。

长度控制在多少？

一句话，二三十个字。这是清单不是摘要，太长会让整份文件变得难扫。如果一句话说不清，往往说明这一条本身不够聚焦，或者它不该出现在精选清单里。

清单里该放哪些内容？

格式规范只占这件事的两成，剩下八成是“放什么进去”。这里给几条实际用下来的判断标准。

选内容的三条标准

选常青的，不选时效的。llms.txt更新频率通常很低，放促销页、活动页进去，过一阵就成了死链。优先放一两年内不会变的内容：核心教程、工具页、术语表、方法论文章。

选自足的，不选依赖上下文的。如果一篇文章必须配合前后几篇才看得懂，单独被取用时价值有限。优先放那些从头到尾把一件事讲完整的页面。

选有独特信息的，不选人云亦云的。模型已经从各种渠道学过通用知识，你的站真正值钱的是别处没有的东西：一手数据、实测结论、独有的方法。

三类站的分区怎么排？

文档站与API站。这是llms.txt眼下最有实际用途的场景——给IDE里的编程助手和智能体取用文档。分区建议按“快速开始、核心概念、API参考、常见问题”排，把入门路径放在最前面。

内容站与个人博客。按主题分区，每个主题挑三到五篇最能代表你观点的文章。这里有个反直觉的建议：别按流量排。流量高的常常是泛话题文，而清单该体现的是你独有的那部分。

工具站与SaaS站。按使用场景分区而不是按功能分类，因为模型接到的问题通常是场景描述而不是功能名词。把“页面进不了索引怎么排查”这样的场景当分区名，比“技术SEO工具”更容易被匹配上。

放多少条合适？

几十条是合理量级。这是精选清单不是全站目录，几百条就失去意义了——那种需求应该由sitemap.xml承接。内容多的站正确做法是分层：最核心的十几条放主分区，次要的放进Optional分区。

完整走一遍：给一个工具站做清单

光说规则不如走一遍。下面用一个假想的场景演示全过程：一个做SEO工具的站，二十来款在线工具，配套写了几十篇教程，现在要给它做一份llms.txt。

第一步：先盘内容，再打开工具

很多人一上来就填表，填到一半发现不知道该放什么。正确顺序是反过来的：先在纸上或文档里列出候选，筛完再动手。

盘点的问题只有一个：如果一个模型只能读我站里的十五个页面，读哪十五个最能代表这个站？按这个标准过一遍，通常会淘汰掉大半——那些泛话题的引流文、蹭热点的时效文、内容重复的同类文，都会在这一步被筛掉。

假设筛完剩下十八条：六款最常用的工具页、八篇有一手实测数据的教程、两篇方法论长文、一份术语表、一个关于页。

第二步：按场景分区，不按功能分类

十八条不能平铺，得分组。这里有个容易走弯路的地方：大多数人会按功能分成“分析类工具”“生成类工具”“检查类工具”，但模型接到的问题通常是场景描述而不是功能名词。

按场景分的话，分区会变成这样：

• 收录与抓取排查：放可索引性体检、robots验证、日志分析这一类
• 内容质量与AI引用：放内容评分、引用评估、分块预览这一类
• 方法论文章：放两篇长文
• Optional：放术语表和关于页——它们有用，但不是核心，上下文紧张时可以跳过

注意最后那个Optional分区。这是提案里的机制，用起来只需要把分区名写成Optional，但很多人不知道有这回事，结果把次要内容和核心内容混在一起，模型只能一视同仁地读。

第三步：填字段

打开工具，从上往下填。站点名称填站名本身；站点描述用一句话交代领域、内容形态和受众；补充说明写清这份清单的组织逻辑。

然后逐个添加分区，每个分区下添加条目。条目的标题直接用页面标题，网址填绝对地址，描述按前面说的标准写——让人只看这一句就知道什么时候该点开它。

这一步最花时间的是写描述，十八条大概要二十分钟。但这二十分钟是整件事里最有价值的部分：它逼你把每个页面的独特价值用一句话说清楚，说不清楚的那几条，往往本身就该重写或者不该进清单。

第四步：看预览，检查四件事

右侧预览区会实时显示最终文件。生成之后重点看这四处：

• 第一行是不是以单个井号开头的站名
• 紧跟着的描述是不是以大于号开头的引用块
• 每个分区是不是两个井号，条目是不是减号加中括号加圆括号的格式
• 有没有哪一条只剩纯文本或裸网址——那说明标题或网址漏填了

第四条最容易漏。工具在字段缺失时会静默降级，预览区里那一行看着也挺正常，只有对照格式才能发现它已经不合规了。

第五步：部署与放行

下载文件，传到网站根目录。传完在浏览器里打开一次，确认能正常显示纯文本而不是弹出下载框。

然后检查robots.txt有没有把它挡住。这一步经常被跳过，但代价可能是整件事白做——文件取不到，格式再规范也没有意义。

第六步：校验并记进维护清单

用校验器跑一遍，确认格式合规、链接可达。然后做一件更重要的事：把“更新llms.txt”写进站点改版的检查清单。这份文件没有自动生成机制兜底，它的失效永远是安静的。

产出的文件大概长这样

# 某某工具站

> 聚焦搜索优化的免费在线工具与实测教程，面向外贸独立站与内容运营者。

清单按使用场景分区，每条附一句适用说明。完整内容见全文版。

## 收录与抓取排查
- [可索引性一键体检](https://example.com/tools/indexability.php): 一个网址查清状态码、robots判定、noindex与canonical
- [服务器日志分析](https://example.com/tools/log.php): 按爬虫维度聚合抓取频率与状态码分布

## 内容质量与AI引用
- [分块预览器](https://example.com/tools/chunk.php): 模拟检索时的切分，标出被切断的答案句

## Optional
- [术语表](https://example.com/glossary/): 常见概念的逐条解释

这款生成器实际做了什么？

把工具拆开看，实现比想象的朴素，但该做的都做了。

核心是一段纯前端的拼装逻辑

页面上的内容全部由浏览器里的JavaScript组装：读站点名称拼成H1，读描述逐行加上引用符号，读补充说明原样附上，再遍历每个分区输出H2标题和它下面的链接列表。整个过程没有网络请求，输入的内容不会离开你的浏览器——给还没上线的项目准备文件时，这一点值得留意。

实时预览带语法着色

预览区随输入即时更新，并且给H1、H2、引用块和链接分别着了色。改一个字就能看到最终文件长什么样，比在编辑器里盲写稳得多。这也是这款工具最实用的一点：它把“格式对不对”这件事变成了肉眼可见的。

导出与部署

可以复制到剪贴板，也可以直接下载成文件，编码是UTF-8。下载下来的文件传到网站根目录就能用。

它有哪些做不到的地方？

把话说在前面，比用完之后再发现要好。

• 它不校验网址是否有效。链接填错了、页面已经删了，工具不会有任何提示，照样生成。这是最容易积累的隐性问题——llms.txt最常见的失效方式，就是改版之后文件没跟着更新，里面躺满死链。
• 缺字段时会静默降级。一条链接只填标题没填网址，输出的是一行纯文本；只填网址没填标题，输出的是一个裸网址。这两种都不是规范里的合法条目格式，但工具不会拦你，预览区里也看不出异常。
• 没有Optional分区的引导。Optional是提案里挺有用的一个机制，工具却只提供普通分区，你得自己把某个分区命名为Optional才能用上，界面上没有任何提示。
• 后端有一段与前端不一致的遗留代码。PHP部分还留着一套独立的生成逻辑，接收的字段和前端不一样，还会多输出一行以URL开头的内容——那不在提案格式里。正常从页面上使用不会触发它，但这段代码本身该清理。
• 不做数量控制。你可以往里塞几百条链接，工具不会提醒你这已经违背了“精选”的初衷。

还有一条限制不属于工具，属于这件事本身：生成一份格式完美的llms.txt，和这份文件被读取，是两件没有因果关系的事。工具只能保证前者。

llms.txt和llms-full.txt有什么区别？

这里有个常见误解值得澄清。很多文章把两者说成提案定义的一对文件，但翻开官方规范会发现，它举的例子是llms-ctx.txt和llms-ctx-full.txt，区别在于含不含Optional分区里的链接。llms-full.txt这个名字其实是社区约定俗成的，不在原始提案里。

抛开命名，实际存在的是两种思路。索引式只给链接和说明，文件小、维护简单，但模型需要再发请求去取内容，取不取得动还要看页面是不是依赖JavaScript渲染。全文式把主要内容直接拼进一个文件，一次读完，代价是文件可能几百KB甚至几MB，超出很多场景单次能吃下的量，也更难保持同步。

实践上建议两个都提供：索引版做精选，全文版给需要完整内容的场景。这款生成器负责的是前者，全文版通常需要脚本从内容库批量导出。

它和robots.txt、sitemap.xml是什么分工？

这三个文件都放根目录、都给机器看，很容易被混为一谈。但它们回答的是三个不同的问题。

看懂这张表，有两个推论会自然浮现。

它替代不了另外两个。有人以为写了llms.txt就能让AI只读指定内容、不碰其他页面——这是误解。控制抓取范围是robots.txt的活，llms.txt既不控制权限，也不承担全站网址清单的职责。

优先级排序很清楚。三者只能做一个的话，先做robots.txt，它写错了整站会从搜索里消失，杀伤力是实打实的；其次sitemap.xml，直接影响收录效率；最后才轮到llms.txt。顺序颠倒过来，属于捡芝麻丢西瓜。

更新节奏也不同：robots.txt一年可能改一次；sitemap.xml通常自动生成、天天更新；llms.txt介于两者之间，内容大改版时更新就够。给它专门上一条自动生成流水线通常不划算，那点收益抵不上维护复杂度。

还有一点值得提醒：两个文件如果内容不同步，麻烦比只做一个更大。索引版更新了、全文版还是三个月前的，模型读到哪一份完全看运气，得到的结论可能互相矛盾。做全文版之前先想清楚谁来保证同步，答不上来就先只做索引版。

多语言站和多个站点该怎么处理？

规范只定义了单个文件的格式，没规定多语言场景怎么办。实际操作时按站点的组织方式来判断。

子域名分语言的，各做各的

如果英文版和中文版在不同的子域名上，它们在协议层面就是两个独立站点，各自的根目录各放一份，内容分别用对应语言写。这种情况最简单，没有歧义。

子目录分语言的，做一份主文件

如果各语言版本都挂在同一个域名的不同子目录下，只有根目录那一份会被取用。这时候的做法是：主文件用站点的主要语言写，然后单独开一个分区，把各语言版本的入口列出来，描述里注明语种。

不建议做的是把所有语言的条目混在同一个分区里。清单本来就靠描述来传递信息，几种语言穿插着排，可读性会掉得很厉害。

描述用什么语言写？

用目标读者的语言。如果这个站主要服务中文用户，就用中文写；主要做外贸出海面向英文市场，就用英文写。模型对两种语言都能处理，但描述的准确度取决于你用哪种语言表达得更精确——用不熟的语言硬写，容易写出含糊的句子，反而降低了这份清单的价值。

一个人管好几个站怎么办？

每个站单独一份，别想着做一份总的。llms.txt是站点级的文件，取用方按域名去根目录拿，跨站点的汇总清单没有约定的存放位置，做了也不会有人来读。

真要在站与站之间建立关联，靠的是页面之间的链接和结构化数据里的组织信息，那是另一套机制，不归这个文件管。

生成之后放哪、怎么验证？

文件生成只是开头，后面这几步同样容易出错。

部署位置与robots放行

文件必须放在网站根目录，通过域名直接加文件名就能访问。放子目录等于没放，因为约定的取用位置只有根目录一个。

另外建议在robots.txt里显式放行它。如果站里有比较激进的禁止规则——比如为了挡扫描器写的前缀禁止、改版期间加的临时全站禁止——有可能连带把这个文件挡在外面，抓取方连文件都取不到。这类规则由RFC 9309定义的匹配优先级决定生效与否，光靠肉眼读规则不保险。

验证方法很直接：把文件路径丢进robots.txt生成器与验证器，看它对这个路径的判定。花十秒钟，省掉一个隐形故障。关于robots.txt本身有哪些容易踩的规则细节，站里另有一篇robots.txt和meta robots什么时候用哪个可以对照。

返回的类型要对

服务器应该以纯文本类型返回它。有些服务器配置会把未知扩展名当成下载文件处理，浏览器一打开就弹下载框，抓取方拿到的内容类型也可能不对。传上去之后自己在浏览器里打开一次，是最快的检查。

用校验器过一遍

格式对不对、链接还活着没有，靠肉眼看几十条容易漏。站里有一款配套的llms.txt校验器，按提案逐项检查H1、摘要块、分区和条目格式，并抽样验证链接可达性，顺带看你有没有提供全文版。生成之后过一遍，改版之后再过一遍，这是维护成本最低的做法。

怎么知道它有没有被读取？

与其看别人的统计，不如在自己站上验一遍，这比任何二手结论都可靠。

去日志里查这个文件的请求

方法很朴素：在访问日志里搜文件名，看有没有请求记录、请求方是谁。日志每行都带请求路径和User Agent，两项一对照就知道来取的是真爬虫、第三方检测工具，还是根本没人来。

要注意区分几类请求方：主流AI厂商的官方抓取程序、各类SEO工具的爬虫、研究机构的采样爬虫。后两类占比往往高得出乎意料——很多站长看到日志里有请求就以为“AI在读我的文件了”，实际来的是某个监测平台。分辨方法是查User Agent，站里的爬虫名称识别工具内置了一百多种爬虫的对照表，粘进去就能看出是谁。想系统看懂各类AI代理的抓取行为，可以参考AI Agent抓取日志解码：8类UA实测与流量归因那篇的分类方法。

日志量大怎么办

几百兆的日志用文本编辑器打不开，这时候需要按爬虫维度聚合：哪些抓取程序来过、各抓了多少次、集中抓了哪些路径。站里的服务器日志分析工具做的就是这件事，粘进日志片段就能看到爬虫构成与抓取频率分布。

观察周期给多长

至少一个月。llms.txt不像页面那样有稳定的抓取节奏，即使真有厂商来取，频率也可能很低，观察一周就下结论容易得到假阴性。

更实际的建议是：把观察成本也算进决策。如果为了验证效果要花几小时折腾日志，那这个投入本身已经超过了这份文件的价值。设个季度提醒，顺手扫一眼就够了。

写的时候最容易踩哪些坑？

把见过的错误归归类，大部分集中在下面几处。

坑一：把它写成了全站目录

最常见的失败，是把sitemap里的几百条网址一股脑倒进来。这等于放弃了这个文件唯一的价值——人工挑选。一份三百条的清单，信息密度和三十条的没有区别，甚至更差，因为重要的东西被稀释了。

判断标准：如果你没法为清单里的每一条说出“为什么它值得单独被列出来”，那它就不该在里面。

坑二：分区名起得太抽象

“内容”“资源”“其他”这类分区名，对模型定位没有任何帮助。分区名应该像目录标题一样具体，让人只看这一行就知道下面是什么。

坑三：链接用了相对路径

写绝对地址。相对路径依赖读取方正确解析基准网址，不同实现的处理方式可能不同，绝对地址不会有歧义。这款生成器不会帮你补全，填什么就输出什么。

坑五：文件做完了，被指向的页面却打不开

这一条比死链更隐蔽。清单里的网址返回的确实是200，但页面内容依赖脚本渲染，抓取方拿到的源码里几乎是空的；或者页面上有弹窗遮罩，正文被挡在后面。清单把模型引过去了，模型什么也没读到。

检查办法是把清单里的每个网址当成一次抓取来看：状态码对不对、有没有被noindex标记、正文在不在初始源码里。站里的可索引性一键体检把这几项放在一屏上，逐条过一遍不算费事。

坑四：改版之后忘了更新

这是最隐蔽也最致命的一个。llms.txt不像sitemap那样有自动生成机制兜底，改版、换域名、批量调整链接之后，它会安静地失效。等想起来检查时，可能已经全是死链。

处理办法两条：要么把它加进改版检查清单，要么定期用校验器扫一遍链接可达性。后者成本更低。

坑六：把它当成一次性任务

做完上传，然后忘掉——这大概是最普遍的结局。llms.txt的价值几乎全部来自“清单是不是还准”，而准不准会随时间衰减：文章改标题、工具改路径、栏目重组，每一次都在削弱它。

比较省事的节奏是跟着内容大改版走：站点结构调整时顺手更新一次，其余时间不管。真要设提醒的话，一个季度一次足够，用校验器扫一遍链接可达性，两分钟的事。

顺带说一句判断标准：如果你已经三个月没动过这个文件，也想不起来里面列了哪些页面，那它大概率已经不准了。与其留着一份过期清单误导取用方，不如花十分钟重新生成一遍——这比第一次做要快得多，因为分区结构已经定好，只需要核对条目。

常见问题解答

H1之外还有必填项吗？

没有。提案原文说H1是唯一必需的部分，引用块、普通段落、H2分区全都可选。但引用块强烈建议写，模型读到的第一段就是它，省掉相当可惜。

Optional分区是干什么的？

提案对它的定义是：这个分区里的网址在需要更短上下文时可以被跳过。相当于给模型标出“这部分不是核心，装不下就别装”。工具没有为它做专门引导，需要你自己把分区命名为Optional。

链接要写绝对地址还是相对地址？

写绝对地址。相对路径依赖读取方正确解析基准网址，不同实现的处理方式可能不一样。这款生成器不做补全，填什么输出什么。

放多少条链接合适？

几十条是合理量级。这是精选清单不是全站目录，几百条就失去意义了，那种需求该由sitemap.xml承接。内容多的站建议分层：核心的放主分区，次要的放Optional。

描述那一句怎么写才不算白写？

判断标准是：只看这句话能不能判断出什么场景下该点开它。写“关于某某的文章”等于没写，要补充标题没说的信息——用了什么方法、给了什么数据、适合什么情况，二三十个字足够。

llms-full.txt是提案规定的吗？

不是。官方规范举的例子是llms-ctx.txt与llms-ctx-full.txt，区别在于含不含Optional里的链接。llms-full.txt这个名字是社区约定俗成的，用的人多，但严格说不在原始提案里。

生成的文件要放在哪里？

必须放网站根目录，通过域名直接加文件名就能访问，放子目录等于没放。另外建议在robots.txt里显式放行，避免被激进的禁止规则连带挡住。

工具会检查我填的链接是不是有效吗？

不会。它只负责格式拼装，不校验网址可达性，填错了也照样生成。生成之后建议用配套的校验器抽查一遍，改版后再查一次。

输入的内容会上传到服务器吗？

不会。生成逻辑全部在浏览器里执行，没有网络请求，适合给还没上线的项目准备文件。

多语言站点要做几份？

看组织方式。各语言分在不同子域名上就各做各的，因为那是两个独立站点；都挂在同一域名的子目录下就只做根目录一份，用主要语言写，另开一个分区列出各语言入口并注明语种。

这个文件能提升Google排名吗？

没有证据支持。Google在AI功能的官方文档里明确写着出现在AI概览或AI模式没有额外要求、不需要特殊优化。要看完整的判断依据和实测数据，站里那两篇专门算账的文章可以对照着读。

权威参考资料