llms.txt 是放在网站根路径、写给大模型看的一份 Markdown 内容清单，「要不要放」是做 GEO 常被问到的一句。我们 2026 年 7 月 8 日在自己的站点上放了一份，到 10 月 15 日满 100 天；这 100 天里 nginx 访问日志一共 104,645 行，本文只回答一件事：各家 AI 抓取器到底来不来取它？
五个读数如下；每个数怎么算、身份怎么核、出处在哪，后面各节分别交代：
- 能核验身份的 AI 抓取器，100 天里取 llms 文件 0 次。 站上能取到的 llms 文件有五个地址（根路径和三个应用路径下的 llms.txt，加上产品站的 llms-full.txt）。这期间 llms 文件的请求一共 210 次：五个地址 196 次，另有 14 次取根路径的 llms-full.txt（那里没有文件，返回 404）；没有一次来自能核验身份的 AI 抓取器。
- 同一批抓取器，取 robots.txt 和 sitemap 取了 3,791 次。 OpenAI、Anthropic、Perplexity、Amazon 的 7 个名字核验通过的请求里，robots.txt 1,222 次、sitemap 2,569 次；OAI-SearchBot 100 天里天天取 robots.txt，GPTBot 天天取 sitemap。它们也取页面，取页面成功 666 次。
- 自报 AI 抓取器或搜索引擎蜘蛛名字来取 llms 文件的 23 次，全是我们自己。 22 次是我们做站点检查时用 curl 冒用 Googlebot 的名字，1 次是我们用 Anthropic 的命令行编程工具 Claude Code 取文件时留下的 Claude-User。
- 210 次里，能确认是我们自己的至少 124 次。 其中 17 次是我们自己的产品（引见 YinJen）做网站诊断时发出的，User-Agent 写的是普通浏览器。210 次里其余的 86 次是命令行和脚本请求、三个第三方网站数据采集程序，以及 User-Agent 像普通浏览器、认不出是谁的请求（见第二节）。
- 把窗口往前推到日志开头（6 月 6 日），核验通过的 AI 抓取器也只碰过 llms 文件一次。 7 月 7 日文件还没上线，一个核验通过的 Claude-User 取过根路径
/llms.txt，返回 404。
落到 GEO 上：llms.txt 可以放，成本低；但别把品牌名、运营主体、能力范围这类关键事实只放在它里面。AI 抓取器真来取的是 robots.txt、sitemap 和页面本身，关键事实要写进服务器直接返回的 HTML。
先交代利益：引见 YinJen 是我们自己的产品，一款监测品牌在 12 个 AI 引擎里可见度的 GEO 工具，它的文章页和产品页就挂在这个站上，所以这是自家站点的日志。只有一个站的读数，算不上行业均值。上一篇也用过这份日志（那篇看抓取器取页面之后执不执行脚本）；本文主要看 llms.txt 这类机读文件，第三节有个别数和那篇相同（Claude-User 取 robots.txt 的 12 次、Perplexity-User 名下的 283 次）。
一、口径
| 项 | 取值 |
|---|
| 数据来源 | zhimahang.com 的 nginx 访问日志：这是苏州智码航科技有限公司自己的站点，引见 YinJen 的文章页和产品页都挂在上面 |
| 窗口 | 北京时间 2026-07-08 00:40:51（产品站的 llms.txt 首次返回 200）至 10-16 00:00（不含），窗口内末行是 10-15 23:55；按日期数是 07-08 至 10-15 共 100 天，104,645 行，期间日志没有轮转 |
| llms 文件 | 路径以 /llms.txt 或 /llms-full.txt 结尾的请求，不论返回什么状态码。能取到的有五个地址：根路径 /llms.txt（由网关转到产品站那一份，内容逐字节相同）、产品站路径下的 llms.txt 和 llms-full.txt、另外两个应用路径下各一份 llms.txt；根路径 /llms-full.txt 没有文件，返回 404 |
| robots.txt、sitemap | 路径以 /robots.txt 结尾，或文件名以 sitemap 开头、以 .xml 结尾的请求；按请求次数算，含 301 跳转和 304「未修改」 |
| 取页面成功 | 返回 2xx 的页面请求；脚本、样式、图片、字体这类静态资源，robots.txt、sitemap、llms 文件和 _rsc 预取，都不算页面 |
| 抓取器名字怎么认 | 看请求头 User-Agent 里写的名字。我们事先列了一张名字表：AI 抓取器、搜索引擎蜘蛛等 34 个，另加豆包 App 的内置浏览器；不分大小写，按表里的顺序逐个比，先比中的算数 |
| 身份核验 | 拿运营方自己公布的地址名单对：OpenAI、Anthropic、Perplexity、Amazon、Google、微软；同一个名字、但来自名单之外的请求，不算这个抓取器 |
| 取数 | 日志：2026-10-16 22:14～22:30 经 ssh 分五次汇总，程序只读日志、在内存里计数、只打印计数，服务器上没留文件；核验名单 22:12～22:13 下载；第二节那 17 次诊断请求，10-17 00:13～00:15 又只读复核了一次原始 User-Agent 和产品后台的诊断记录。文件核对：22:18～22:28 用 curl 取本站的 llms 文件、robots.txt、四份 sitemap 和产品站首页，都在日志窗口之后 |
| 隐去的 | 访问方的 IP 地址一律不写 |
| 时区 | 日志按北京时间（+0800）记录，文中日期一律用北京时间 |
二、llms 文件被请求了 210 次，都是谁
| 来源（按 User-Agent 分） | 次数 | 其中能确认是我们自己的 | 能核验为 AI 抓取器的 |
|---|
| 自报 AI 抓取器或搜索引擎蜘蛛的名字（Googlebot 22、Claude-User 1） | 23 | 23 | 0 |
命令行和脚本（curl 112、User-Agent 只写 Mozilla/5.0 的 4、自报一个网站体检脚本名的 14） | 130 | 84 | 0 |
| 三个第三方网站数据采集程序（做站点技术画像、商业数据的那类，自报名字，不是 AI 引擎的抓取器） | 14 | 0 | 0 |
| 我们产品引见 YinJen 的网站诊断功能（User-Agent 是诊断程序里写死的一串普通浏览器标识，认法见读法第 2 条） | 17 | 17 | 0 |
| User-Agent 像普通浏览器、认不出是谁 | 26 | 0 | 0 |
| 合计 | 210 | 124 | 0 |
按地址分：根路径 /llms.txt 84 次，产品站的 llms.txt 80 次，另外两个应用的 llms.txt 18 次，产品站的 llms-full.txt 14 次，根路径 /llms-full.txt（没有文件）14 次。
读这张表：
- 名字表里的 34 个名字，只有两个取过 llms 文件，而且都没通过核验。 其余 32 个名字，包括 GPTBot、OAI-SearchBot、ChatGPT-User、ClaudeBot、PerplexityBot、Bytespider、Meta 的几个名字、Applebot、百度蜘蛛和 Kimi 的抓取器，按自报计也是 0 次：连借这些名字冒充的请求，都没来取过 llms 文件。
- User-Agent 像普通浏览器的 43 次里，17 次是我们自己产品的网站诊断，其余 26 次认不出是谁。 引见 YinJen 的网站诊断会取站点根路径的
/llms.txt，文件正常再取 /llms-full.txt，用的 User-Agent 是程序里写死的一串 Windows 版 Chrome 标识。这 17 次和这串逐字相同，分 9 批，都在 7 月 10 日 23:33 到 11 日 21:04 之间：每批前后 20 秒内，同一地址都用这串标识取了首页；8 批还取了诊断程序要查的 /.well-known/ai.txt；9 批里 8 批在 1～3 秒内先后取了 /llms.txt 和 /llms-full.txt。前 8 批是这几项检查开发期间我们开发环境里跑的：其中第 2～7 批（7 月 10 日 23:40～23:58 的 6 批）就用到了取 /llms-full.txt 和 /.well-known/ai.txt 的两项检查，而这两项检查 7 月 11 日 00:06 才提交进代码库。最后 1 批来自我们自己的服务器，12 秒后服务器上留下了我们自己账号诊断本站的记录。认不出的 26 次全是同一个模式：先请求一次、拿到 301 跳转（http 转 https），再换一个地址取一次，12 对在 1～2 秒内，另有 1 对隔了 4 秒，像用轮换代理的扫描程序。它们不自报名字，本文不把它们算作任何抓取器。 - 命令行请求里有 46 次没留下第四节说的四条线索，本文不算进「我们自己」。 所以 124 是下限。
- 窗口之前还有一次。 7 月 7 日 09:12，文件还没上线，一个核验通过的 Claude-User 取过根路径
/llms.txt，返回 404。Claude-User 是 Anthropic「按用户提问去取页面」的名字，这次是谁的提问触发的，日志看不出来。从 6 月 6 日日志开头到窗口截止，核验通过的 AI 抓取器取 llms 文件的，只有这一次。
三、同一批抓取器取了什么
下表只算核验通过的请求，窗口同上：
| 名字 | 运营方 | robots.txt（有请求的天数） | sitemap（有请求的天数） | llms 文件 | 取页面成功 |
|---|
| OAI-SearchBot | OpenAI | 681（100 天） | 0 | 0 | 100 |
| GPTBot | OpenAI | 0 | 348（100 天） | 0 | 125 |
| ChatGPT-User | OpenAI | 0 | 0 | 0 | 177 |
| ClaudeBot | Anthropic | 503（52 天） | 2,221（52 天） | 0 | 129 |
| Claude-User | Anthropic | 12（7 天） | 0 | 0 | 6 |
| PerplexityBot | Perplexity | 24（18 天） | 0 | 0 | 49 |
| Amazonbot | Amazon | 2（2 天） | 0 | 0 | 80 |
| 以上 7 个名字合计 | — | 1,222 | 2,569 | 0 | 666 |
| 对照：Googlebot | Google | 322（95 天） | 116（87 天） | 0 | 767 |
| 对照：bingbot | 微软 | 84（55 天） | 475（98 天） | 0 | 630 |
读这张表：
- robots.txt 和 llms.txt 都放在约定的根路径上，前者天天有人取，后者没有。 OAI-SearchBot 100 天里每天都取 robots.txt，GPTBot 每天都取 sitemap，ClaudeBot 在 52 天里取过 robots.txt、52 天里取过 sitemap。同样在根路径上的 llms.txt，它们一次没取。
- 按用户提问去取页面的名字也没取。 ChatGPT-User 取页面成功 177 次、Claude-User 6 次，都没取过 llms 文件。
- Claude-SearchBot 名下 159 次、Perplexity-User 名下 283 次请求，一次都没通过核验，表里不列；按自报计，它们取 llms 文件也是 0 次。GoogleOther（Google 的通用抓取器，不专属 AI）核验通过的请求里，llms 文件同样是 0。
- 表里是请求次数，不代表读了什么内容。 robots.txt 的请求里有 301 跳转和 304「未修改」，比如 OAI-SearchBot 的 681 次里返回 2xx 的是 446 次。
四、自报名字的 23 次：怎么认出是我们自己
名字可以冒用，所以先核验；没通过核验的，再看是不是我们自己发的。我们按四条线索认自己的请求，满足任一条的地址算我们的：
- User-Agent 里带我们自测时加的标记（3 个地址）。
- 我们自己的工作会话记录里，前后 2 分钟内有用 Claude Code 取站点文件的操作（2 个地址）。
- 自称 Googlebot、却不在 Google 名单里来取 llms 文件的请求：时间对得上我们 5 次站点检查的记录，那几次检查都写明顺带取了 llms 文件（2 个地址）。
- 上一篇用同一份日志认出来的、10 月 9～10 日的自家地址（2 个地址）。
去掉重叠，一共 8 个地址，它们发的 llms 请求有 107 次；加上第二节按请求本身认出的、我们产品网站诊断的 17 次，共 124 次，占 210 次的一半多。具体到自报名字的 23 次：
- Googlebot 22 次：分布在 9 月 23 日到 10 月 13 日的 5 个时段，每次都在一分钟内把几份 llms 文件各取一遍，来自 2 个不在 Google 名单里的地址。这是我们做站点检查时，用 curl 带着 Googlebot 的 User-Agent 扫自家站点留下的。
- Claude-User 1 次：9 月 6 日，User-Agent 写明来自 claude-code，地址不在 Anthropic 公布的名单里；我们的会话记录里，早几秒有一次用 Claude Code 取这个文件的操作，9 秒后同一地址又用只写
Mozilla/5.0 的 User-Agent 取了两次。这是我们自己在查文件。
所以，想数自己站上的 llms.txt 有没有人读，要先剔掉自己：我们这 210 次里，一半多是我们自己。
五、站点前面有没有 CDN 把请求挡掉
源站日志只记录到达源站的请求。如果站点前面的 CDN 缓存了 llms.txt，抓取器取到的是缓存，源站就看不到。我们的情况分两段：
- 7 月 8 日至 8 月 8 日（32 天），站点前面有 Cloudflare 代理。 这段时间日志里 91.4% 的请求经 Cloudflare 的节点转来，llms 文件被请求 32 次。同一个地址几秒到几分钟内连着取 llms.txt，每一次都记在了源站日志里（比如 7 月 10 日 25 分钟里 7 次，都不带查询参数），看不出被边缘缓存截走。但这只说明这几次没被截走，不能排除别的请求被缓存挡掉。
- 8 月 9 日起不再经过代理，之后经 Cloudflare 节点转来的请求只剩 2.3%（我们没去分辨是哪类客户端）。只看这 68 天：第三节那 7 个名字核验通过的请求，取 robots.txt 964 次、sitemap 1,825 次、llms 文件 0 次。
六、对做 GEO 意味着什么
可以这样用：
- llms.txt 可以放，但别指望靠它让 AI 抓取器读到你。 它成本低，按用户指令去取文件的编程助手会读（我们自己就用 Claude Code 取过）；但在我们这个站上，100 天里能核验的 AI 抓取器一次没取。我们自己的产品引见 YinJen 在网站诊断里也查 llms.txt，把缺 llms.txt、缺 llms-full.txt 都列为低影响项。品牌名、运营主体、能力范围这类关键事实，要写进服务器直接返回的 HTML：它们真来取的是页面，第三节表里核验通过的取页面成功 666 次。页面怎么写才不依赖浏览器端脚本，见上一篇。
- 把 robots.txt 和 sitemap 写对、保持最新。 这两样是 AI 抓取器真来取的机读文件：OAI-SearchBot 天天取 robots.txt，GPTBot 天天取 sitemap。robots.txt 别误拦 AI 答案引擎的抓取器，sitemap 要列全、有新页面及时更新（写法见延伸阅读里讲 robots.txt 和 sitemap 的那篇）。
- 想知道你站上的 llms.txt 有没有人读，数自己的日志。 按路径找出 llms 文件的请求，按 User-Agent 分组，再用运营方公布的地址名单核验；先剔掉自己的请求。
别这样用：
- 本文不构成对任何收录或排名的承诺。
放不放 llms.txt，都不代表会不会被 AI 引用。
- 不能外推到别的站。 这里只有一个站、一份源站日志、100 天；别的站、别的时段可能不同。
- 「日志里 0 次」不等于 AI 用不到 llms.txt 里的内容。 它们可能从别处拿到同样的内容，也可能以后会来取；这份日志只说明，这 100 天里能核验的 AI 抓取器没有来源站取它。
七、读这组数要注意的地方
- 我们的 llms.txt 没被任何地方引用。 robots.txt、产品站首页和四份 sitemap 里都没有指向它的链接，抓取器只能按约定路径自己来找。如果在页面或 robots.txt 里加上链接，结果可能不同，我们没测。llms.txt 里倒是链了 llms-full.txt。
- llms-full.txt 只存在了 52 天。 产品站的 llms-full.txt 8 月 25 日才首次返回 200，内容是开放 API 的中文全文文档。
- 名字按自报，核验是快照。 核验用的是取数当天的名单。Bytespider、百度蜘蛛、Meta 的几个名字没用上名单核验，但它们按自报计取 llms 文件也是 0，不影响结论。
- 代理那 32 天只能部分排除缓存。 见第五节。
- 我们自己的请求没从总数里删。 第二节的 210 次里含我们自己的请求，按四条线索认出 107 次，加上我们产品网站诊断的 17 次共 124 次，是下限。
- 国内 AI 引擎几乎看不到。 名字表里 Kimi 的抓取器、豆包 App 的内置浏览器都没取过 llms 文件；国内引擎的抓取器在这份日志里本来就很少（上一篇第八节），本文回答不了它们读不读 llms.txt。
- 数字会过时。 日志每天在长，各家名单也会改；文中数字只代表 10 月 16～17 日取数那一刻。
数据出处：日志数字取自 zhimahang.com 的 nginx 访问日志，窗口是北京时间 2026-07-08 00:40:51 至 10-16 00:00（104,645 行），第二节读法第 4 条窗口之前那一次取自同一份日志从 6 月 6 日开头到窗口起点之间的部分；10 月 16 日 22:14～22:30 分五次只读汇总、10 月 17 日 00:13 又只读复核一次；名字按 User-Agent 自报，身份核验按 OpenAI、Anthropic、Perplexity、Amazon、Google、微软各自公布的地址名单（10 月 16 日 22:12～22:13 下载）；「Cloudflare 代理那 32 天」按日志里来访的对端地址是否落在 Cloudflare 公布的地址段里判断。文件核对（五个 llms 文件地址的大小、根路径与产品站两份逐字节相同、robots.txt、四份 sitemap 和产品站首页里没有指向 llms.txt 的链接）是北京时间 10 月 16 日 22:18～22:28 用 curl 取本站所得，在日志窗口之外；「根路径由网关转到产品站那一份」取自我们的代码注释和部署说明。认出我们自己请求的四条线索，取自我们自己的站点检查记录和工作会话记录；其中第四节第 1 条线索看的是同一份日志里带自测标记的请求，含 10 月 16 日当天（窗口之后）的行。第二节我们产品网站诊断的 17 次，按诊断程序代码里写死的 User-Agent、取文件的顺序和同批的其他请求认出；最后 1 批的来源地址与本站域名现在解析到的地址（我们的服务器）相同，另对了产品后台的诊断记录（10 月 17 日 00:14～00:15 只读查询）。单一站点的实测，不是行业均值。
本文由苏州智码航科技有限公司（引见 YinJen 团队）撰写。本文用到的访问日志明细没有公开（日志里有访问方的地址）；我们公开的引用数据集在 GitHub 组织 ZhiMaHang（已验证域名归属 zhimahang.com）。官网：zhimahang.com
本文数据来自作者所属公司对自有站点的只读统计与核对（日志侧为北京时间 2026-06-06 至 10-16 的 nginx 访问日志，主窗口为 07-08 至 10-15，10-16 当天的行只用来按自测标记认出我们自己的地址；文件侧为 10-16 用 curl 取本站文件；另对照了各运营方公布的地址名单、自有代码仓、自有产品后台的诊断记录和自己的检查记录与工作会话记录），文字由 AI 辅助创作、作者审校发布。
延伸阅读
