llms.txt：一个新约定，值不值得跟

如果你今年读过任何关于「如何被 AI 引用」的内容，一定见过 llms.txt。它就是一个放在站点根目录的 Markdown 文件，列出你最希望语言模型读到的那些页面。

做一份大概花二十分钟。它到底有没有用，是另一个问题。

它到底是什么

这个约定刻意做得极简——站点根目录下一个 /llms.txt，纯 Markdown，没有 schema：

# 你的站点

> 一句话说明这个站点是什么。

## 核心页面
- [首页](https://example.com/)：讲什么
- [关于](https://example.com/about)：谁在做

## 文章
- [某篇文章](https://example.com/blog/some-post)：论证了什么

它的想法是：模型在决定抓什么的时候，能拿到一份人工整理的清单，而不是从导航里猜。

它不是什么

有三件事值得说清楚，因为大多数介绍都跳过了：

它不是标准。 没有任何标准组织批准过它，也没有任何厂商承诺遵守它。它只是一个被不少站点采纳的提议。

它没有强制力。 和 robots.txt 一样是自愿遵守的。但与 robots.txt 不同的是，它甚至不是一个抓取器早就围绕它建好的老约定——所以不存在「已经读它的实现」这回事。

它替代不了基本功。 如果你的正文是客户端渲染的，一份指向它的 llms.txt 什么都改变不了：抓取器到了那里，看到的还是空壳。先把那个修了。

那为什么还值得做

两个理由，都不是「它能提升排名」：

1. 成本几乎为零，而且可以自动生成。 我们自己的那份是个路由处理器，读的就是博客列表用的同一份文章清单。发文时它自己就更新了。边际成本是零。

2. 它是一句没有歧义的意图声明。 模型也好、人也好，想知道哪些页面是你的正文而不是样板，你用一个文件回答了，不用让对方去猜。

理由就这些。它便宜、它清楚、它也许有用。

怎么检查你的那份

要验两件事，第一件能抓住大部分错误：

curl -s https://your-site.com/llms.txt

应该返回 200 和真正的 Markdown。最常见的失败是文件存在但里面没有链接——我们自己的审计里有一条规则专门查这个，因为一堆没有 URL 的标题，等于没告诉模型该去哪儿。

不想手动 curl 的话，llms.txt 工具会一并告诉你文件在不在、格式合不合格，并顺手从你的 sitemap 生成一份草稿。

然后确认里面的地址真的能打开。llms.txt 里的死链比不放这个文件更糟：那是你自己指出来的。

诚实的小结

加上它吧，花那二十分钟。但别指望它自己带来流量——在真正决定你会不会被引用的那些事里，它只是一个便宜的小信号：内容服务端渲染、robots.txt 放行抓取器、结构化数据，以及你本来就有值得被引用的东西。

最后一条占了大部分功劳。