某天晚上我照着某篇教程给博客加llms.txt，写得还挺认真。开头写一段项目简介，下面按 H2 分组，把文章列表一条条列进去，每条后面跟一句说明。一共二十几篇，写完检查了两遍链接，生怕哪个 404。
加完就没再管。
先补一句这东西到底是什么，知道的可以直接往下翻。llms.txt 就是一个放在网站根目录的纯文本文件，Markdown 格式，里面用一两句话介绍你的站点是干什么的，然后列出你觉得重要的页面链接。名字和 robots.txt 很像，作用也常被拿来类比，但这两件事不一样。robots.txt 是告诉爬虫别去哪，llms.txt 是告诉大模型该看哪。
配套还有个 llms-full.txt，顾名思义，把整个站的内容塞进一个文件。今年的 v2 版本又支持放在子目录里，比如 /docs/llms.txt 只覆盖 docs 下面的页面。
提出这个方案的是 Jeremy Howard，fast.ai 的创始人，2024 年 9 月发的。到现在两年多，一直是社区提案，没有哪个标准组织收编，主流 AI 公司也没公开说过自己在用。
上周不知道为什么想起来这事，跑去服务器上翻日志。
三个月，零
grep 了一下，零。
我一开始以为是日志被轮转了，或者 CDN 把静态文件的访问吃掉了，又换了个路径重新查。robots.txt 三万多条，sitemap 一万多，llms.txt 干干净净，一条都没有。
倒也没多失望，就是有点怪。跟认真写了封信寄出去、对面一直没拆差不多。
查完这两项，我开始怀疑是自己哪里写错了，于是跑去翻了翻别人的情况。
不止我一个人这样
SE Ranking 在 2025 年 11 月发过一份分析，抓了大约 30 万个域名。结论是没有。有没有 llms.txt，跟被 AI 引用的频率之间，找不出统计学上的关联。
他们还跑了个 XGBoost 模型，把 llms.txt 作为一个特征放进去，然后试着把它删掉。删完之后模型准确率涨了。
这个细节我看了好几遍。这个变量对模型来说基本等于噪声，加进去只会拖累预测。
同一份数据里还有个反常的地方：高流量站点用 llms.txt 的比例是 8.27%，中等流量的站点是 10.54%。如果这东西真有用，最该卷的那批站应该用得最多才对，结果正好反过来。
另有一组数字更直接。有个做 AI 流量监测的团队统计了 90 天里 5 亿次 AI 爬虫请求，落到 /llms.txt 上的只有 408 次。我算了一下，大概是百万分之零点八，也可能我算错了。
还有人分析了 13.7 万个网站，28% 确实发布了这个文件，其中 97% 从来没被任何爬虫请求过。
换成更好懂的说法，一百个站里大概有二十八个放了这文件，真正被读过的，不到一个。
Google 那边其实早就说过了，只是没人转
2026 年 5 月 15 日，Google Search Central 发了一份官方指南，标题是《Optimizing your website for generative AI features on Google Search》。里面有一段我抄一下：
您无需为了在 Google 搜索（包括其生成式 AI 功能）中占有一席之地，而专门创建新的机器可读文件、AI 文本文件、标记或 Markdown，因为 Google 搜索本身并不使用这些文件或标记。
后面还补了一句，说你如果是为了别的服务维护 llms.txt 或者其他类似文件，完全没问题，不损害也不提升在 Google 搜索里的排名，因为 Google 会忽略它。
同一份指南顺手把另外几件事也否了。不用把长文切成小块喂给 AI，不用专门为 AI 重写一遍内容，也不用搞什么 AI 专用的 schema。整份文件的核心意思就一句，为生成式 AI 搜索做优化，还是 SEO。
再往前，2025 年 7 月的 Search Central Live 上，Gary Illyes 被问到这事，回答得很直接，Google 不支持，也没有支持的计划。
John Mueller 在 Bluesky 上的说法更损一点。他说这东西跟 keywords meta 标签差不多。
做过早年 SEO 的人应该有印象。当年大家都往页面里塞关键词，塞得越多越好，后来搜索引擎发现这玩意儿谁都能随便写，就彻底不用了。这个类比不太客气，但位置放得很准。
不过这里有个我没想通的地方。
Google 搜索团队说不用，Chrome 团队的态度却有点微妙。Lighthouse 的文档里，llms.txt 被归在 agentic browsing 这一类审计项下面，理由是它能帮 agent 不必爬完整个站才搞清结构。当然这个审计很宽松，文件缺失只显示"不适用"，只有服务器返回错误才报警，因为提供它是可选的。
同一个公司，两个团队的说法不太一样。
我猜是因为他们看的东西不同。搜索团队想的是排名和引用，Chrome 想的是浏览器里的 agent 怎么更省事地理解一个站点。一个是流量问题，一个是交互问题。这两个目标并不冲突，但也没法互相证明。
那它为什么还能火两年
我想到几个原因，不一定对。
一个是成本太低。写个文件十几分钟，不用改架构，不用动代码，做完还有种"我做了点什么"的踏实感。这种投入产出比很难让人拒绝。
再一个是它长得太合理了。给机器人看的说明书，这个说法一听就懂，不用解释。而真正有效的那些事，比如把内容写扎实、把结构化数据弄对、把首屏加载速度提上去，讲起来都很无聊，也没法包装成一个新概念去卖。
还有一个我后来才想明白。OpenAI、Anthropic、Google 自己的开发者文档，首页确实都放了 llms.txt。MCP 项目的文档也是，几乎每一页开头都有一句提示，指向 llms.txt 索引。
看到这个，很容易得出"大厂都在用"的结论。但仔细想想，那些都是文档站，主要读者是编程助手。这跟"搜索引擎会读"完全是两码事。
有用，但不是在你想的那个地方
所以它有用，只是大部分人用错了地方。
如果你的站点是技术文档、API 手册、组件库说明，读者里有相当一部分是 Claude Code、Cursor 这类东西，那 llms.txt 确实有意义。它能让 agent 不用爬完整站就知道你的文档怎么组织、哪几个页面重要。这本来也是这个方案被提出来时的原始场景。
如果你的站点是电商、企业官网、内容博客，指望它提升在 ChatGPT 或者 AI Overviews 里的曝光，目前没有任何数据支持。
有些文章会说 ChatGPT 搜索和 Perplexity 已经把 llms.txt 当成 emerging signal。这个说法我没找到一手出处。而且就算是真的，emerging 的意思也只是"在出现"，离"确定有效"还差得远。
那真正有用的是什么，Google 那份指南里其实写了，只是那段没人转。它说，如果你的内容是任何一个大模型都已经知道的东西，你就不会被引用。能被引用的，是那种只有你能写出来的东西，比如你自己踩过的坑、你们团队当时为什么这么决定、你手上的一手数据。
这段话听起来像场面话，但它是这份文件里少数被明确认可的东西。
另外，robots.txt 得配明白。想让 GPTBot、ClaudeBot、PerplexityBot、OAI-SearchBot 读到你的内容，就得放行；不想被拿去训练，就单独禁 Google-Extended 和 Applebot-Extended。这件事比 llms.txt 重要得多，而且不少人根本没配。
真要写 llms.txt，也别把 sitemap 整个倒进去，那不是它该干的事。挑十几二十个你会主动给新客户看的页面就够了，剩下的交给 sitemap。
我最后没删
写都写了，删掉也没什么意义，反正就几 KB。
只是把它从原来的位置挪到了最后。在我自己的优先级清单上，它现在排在 robots.txt、页面结构、内容质量后面，大概第四或者第五位。
你要是也写了，我建议去翻一下日志。grep 一下 llms.txt，再按 bot 的 UA 过滤，网上有现成的命令可以直接抄。查完可能会有点失落，但总比一直以为自己在做一件有用的事要好。
万一查出来真有几百次请求，那恭喜，你的站点八成是文档站，这东西对你是真有用。
