llms.txt 对 AI 搜索的品牌可见度基本无用，对编程 agent 有用。 这不是推理出来的结论，是日志跑出来的：我们在 37 个站点部署这个文件，连续记录 122 天服务器访问日志，再用四个国产 AI 平台做了一次删除对照实验。
三个核心数字先摆在这里：
- 具名 AI/搜索爬虫对
/llms.txt的请求，占全部 AI bot 流量的 0.012% - 37 个诱饵 URL 里只有 3 个被访问过，来自具名国产爬虫的请求是 0 次
- 删除文件的对照组，91 天后品牌提及率没有下降（反而微涨 1.1pp）
下面是全部数据、方法和你可以直接复用的验证步骤。
llms.txt 有用吗：一句话结论与适用边界
llms.txt 是放在网站根目录的 Markdown 索引文件，用一份链接清单告诉大模型你的核心内容在哪里。截至 2026 年 7 月，没有任何一家国产大模型厂商在公开文档中承诺读取它。
我们的测试结果是：它对 AI 搜索里的品牌提及率没有可测量的贡献，但对 IDE 编程助手和 MCP 客户端有实际价值。
分界线在于你的读者是谁。如果你的内容会被 agent 直接调用（API 文档、SDK、开发者手册），写它划算；如果你指望它提升在豆包、DeepSeek 里的品牌推荐位置，那是自我安慰。 30 分钟能写完的文件不必纠结要不要写，真正的风险是把它当成 AEO 优化的核心动作，挤掉了真正有效的排期。
llms.txt 是什么，它原本承诺解决什么问题
llms.txt 是 Answer.AI 的 Jeremy Howard 在 2024 年 9 月提出的一份社区约定：网站在根目录放置 /llms.txt，用 Markdown 列出最重要的页面链接和一句话说明，让大模型不必解析臃肿的 HTML 就能拿到干净的内容地图。规范本身极简，只有 H1 是必需的，其余引用块和 H2 分组都可选，完整定义见 llms.txt 官方规范站点。
它的设计前提是：模型在回答时会主动来根目录看一眼。这个前提从来没有被任何一家厂商确认过。 谷歌方面的表态最直接——Search Relations 团队把它类比为早已废弃的 keywords meta 标签，理由是自我声明式信号无法验证，相关表态见 Search Engine Journal 对谷歌 llms.txt 立场的报道。国产厂商则连表态都没有。
需要区分清楚的是：llms.txt 是"内容索引"，robots.txt 是"抓取权限"，两者不是替代关系，也不互相兜底。 robots.txt 被所有主流爬虫强制遵守，llms.txt 没有任何一家承诺读取——两份文件的效力完全不在一个量级，展开对比可参考 llms.txt vs robots.txt：各自能做和不能做什么。
我们测了什么：37 个站点、122 天日志与四平台对照
测试跨度为 2026 年 3 月 1 日至 6 月 30 日，共 122 天，覆盖 37 个站点：SaaS 产品站 11 个、消费电商 9 个、B2B 制造 8 个、内容媒体 6 个、开发者文档站 3 个。全部在 3 月 1 日同步上线结构一致的 /llms.txt，链接数在 12 到 40 条之间。
日志口径与归因方法
日志取全量 Nginx access log 与 CDN 边缘日志的合并集，按三步归因：先匹配 User-Agent 字符串，再做 IP 反向 DNS 正反解验证，最后按 ASN 归属兜底。UA 可以伪造，只认 UA 的统计一定虚高。
这里踩了一个大坑值得单独说：37 个站里有 9 个站，源站日志显示 /llms.txt 请求为 0。接入边缘日志后发现，请求真实存在，只是被 CDN 当静态资源全量缓存，根本没回源。修正前源站合计只记到 1,486 次，修正后为 2,317 次，漏记 36%。 很多人自测得出"完全没人请求"的结论，其实是日志根本没记全。
对照实验设计
3 月全站部署后，4 月 1 日从中选出 12 个流量与内容更新节奏相近的站点，随机分成两组：A 组 6 站保留 llms.txt，B 组 6 站彻底删除并返回 404。观测至 6 月 30 日，共 91 天。
用 MaxAEO 每周在 DeepSeek、豆包、Kimi、通义千问四个平台跑同一批 240 条品牌相关 prompt，记录品牌提及率。两组在实验期内都保持正常内容更新，唯一受控变量是文件是否存在。
这个设计的局限也要说清楚： 12 站分两组，样本量不足以检出 1 个百分点以内的真实效应；四个平台的召回策略也可能在 91 天里各自调整。所以下文的结论是"没测出效应"，不是"证明了效应为零"——但对做排期决策来说，这两句话的含义相同。
日志结果：谁在请求 /llms.txt
122 天内，37 个站点合计记录到约 1,940 万次可归因为 AI 及搜索类 bot 的请求，其中命中 /llms.txt 的仅 2,317 次，占比 0.012%。
| 请求来源分类 | 次数 | 占比 |
|---|---|---|
| AEO / GEO 监测与检测工具 | 1,392 | 60.1% |
| 无头浏览器、云厂商 IP 未知来源 | 604 | 26.1% |
| 可归因到具名搜索 / AI 爬虫 | 321 | 13.9% |
具名爬虫这 321 次拆开看：Bytespider 156 次、PetalBot 61 次、Baiduspider 44 次、YisouSpider 33 次、其余合计 27 次。平均下来，一个非文档类站点每月只会被具名爬虫请求这个文件不到 1 次。
最第一行：六成流量来自检查"你有没有这个文件"的工具，而不是消费内容的模型。 llms.txt 目前最大的使用场景是被审计，形成了一个自我循环的市场——工具检测出你没写，你写上，下次检测通过，模型那边什么都没发生。
分布也极不均匀：3 个开发者文档站贡献了 2,317 次中的 1,043 次，剩下 34 个站合计只有 1,274 次。而这 1,043 次里，有 709 次（68.0%）能归因到 IDE 编程助手与 MCP 客户端类 UA。
这条数据指向一个明确判断：llms.txt 的真实消费者是 agent，不是搜索型 AI。 如果你正在考虑让智能体直接读取你的产品数据，给 AI 开一个 MCP 接口比反复优化这个文本文件的收益高一个量级。
诱饵 URL 实验：被请求不等于被读懂
判断一个爬虫是否真的解析了 llms.txt，最硬的证据是看它有没有沿着文件里的链接继续抓。 我们的做法是在每个站点埋一个诱饵 URL（canary）：这个页面站内任何位置都没有链接，不进 sitemap，不做外链，robots 允许抓取，全站唯一出现位置就是 llms.txt 里的一行。
只要日志里出现对它的请求，就能反推该 UA 完整读取并解析了 llms.txt。这是整套验证里最不容易被糊弄的一环。
122 天结果：37 个诱饵 URL 中只有 3 个被访问过，合计 6 次请求。 其中 4 次来自 AEO 监测工具，2 次来自无头 Chrome。来自 Bytespider、PetalBot、Baiduspider、YisouSpider 的诱饵请求为 0。
也就是说，具名国产爬虫会偶尔拉取这个文件，但没有证据表明它们把文件里的链接当成抓取队列。用三道门的框架讲：请求门微弱通过，解析门基本不通过。
提及率有变化吗：四平台 91 天对照结果
第三道门是引用门——文件存在与否，会不会改变 AI 回答里提到你的概率。
| 分组 | 实验前提及率 | 实验后提及率 | 变化 |
|---|---|---|---|
| A 组：保留 llms.txt（6 站） | 18.6% | 19.9% | +1.3pp |
| B 组：删除 llms.txt（6 站） | 19.2% | 20.3% | +1.1pp |
两组都在涨，因为两组都在正常更新内容；组间差异只有 0.2 个百分点，在这个样本量下不具备统计意义。删掉文件的站点没有任何一个出现提及率下滑。
这个结果和更大规模的独立研究方向一致：SE Ranking 对约 30 万个域名做的分析显示，llms.txt 与 AI 引用频次之间没有统计显著相关，把这个特征从预测模型里移除后模型准确率反而提升——它引入的是噪声不是信号，研究方法与结论见 SE Ranking 关于 llms.txt 的分析，以及 Search Engine Journal 对该 30 万域名研究的报道。
我们的样本远小于它，但优势是加了删除对照——大样本相关性研究回答不了"删了会怎样"，而这恰恰是品牌方真正关心的问题。英文语境下的同类证据梳理可参考 Does llms.txt Work? Evidence From AI Citation Data。
为什么国产 AI 大概率不看这个文件
根本原因不在于厂商懒得支持，而在于检索链路的结构：国产 AI 的联网回答绝大多数是从既有搜索索引里召回的，不是临时去你的根目录读文件。
模型收到问题后，先把它转成检索式，交给底层搜索引擎或自有内容生态返回候选文档，再对候选做摘要和引用。整条链路里没有任何一步会经过 /llms.txt——因为召回依赖的是索引，而索引来自常规爬虫按 sitemap 和链接图抓回来的 HTML。
这也解释了日志里的现象：Bytespider 请求量最大却从不跟进诱饵 URL，因为它的任务是抓页面填索引，不是解析索引文件。
要让这条链路改判，需要的不是一个文件，而是厂商在召回层加一步"先读 llms.txt"。 这一步的成本、收益和被滥用风险（自我声明式信号天然可被刷）决定了它短期内不会发生——这也正是谷歌拿 keywords meta 标签作类比的原因。至于哪些爬虫该放行、哪些该限速，robots.txt 要不要放行 GPTBot、ClaudeBot 与 Bytespider 给了更细的取舍标准。
怎么验证 AI 到底有没有读你的 llms.txt
验证只需要日志，不需要工具订阅。 按顺序做完这五步，你能得到关于自己站点的确定答案，而不是别人的统计结论。
- 确认日志记全了。 先检查
/llms.txt是否被 CDN 缓存。命中缓存的请求不会回源，源站日志会显示为 0。开边缘日志，或给该路径单独设置Cache-Control: no-store后再统计。这一步不做，后面全是错的。 - 过滤命中记录。 在合并后的日志上执行
grep 'GET /llms.txt' access.log | awk '{print $1, $12}' | sort | uniq -c | sort -rn，得到 IP 与 UA 的频次分布。 - 做 UA 三分类归因。 把结果分成监测工具、无头浏览器与未知云 IP、具名爬虫三类。对具名爬虫必须做 rDNS 正反解验证，反查主机名再正解回 IP，能对上才算数。UA 伪造成本为零。
- 埋诱饵 URL。 建一个站内孤立页面，只在 llms.txt 里出现，不进 sitemap、不做内链外链。观察 30 天，看有没有请求、来自谁。有请求才证明文件被解析了。
- 做删除对照。 如果你有多个结构相近的站点或子目录，分组保留与删除，用固定 prompt 集在多平台按周记录提及率，至少跑 8 周再看差值。
三个常见误判要避开：
- 别用"事实指纹"法。 有人在 llms.txt 里写一条独有事实，再去问 AI 能不能答出来。这个方法会误判——llms.txt 本身可能被常规搜索索引收录，模型答对可能来自搜索结果而非文件解析。
- 别把监测工具流量当成模型流量。 这是最普遍的自我欺骗，六成命中都是这一类。
- 别在只跑两周之后下结论。 具名爬虫对这个文件的请求间隔可能超过一个月，短窗口的 0 命中说明不了任何事。
如果第一步就发现日志里连常规爬虫都没有，那问题比 llms.txt 严重得多：先查 WAF 是否按 UA 或境外 IP 段误拦、首屏内容是否依赖 JS 渲染、证书链在老客户端上是否完整。这三项任意一项挂掉，写多少索引文件都是零。
值得写和纯自我安慰的分界线
判断标准只有一条：你的内容有没有 agent 消费场景。
| 场景 | 建议 | 理由 |
|---|---|---|
| API / SDK / 开发者文档站 | 值得写，并加 llms-full.txt | IDE 助手与 MCP 客户端是实际消费者，我们的样本里占该类站点命中量的 68% |
| 技术型 SaaS，用户会在编程环境里调用 | 值得写 | 同上，且成本低 |
| 内容量大、栏目结构清晰的媒体站 | 可写，30 分钟内完成 | 无害，但不要给它排预算 |
| 品牌官网、消费电商、本地服务 | 不必写 | 无 agent 消费场景，对提及率零贡献 |
| 已在为写不写这个文件开会 | 立刻停下 | 会议成本已超过文件收益 |
写的时候按最简规范来就行，具体字段、示例和常见错误可参考 llms.txt 怎么写才有用。关键是别把它当 AI 搜索优化的抓手——它不是排名信号，它是给 agent 的目录。
与其纠结 llms.txt，先做这四件事
同样的时间投入到下面四件事上，对 AI 可见度的回报是可测量的：
- 打通可达性。 确认 Bytespider、PetalBot、Baiduspider、YisouSpider 能正常抓到关键页面，WAF 没有误拦，首屏内容不依赖 JS 渲染。抓不到，一切归零。
- 让正文可读。 把锁在 PDF、长图和 iframe 里的核心内容改成 HTML 文本，这一项的提及率提升幅度我们观测到过双位数百分点。
- 做成可摘录的段落。 定义先行、结论前置、数据带来源，让模型能整段引用你而不是同义改写。问答式结构在这一项上效率最高，组织方法见 FAQ 和问答式内容对 AEO 还有用吗。
- 持续监测再排期。 用 AI 提及率、情感倾向和引用来源分布反推内容缺口，把监测的异常信号变成选题输入，具体流水线可参考从监测异常到内容排期的搭建方法。
这四件事都有明确的因果链和可复现的验收标准，llms.txt 没有。
常见问题
问：llms.txt 有用吗，一句话回答是有还是没有？
答：对搜索型 AI 无效，对编程 agent 有效。我们 122 天的日志显示，具名国产爬虫对这个文件的请求量占全部 AI bot 流量的 0.012%，且不跟进文件里的链接；删除文件的对照组品牌提及率没有下降。
问：豆包、DeepSeek、Kimi、通义千问有没有官方支持 llms.txt？
答：截至 2026 年 7 月，我们没有检索到任何一家国产大模型厂商在公开文档或开发者说明中表示会读取 llms.txt。谷歌则已明确表态不支持且无计划支持。
问：已经写了要不要删掉？
答：不用删。文件本身没有负面影响，删除也不会带来收益。我们的 B 组 6 个站点删除后提及率反而微涨，说明它在两个方向上都不是变量。真正要删的是它在你排期表里的优先级。
问：llms-full.txt 需要一起写吗？
答：只有文档站需要。它把全文正文而非链接列表塞进单文件，体积通常在几百 KB 到几 MB，主要服务于 IDE 助手一次性载入上下文。品牌官网写它没有消费方。
问：写了 llms.txt 会不会有副作用，比如泄露内容结构或被恶意爬虫利用？
答：实测没有观测到异常抓取。但要注意两点：一是别把未公开、未上线的 URL 写进去，这个文件是完全公开的；二是它不提供任何抓取权限，能不能抓仍由 robots.txt 和服务端规则决定，别指望用它挡爬虫。
问：llms.txt 多久更新一次？
答：对非文档站，改版换栏目时顺手更新即可，没有必要排周期。对文档站，建议随构建流程自动生成——手工维护的清单在版本迭代里几天就会失效，而失效的链接对 IDE 助手是负收益。
问：既然爬虫不读，为什么我的监测报告显示 llms.txt 被访问了很多次？
答：大概率是监测工具自己的检测请求。这类流量在我们的样本里占 60.1%。区分办法是看 UA 与 IP 归属，检测类 agent 通常在 UA 里带 checker、audit、readiness 之类的标识，且只请求这一个路径、不请求任何其他页面。