llms.txt 不是 SEO 项目
今年越来越多网站在根目录放了一份 llms.txt，但会读它的，仍然很少。它不是新的 SEO 排名信号，更像是给已经找到你的网站 Agent 准备的一张目录。
llms.txt 是一段 Markdown：告诉 Agent 这站是什么、哪些页面值得花时间，它不是 robots.txt，拦不住谁，也指挥不了 Google。
放的人在变多，但全网比例并不高
Originality.ai 跟踪 300 万以上域名。2025 年 6 月 4,088 个站有 llms.txt，2026 年 5 月是 36,120 个，截至 2026 年 9 月，仪表盘最新计数已到 136,610。
这是增长，可还不是普及。即使按 300 万域名计算，也只有约 4.6%，距离普及还很远。
读的人几乎没跟上
Ahrefs 看了 137,210 个域名 2026 年 5 月的服务器日志。有有效 llms.txt 的大约 38,000 个站里，97% 当月一个请求都没有。
被请求过的那 3% 里，最大头是 SEO 审计工具，占 21.7%。Chrome Lighthouse 的检查就算在这一类，审计工具在查「你有没有这文件」，不等于模型在用这文件。
有请求的流量里，AI 工具合计大约 19.5%，GPTBot 最多，Claude Code 第二，真正做 AI 搜索召回的 bot 大约 1.1%，文件不存在时，AI bot 基本不会主动去找 /llms.txt。
绝大多数文件没人读，少数被读到的，先是工具在审计自己，其次才是 Agent。
对 Google Search 没有用
Google 在 AI 优化指南里写明：Search（包括 AI Overviews）不用这类文件，有它既不帮助也不损害排名或可见度。
Google AI features and your website
John Mueller 更早把它比作 keywords meta：站点自己宣称自己是什么，要核实，还不如直接看页面。
Search 团队说可以忽略，但 Chrome Lighthouse 又在 Agentic Browsing 里加了可选检查，不过这是两套系统，两件事，别把审计项当成排名信号。
较明确的使用场景主要是编码 Agent
在目前能观察到的请求中，较明确的使用场景主要集中在编码 Agent 和文档工具。Cursor、Claude Code 这类工具在对接 API 或文档时，确实会用 llms.txt 当索引，文档平台也常自动生成一份。这和「每个 Agent 打开任意网站都会先打根目录」不是一回事，更常见的是：文档站自己提示去拉，或用户把 URL 加进规则、MCP、@Docs。
所以这份文件真正服务的对象很清楚：已经找上门来的编码 Agent，给它一张目录。
v2 补的是「怎么找到」
Jeremy Howard（@jeremyphoward）在 2026 年 8 月 10 日发布了 llms.txt v2，是 2024 年提案后第一次修订。v2 提案补充了两种用于发现 Markdown 和说明文件的链接关系，但不同 Agent 的支持程度仍然不一致。
以前 Agent 打开一个 HTML 页，只能猜：这页有没有更干净的 Markdown，这站的说明文件放在哪。v2 加了两种链接关系：
rel="alternate" type="text/markdown"：这页有 Markdown 版rel="describedby"：这页的llms.txt是哪一个
可以写进 HTML 的 <link>，也可以只放在 HTTP Link 响应头，后者在 CDN 配一次就行，页面模板不用改。
同一页的 Markdown 版，两种地址都算数：在原网址后面加 .md（install.html.md），或把扩展名换成 .md（install.md），Agent 不必只猜一种，页面用 rel="alternate" 指过去更稳。
llms.txt 也不必只放根目录。/docs/llms.txt 只管 /docs/ 下面的页，/docs/api/llms.txt 只管更里面的那一层，同一页被多份文件罩到时，路径更具体的那份优先。
按页面分，不要整站当 SEO 项目做
文档页、API 页值得认真写，编码 Agent 真会顺着链接翻，写清楚比写全更重要。
常规营销页、博客列表跟着模板生成一份即可，不必单独维护，Google 不吃这个信号，对这类页面而言单独维护的收益通常很有限。
有文档页就写，没有文档页也别为了审计分数硬造一份。