llms.txt 校验器

📖 llms.txt 校验器使用说明

llms.txt 是放在网站根目录的一个 Markdown 文件，用来告诉大模型"这个站最值得读的内容在哪里"。它由 Jeremy Howard 在 2024 年提出，思路类似 robots.txt 和 sitemap.xml，区别在于它面向的是模型的阅读需求：给一份人工挑选过的、带简短说明的核心链接清单，而不是把整站丢过去。

这款工具抓取你站点的 llms.txt，按提案定义的结构逐项校验，并抽样验证里面的链接还能不能打开。站里已经有一个 llms.txt 生成器负责产出文件，这一款负责检查产出的东西是否合规、有没有随时间烂掉。

一、规范长什么样？

提案对结构的要求很简洁，但顺序是固定的：

• 一个 H1，写站点或项目名称。这是唯一必填项。
• 一个引用块（以大于号开头），一两句话说清这个站是做什么的。这部分可选但强烈建议写，模型读到的第一段就是它。
• 若干普通段落，补充说明。可选。
• 若干 H2 分区，每个分区下面是链接列表，每条格式为 - [名称](URL): 说明。说明部分可选，但写了对模型帮助很大。
• 一个名为 Optional 的 H2 分区（可选）。放在这个分区里的链接被视为次要资源，上下文紧张时可以跳过。这是提案里一个容易被忽略但很有用的设计。

校验器会逐项检查这些结构，同时标出常见的写法问题：链接用了相对路径、条目缺少说明、分区为空、以及整个文件是否大到失去了"精选"的意义。

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

llms.txt 是索引，llms-full.txt 是全文。前者给链接和说明，模型按需去取；后者把主要内容直接拼在一个文件里，模型一次读完不用再发请求。

两者各有取舍。索引式的文件小、维护简单，但模型需要多次抓取，而且它抓不抓得动你的页面还要看你的站是不是需要 JavaScript 渲染。全文式的一次到位，代价是文件可能几百 KB 甚至几 MB，超出很多模型单次能吃下的量，也更难保持同步。

实践上的建议是两个都提供：llms.txt 做精选索引，llms-full.txt 给需要完整内容的场景。这款工具会同时检测两个文件是否存在，并给出体积。

三、写 llms.txt 有用吗？

这里需要说实话：到目前为止，没有任何一家主流 AI 厂商公开确认会读取 llms.txt。它是一个社区提案，不是被采纳的标准。日志里能看到的抓取，多数来自各类第三方工具和研究爬虫，而不是 ChatGPT、Claude 或 Gemini 的官方抓取程序。

那为什么还建议写？三个理由：一是成本极低，一个文件几十行，写一次维护成本接近于零；二是它是可赌的期权，如果哪天被采纳，早写的人不用临时补；三是写这个文件的过程本身有价值——被迫想清楚"我这个站最值得被读的十几篇内容是哪些"，这个梳理对内容策略有实实在在的帮助。

但不要把它当成 GEO 的主要抓手。真正影响 AI 引用的仍然是内容本身的质量、结构和可抓取性，llms.txt 顶多是锦上添花。把精力放在让正文自包含、结构清晰、事实密度高上面，回报率高得多。

四、这款工具做不到什么？

• 它校验的是社区提案，不是正式标准。提案本身还在演进，各家实现的解读也不完全一致，所以这里的"不合规"更准确的说法是"与提案的建议写法不一致"。
• 它只抽样验证链接。为了控制耗时，最多验证前 24 条链接的可达性，不会把几百条全跑一遍。
• 它不判断内容质量。链接指向的页面写得好不好、说明写得准不准，工具看不出来。
• 它不检测更新时效。llms.txt 最容易出的问题是站点改版后文件没跟着更新，工具只能通过死链间接反映这一点。
• 它不代表模型会怎么用这个文件。前面说了，目前没有厂商公开确认读取行为，任何关于"写了就会被引用"的说法都没有依据。