如果你的站点在根目录放了llms.txt访问也正常但服务器日志里始终等不到对应请求那么这篇文章就是给你看的。llms.txt是最近两年在站长圈和 AI 应用开发圈里被反复提到的站点说明文件。它的思路很像robots.txt和sitemap.xml的混合体网站主在根目录放一个 Markdown 格式的文件告诉大语言模型和 AI 爬虫“这个站是什么、有哪些值得读的页面、每个页面是干什么的”。按理说这能帮模型少抓垃圾页面、提高信息抽取效率但现实是很多人部署完之后发现根本没有人来获取这个文件。这不是服务器配置问题而是整个生态还没有完全接受这个约定。本文会把llms.txt的来历、规范、部署方式、验证方法以及“为什么没人抓取”的原因逐层拆开。看完你就能判断你的站点要不要上llms.txt上了之后到底怎么确认有没有被 AI 爬虫取走以及下一步还能做什么。1. 核心能力速览能力项说明项目性质站点信息描述文件约定类似robots.txt但不是强制规范文件位置网站根目录下的llms.txt文件格式Markdown通常包含标题、站点简介、区块和链接列表核心功能向 LLM 爬虫提供结构化的站点导航和内容摘要与 sitemap 区别sitemap 面向搜索引擎llms.txt 面向 AI 模型部署门槛低只需能修改站点根目录文件是否需要 GPU不需要纯 Web 文件是否支持批量以站点为粒度一个站点一个文件当前采用情况仍属于提案/约定阶段只有部分 AI 工具读取适合场景技术文档站、API 文档站、知识库、内容站从硬件角度看部署llms.txt不消耗任何计算资源也不要求 GPU 或高性能服务器。它的核心成本是维护成本你需要持续更新文件里的链接和摘要并保证页面不会大量 404。2. llms.txt 能解决什么问题很多站长对llms.txt的第一反应是“这东西能让我网站被 ChatGPT 引用吗”。这是一种常见的误读。llms.txt本身不会直接提升排名也不会保证爬虫一定来访问。它的作用是“如果爬虫端实现了 llms.txt 解析逻辑”那么它可以通过这个文件更快地理解你的网站结构。举个例子。一个普通文档站可能有几百个页面传统爬虫会把所有页面抓一遍然后依靠正文内容判断每个页面是什么。这个过程慢而且容易抓到重复、过时、低质量的页面。有了llms.txt爬虫可以先读这个索引文件直接看到“这个站点是什么有哪些板块每个板块最重要的链接是什么”。对模型来说这相当于给了它一张地图。所以llms.txt适合的场景很明确内容组织清晰的文档站。有大量 API 端点或用户指南的项目。希望控制 AI 爬虫抓取范围的站点。想减少无效抓取、降低服务器压力的站点。不适合的场景同样清楚纯个人博客没有明确栏目结构价值提升有限。站点内容大部分需要登录才能看公开抓取无意义。不想被任何爬虫访问的站点。信息高度动态、频繁变化的站点维护成本偏高。还有一类使用者需要注意如果你的站点包含用户生成内容、涉及人脸照片、音频、视频或版权素材在公开llms.txt之前要先确认这些内容是否有合法授权。llms.txt不是协议它只是给爬虫看的提示但它提供的信息会直接影响模型对站点内容的处理和引用。不要为了“被 AI 引用”而把不该公开的内容全部列进去。3. 环境准备与前置条件部署llms.txt不需要安装额外软件但需要满足几个最基础的前置条件。3.1 能访问站点根目录llms.txt的标准位置是域名根目录比如https://example.com/llms.txt不是/docs/llms.txt也不是https://example.com/llms.txt.html。目录搞错了爬虫按规范来找就一定会 404。如果你用的是静态托管平台比如 GitHub Pages、Cloudflare Pages、Vercel只需要把文件放到静态目录的根目录即可。如果你用的是 Nginx 或 Apache则需要确认站点 root 指向的物理路径并把文件放到这个路径下。3.2 HTTPS虽然规范没有强制要求 HTTPS但生产环境一定要用 HTTPS。现在几乎所有主流 AI 爬虫在访问站点时都会优先抓取 HTTPS 页面。如果站点还是 HTTP很多爬虫会拒绝访问。这个要求和部署普通网站完全一致。3.3 文本编辑与版本管理llms.txt本质是 Markdown 文件。建议使用支持 UTF-8 编码的编辑器避免出现中文乱码。项目类站点最好把llms.txt放进 Git 仓库方便追踪修改历史。这样即使文件被错误修改也能快速回滚。3.4 robots.txt 不与 llms.txt 冲突这个很容易被忽略。你的robots.txt里如果写了类似User-agent: * Disallow: /那绝大多数正常爬虫都不会访问站点里的任何路径包括llms.txt。相反如果你希望 AI 爬虫读取该文件至少要在规则中允许这个路径。更稳妥的做法是在发布前把llms.txt路径加入 robots 的白名单。4. 部署实施方案4.1 创建 llms.txt 文件参考 llmstxt.org 的思路llms.txt的推荐结构非常简洁标题、站点描述、分区块的链接列表。它遵循 Markdown 风格但链接行格式会带有简短的摘要说明。下面是一个最小可用的示例# Example Docs Example Docs is a collection of guides and API references for building secure, scalable web applications. ## Getting Started - [Quick Start](https://example.com/quick-start): Set up the SDK in 5 minutes. - [Authentication](https://example.com/auth): How to issue and validate API keys. ## API Reference - [REST API](https://example.com/api/rest): RESTful endpoints for core resources. - [Webhooks](https://example.com/api/webhooks): Event delivery and retry policy.几个实际建议站点描述放在引用块里语义更清晰。链接摘要要短一句话说明页面用途不要堆关键词。每个区块之间用空行分隔。不要放 JS 动态内容文件必须是静态 Markdown爬虫不会执行脚本。不要放登录后可见的链接否则爬虫会反复请求然后拿到 401。4.2 添加 robots 白名单如果你想明确告诉 AI 爬虫“这里有一个 llms.txt 可以读”可以在robots.txt里增加规则User-agent: GPTBot Allow: /llms.txt User-agent: ClaudeBot Allow: /llms.txt User-agent: PerplexityBot Allow: /llms.txt User-agent: * Disallow:注意robots.txt的Allow只表示“允许访问”并不代表爬虫一定来。它解决的是“不拦截”不能解决“主动发现”的问题。4.3 Nginx 静态配置示例如果站点用 Nginx 托管需要确保根目录下的llms.txt可以直接被外部访问。一个最小配置如下server { listen 80; server_name example.com; root /var/www/example; location /llms.txt { default_type text/markdown;; charset utf-8; } }这里把响应类型设置为text/markdown并指定 UTF-8 编码。虽然不是每个爬虫都强制检查 Content-Type但规范的响应会减少解析异常。4.4 静态站点生成器集成如果使用 Hugo、Jekyll 或 VitePress 这类静态站点生成器可以直接把llms.txt放在静态目录里。以 Hugo 为例放在static/llms.txt即可。注意选择文本格式不要使用模板语法自动生成避免每次构建覆盖掉手写的链接。4.5 注意缓存和 CDN如果站点用了 CDN不要把llms.txt缓存太久。文件内容更新后爬虫可能因为缓存而拿到旧版本。比较稳妥的做法是在响应头加上Cache-Control: no-cache在 Nginx 中可以这样设置location /llms.txt { add_header Cache-Control no-cache; }5. 功能测试与效果验证部署完成后第一步是验证文件能正常访问第二步是验证内容格式正确第三步才是观察有没有爬虫来获取。5.1 验证文件可访问性使用curl检查响应状态码和内容curl -I https://example.com/llms.txt预期返回HTTP/2 200 content-type: text/markdown再查看内容首部curl https://example.com/llms.txt | head -n 50如果返回 404说明文件没有放在正确的位置。如果返回 403需要检查 Nginx 权限或防火墙规则。5.2 校验 Markdown 结构llms.txt的解析依赖 Markdown 结构。建议检查以下几点第一行是否是# 站点名。描述是否放在引用块内。每个区块是否用##分隔。链接行是不是以- [标题](URL): 简介的格式写出。文件编码是否为 UTF-8有没有 BOM 头。可以用类似下面的 Python 脚本快速检查链接 URLimport re from urllib.parse import urlparse with open(llms.txt, r, encodingutf-8) as f: content f.read() links re.findall(r\[([^\]])\]\(([^)])\), content) for title, url in links: parsed urlparse(url) if parsed.scheme not in (http, https): print(f异常链接: {title} - {url}) else: print(f正常: {title} - {url})5.3 判断“有没有被获取”这才是关键。llms.txt部署完成后你需要观察服务器日志grep llms.txt /var/log/nginx/access.log | tail -n 20如果日志里没有任何llms.txt记录说明目前没有爬虫请求这个文件。这完全正常原因下面细说。还有一种思路是主动看通用爬虫有没有访问过站点。以 Nginx 默认日志格式为例可以统计包含已知 AI 爬虫 UA 的请求grep -iE GPTBot|ClaudeBot|PerplexityBot|Google-Extended /var/log/nginx/access.log | tail -n 20注意没有请求不代表你的配置有问题。llms.txt是“提供方协议”不是“强制抓取协议”。爬虫端必须实现了llms.txt解析逻辑才会在访问站点时额外请求这个文件。目前很多主流训练爬虫仍然只抓取 HTML。6. 监控与日志分析虽然llms.txt本身没有 API但它落地之后可以通过访问日志、监控面板和统计分析工具来观察效果。这里给出几个可以直接用的排查和监控思路。6.1 Nginx 日志按月统计awk $7 ~ /llms\.txt/ {print $4} /var/log/nginx/access.log \ | cut -d: -f1 \ | sort \ | uniq -c这个命令会按天汇总llms.txt的请求量。如果某一天开始出现请求说明有某个抓取器开始关注这个文件。6.2 监控爬虫 UA不同爬虫对llms.txt的实现路径不同。只靠日志很难确定对方是否因为看了llms.txt才抓取其他页面。但至少可以记录 UA为后续分析做数据基础awk $7 ~ /llms\.txt/ {print $1, $12, $13, $14} /var/log/nginx/access.log \ | grep llms.txt \ | tail -n 30默认 Nginx combined 日志格式里$12是 User-Agent。如果你修改过日志格式需要调整字段编号。更好的做法是把请求日志写入独立文件location /llms.txt { access_log /var/log/nginx/llms-txt.log; }这样llms.txt的请求不会被其他日志淹没。6.3 对接监控告警如果你希望第一时间知道有没有爬虫来请求llms.txt可以用 cron 脚本每分钟检查一次日志变化。也可以接入现成的日志平台比如 Loki 或 Elasticsearch设置关键字告警。简单脚本示例#!/bin/bash today$(date %d/%b/%Y) count$(grep $today /var/log/nginx/llms-txt.log | wc -l) if [ $count -gt 0 ]; then echo llms.txt 今天有 $count 次请求 else echo llms.txt 今天还没有请求 fi这个脚本适合放在 crontab 里定时跑不需要任何额外依赖。7. 资源占用与性能观察从资源占用角度看llms.txt几乎不消耗服务器计算能力。一个正常规模的文档站llms.txt文件大小通常在 10KB 到 100KB 之间。即使每秒被请求 100 次对现代 Web 服务器来说也只是很小的负载。真正需要注意的是两点缓存策略和文件规模。如果文件里塞入几万个链接每次请求都会把整个文件从磁盘读出来然后再传输。这种情况下建议在 Nginx 或 CDN 层面开启缓存。但要注意上文提到的更新问题缓存时间不能太长。比较理想的方案是设置短缓存比如 5 到 10 分钟location /llms.txt { add_header Cache-Control max-age600; }从“性能观察”的角度你可以重点看三个指标llms.txt的请求 QPS。请求来源 IP 是否属于已知 AI 爬虫 IP 段。文件完整下载时间。这些指标可以通过下面的命令快速测量time curl -s -o /dev/null https://example.com/llms.txt如果时间大于 1 秒说明文件太大或网络链路有问题需要进一步优化。8. 常见问题与排查方法问题现象可能原因排查方式解决方案浏览器访问 llms.txt 返回 404文件未放在根目录检查站点根路径把文件移到域名根目录返回 403Nginx 权限、目录禁止访问查看 error.log调整目录权限和 location 规则中文乱码文件编码非 UTF-8用编辑器查看编码另存为 UTF-8 无 BOM一直没有任何请求爬虫端未实现 llms.txt 解析看访问日志等待生态适配或主动提交站点给搜索引擎请求有但内容不是最新CDN 或浏览器缓存检查响应头 Cache-Control设置 no-cache 或短缓存OpenAI 爬虫不访问robots.txt 未允许检查 robots.txt添加 Allow: /llms.txtMarkdown 被解析成纯文本响应 Content-Type 不是 text/markdowncurl -I 检查响应头在 Nginx 中配置 default_type文件非常大链接过多查看文件体积按内容层级精简只保留核心页面更隐蔽的一个问题是有些搜索引擎会把llms.txt当成普通网页收录导致页面出现在搜索结果里内容却是无样式的纯文本。如果你不希望这样可以在robots.txt里限制非 AI 爬虫访问但普通搜索引擎和 AI 爬虫使用的 UA 有重叠这条规则需要反复测试。9. 最佳实践与使用建议9.1 先小范围验证再全站铺开不要第一次就把整站几千个链接全塞进去。先放权威栏目、最核心文档观察日志和搜索引擎表现。等确认格式被正确解析、没有异常请求后再逐步扩展。9.2 保持文件与站点内容同步llms.txt最大的维护风险是链接失效。建议在 CI/CD 流程中增加链接检查步骤自动检测llms.txt中的 URL 是否返回 200。没有 CI/CD 的站点至少每周手工抽查一次。9.3 区分训练爬虫和搜索爬虫不同爬虫访问llms.txt的动机不同。部分搜索型 AI 产品会把llms.txt当作站点入口读取后继续抓取内部页面。部分训练型爬虫可能完全不看它。不要因为某一个爬虫没来就否定整个方案。9.4 不要过度插入关键词llms.txt的目的是让 AI 理解站点结构不是做 SEO。把摘要写成关键词堆砌只会让解析效果更差。保持自然、简洁、准确。9.5 注意内容授权与隐私如果你的站点包含用户生成内容或者提供的是第三方素材不要在没有授权的情况下把这些页面写进llms.txt。理由很简单llms.txt是给 AI 爬虫看的文件你等于主动告诉模型“这些页面值得读”这会加速素材被用于模型训练或搜索结果。发布前先问自己这些内容是否允许被第三方 AI 系统公开使用9.6 把它当成工程配置不是一劳永逸llms.txt的价值取决于生态和内容的新鲜度。建议每个季度复盘一次日志里有没有爬虫访问文件里有没有失效链接站点结构有没有变化定期维护才能让这个文件在被真正需要的时候保持可用。10. 总结与下一步回到最初的问题“Nobody Fetched My llms.txt”。这大概率不是你的配置错误而是整个生态还在磨合期。llms.txt是一个由内容方主动提供的索引爬虫端是否读取完全取决于对方的产品设计。作为站长你能做的就是把文件放在正确位置、保持内容准确、留好日志然后等生态慢慢跟进。下一步建议按这个顺序验证确认https://你的域名/llms.txt返回 200内容格式正确。检查robots.txt是否允许 AI 爬虫访问该文件。在访问日志里单独记录llms.txt的请求。把llms.txt纳入站点更新流程保证链接有效。定期观察日志看看哪个爬虫开始读这个文件。这个文件不是“部署了就有收益”的万能方案但它是在 AI 搜索和训练爬虫识别站点结构时少数由站长侧完全可控的入口。先把基础工作做好等哪天爬虫生态开始大规模解析llms.txt时你的站点已经准备好了。
llms.txt部署后无人抓取？原因分析与排查指南
如果你的站点在根目录放了llms.txt访问也正常但服务器日志里始终等不到对应请求那么这篇文章就是给你看的。llms.txt是最近两年在站长圈和 AI 应用开发圈里被反复提到的站点说明文件。它的思路很像robots.txt和sitemap.xml的混合体网站主在根目录放一个 Markdown 格式的文件告诉大语言模型和 AI 爬虫“这个站是什么、有哪些值得读的页面、每个页面是干什么的”。按理说这能帮模型少抓垃圾页面、提高信息抽取效率但现实是很多人部署完之后发现根本没有人来获取这个文件。这不是服务器配置问题而是整个生态还没有完全接受这个约定。本文会把llms.txt的来历、规范、部署方式、验证方法以及“为什么没人抓取”的原因逐层拆开。看完你就能判断你的站点要不要上llms.txt上了之后到底怎么确认有没有被 AI 爬虫取走以及下一步还能做什么。1. 核心能力速览能力项说明项目性质站点信息描述文件约定类似robots.txt但不是强制规范文件位置网站根目录下的llms.txt文件格式Markdown通常包含标题、站点简介、区块和链接列表核心功能向 LLM 爬虫提供结构化的站点导航和内容摘要与 sitemap 区别sitemap 面向搜索引擎llms.txt 面向 AI 模型部署门槛低只需能修改站点根目录文件是否需要 GPU不需要纯 Web 文件是否支持批量以站点为粒度一个站点一个文件当前采用情况仍属于提案/约定阶段只有部分 AI 工具读取适合场景技术文档站、API 文档站、知识库、内容站从硬件角度看部署llms.txt不消耗任何计算资源也不要求 GPU 或高性能服务器。它的核心成本是维护成本你需要持续更新文件里的链接和摘要并保证页面不会大量 404。2. llms.txt 能解决什么问题很多站长对llms.txt的第一反应是“这东西能让我网站被 ChatGPT 引用吗”。这是一种常见的误读。llms.txt本身不会直接提升排名也不会保证爬虫一定来访问。它的作用是“如果爬虫端实现了 llms.txt 解析逻辑”那么它可以通过这个文件更快地理解你的网站结构。举个例子。一个普通文档站可能有几百个页面传统爬虫会把所有页面抓一遍然后依靠正文内容判断每个页面是什么。这个过程慢而且容易抓到重复、过时、低质量的页面。有了llms.txt爬虫可以先读这个索引文件直接看到“这个站点是什么有哪些板块每个板块最重要的链接是什么”。对模型来说这相当于给了它一张地图。所以llms.txt适合的场景很明确内容组织清晰的文档站。有大量 API 端点或用户指南的项目。希望控制 AI 爬虫抓取范围的站点。想减少无效抓取、降低服务器压力的站点。不适合的场景同样清楚纯个人博客没有明确栏目结构价值提升有限。站点内容大部分需要登录才能看公开抓取无意义。不想被任何爬虫访问的站点。信息高度动态、频繁变化的站点维护成本偏高。还有一类使用者需要注意如果你的站点包含用户生成内容、涉及人脸照片、音频、视频或版权素材在公开llms.txt之前要先确认这些内容是否有合法授权。llms.txt不是协议它只是给爬虫看的提示但它提供的信息会直接影响模型对站点内容的处理和引用。不要为了“被 AI 引用”而把不该公开的内容全部列进去。3. 环境准备与前置条件部署llms.txt不需要安装额外软件但需要满足几个最基础的前置条件。3.1 能访问站点根目录llms.txt的标准位置是域名根目录比如https://example.com/llms.txt不是/docs/llms.txt也不是https://example.com/llms.txt.html。目录搞错了爬虫按规范来找就一定会 404。如果你用的是静态托管平台比如 GitHub Pages、Cloudflare Pages、Vercel只需要把文件放到静态目录的根目录即可。如果你用的是 Nginx 或 Apache则需要确认站点 root 指向的物理路径并把文件放到这个路径下。3.2 HTTPS虽然规范没有强制要求 HTTPS但生产环境一定要用 HTTPS。现在几乎所有主流 AI 爬虫在访问站点时都会优先抓取 HTTPS 页面。如果站点还是 HTTP很多爬虫会拒绝访问。这个要求和部署普通网站完全一致。3.3 文本编辑与版本管理llms.txt本质是 Markdown 文件。建议使用支持 UTF-8 编码的编辑器避免出现中文乱码。项目类站点最好把llms.txt放进 Git 仓库方便追踪修改历史。这样即使文件被错误修改也能快速回滚。3.4 robots.txt 不与 llms.txt 冲突这个很容易被忽略。你的robots.txt里如果写了类似User-agent: * Disallow: /那绝大多数正常爬虫都不会访问站点里的任何路径包括llms.txt。相反如果你希望 AI 爬虫读取该文件至少要在规则中允许这个路径。更稳妥的做法是在发布前把llms.txt路径加入 robots 的白名单。4. 部署实施方案4.1 创建 llms.txt 文件参考 llmstxt.org 的思路llms.txt的推荐结构非常简洁标题、站点描述、分区块的链接列表。它遵循 Markdown 风格但链接行格式会带有简短的摘要说明。下面是一个最小可用的示例# Example Docs Example Docs is a collection of guides and API references for building secure, scalable web applications. ## Getting Started - [Quick Start](https://example.com/quick-start): Set up the SDK in 5 minutes. - [Authentication](https://example.com/auth): How to issue and validate API keys. ## API Reference - [REST API](https://example.com/api/rest): RESTful endpoints for core resources. - [Webhooks](https://example.com/api/webhooks): Event delivery and retry policy.几个实际建议站点描述放在引用块里语义更清晰。链接摘要要短一句话说明页面用途不要堆关键词。每个区块之间用空行分隔。不要放 JS 动态内容文件必须是静态 Markdown爬虫不会执行脚本。不要放登录后可见的链接否则爬虫会反复请求然后拿到 401。4.2 添加 robots 白名单如果你想明确告诉 AI 爬虫“这里有一个 llms.txt 可以读”可以在robots.txt里增加规则User-agent: GPTBot Allow: /llms.txt User-agent: ClaudeBot Allow: /llms.txt User-agent: PerplexityBot Allow: /llms.txt User-agent: * Disallow:注意robots.txt的Allow只表示“允许访问”并不代表爬虫一定来。它解决的是“不拦截”不能解决“主动发现”的问题。4.3 Nginx 静态配置示例如果站点用 Nginx 托管需要确保根目录下的llms.txt可以直接被外部访问。一个最小配置如下server { listen 80; server_name example.com; root /var/www/example; location /llms.txt { default_type text/markdown;; charset utf-8; } }这里把响应类型设置为text/markdown并指定 UTF-8 编码。虽然不是每个爬虫都强制检查 Content-Type但规范的响应会减少解析异常。4.4 静态站点生成器集成如果使用 Hugo、Jekyll 或 VitePress 这类静态站点生成器可以直接把llms.txt放在静态目录里。以 Hugo 为例放在static/llms.txt即可。注意选择文本格式不要使用模板语法自动生成避免每次构建覆盖掉手写的链接。4.5 注意缓存和 CDN如果站点用了 CDN不要把llms.txt缓存太久。文件内容更新后爬虫可能因为缓存而拿到旧版本。比较稳妥的做法是在响应头加上Cache-Control: no-cache在 Nginx 中可以这样设置location /llms.txt { add_header Cache-Control no-cache; }5. 功能测试与效果验证部署完成后第一步是验证文件能正常访问第二步是验证内容格式正确第三步才是观察有没有爬虫来获取。5.1 验证文件可访问性使用curl检查响应状态码和内容curl -I https://example.com/llms.txt预期返回HTTP/2 200 content-type: text/markdown再查看内容首部curl https://example.com/llms.txt | head -n 50如果返回 404说明文件没有放在正确的位置。如果返回 403需要检查 Nginx 权限或防火墙规则。5.2 校验 Markdown 结构llms.txt的解析依赖 Markdown 结构。建议检查以下几点第一行是否是# 站点名。描述是否放在引用块内。每个区块是否用##分隔。链接行是不是以- [标题](URL): 简介的格式写出。文件编码是否为 UTF-8有没有 BOM 头。可以用类似下面的 Python 脚本快速检查链接 URLimport re from urllib.parse import urlparse with open(llms.txt, r, encodingutf-8) as f: content f.read() links re.findall(r\[([^\]])\]\(([^)])\), content) for title, url in links: parsed urlparse(url) if parsed.scheme not in (http, https): print(f异常链接: {title} - {url}) else: print(f正常: {title} - {url})5.3 判断“有没有被获取”这才是关键。llms.txt部署完成后你需要观察服务器日志grep llms.txt /var/log/nginx/access.log | tail -n 20如果日志里没有任何llms.txt记录说明目前没有爬虫请求这个文件。这完全正常原因下面细说。还有一种思路是主动看通用爬虫有没有访问过站点。以 Nginx 默认日志格式为例可以统计包含已知 AI 爬虫 UA 的请求grep -iE GPTBot|ClaudeBot|PerplexityBot|Google-Extended /var/log/nginx/access.log | tail -n 20注意没有请求不代表你的配置有问题。llms.txt是“提供方协议”不是“强制抓取协议”。爬虫端必须实现了llms.txt解析逻辑才会在访问站点时额外请求这个文件。目前很多主流训练爬虫仍然只抓取 HTML。6. 监控与日志分析虽然llms.txt本身没有 API但它落地之后可以通过访问日志、监控面板和统计分析工具来观察效果。这里给出几个可以直接用的排查和监控思路。6.1 Nginx 日志按月统计awk $7 ~ /llms\.txt/ {print $4} /var/log/nginx/access.log \ | cut -d: -f1 \ | sort \ | uniq -c这个命令会按天汇总llms.txt的请求量。如果某一天开始出现请求说明有某个抓取器开始关注这个文件。6.2 监控爬虫 UA不同爬虫对llms.txt的实现路径不同。只靠日志很难确定对方是否因为看了llms.txt才抓取其他页面。但至少可以记录 UA为后续分析做数据基础awk $7 ~ /llms\.txt/ {print $1, $12, $13, $14} /var/log/nginx/access.log \ | grep llms.txt \ | tail -n 30默认 Nginx combined 日志格式里$12是 User-Agent。如果你修改过日志格式需要调整字段编号。更好的做法是把请求日志写入独立文件location /llms.txt { access_log /var/log/nginx/llms-txt.log; }这样llms.txt的请求不会被其他日志淹没。6.3 对接监控告警如果你希望第一时间知道有没有爬虫来请求llms.txt可以用 cron 脚本每分钟检查一次日志变化。也可以接入现成的日志平台比如 Loki 或 Elasticsearch设置关键字告警。简单脚本示例#!/bin/bash today$(date %d/%b/%Y) count$(grep $today /var/log/nginx/llms-txt.log | wc -l) if [ $count -gt 0 ]; then echo llms.txt 今天有 $count 次请求 else echo llms.txt 今天还没有请求 fi这个脚本适合放在 crontab 里定时跑不需要任何额外依赖。7. 资源占用与性能观察从资源占用角度看llms.txt几乎不消耗服务器计算能力。一个正常规模的文档站llms.txt文件大小通常在 10KB 到 100KB 之间。即使每秒被请求 100 次对现代 Web 服务器来说也只是很小的负载。真正需要注意的是两点缓存策略和文件规模。如果文件里塞入几万个链接每次请求都会把整个文件从磁盘读出来然后再传输。这种情况下建议在 Nginx 或 CDN 层面开启缓存。但要注意上文提到的更新问题缓存时间不能太长。比较理想的方案是设置短缓存比如 5 到 10 分钟location /llms.txt { add_header Cache-Control max-age600; }从“性能观察”的角度你可以重点看三个指标llms.txt的请求 QPS。请求来源 IP 是否属于已知 AI 爬虫 IP 段。文件完整下载时间。这些指标可以通过下面的命令快速测量time curl -s -o /dev/null https://example.com/llms.txt如果时间大于 1 秒说明文件太大或网络链路有问题需要进一步优化。8. 常见问题与排查方法问题现象可能原因排查方式解决方案浏览器访问 llms.txt 返回 404文件未放在根目录检查站点根路径把文件移到域名根目录返回 403Nginx 权限、目录禁止访问查看 error.log调整目录权限和 location 规则中文乱码文件编码非 UTF-8用编辑器查看编码另存为 UTF-8 无 BOM一直没有任何请求爬虫端未实现 llms.txt 解析看访问日志等待生态适配或主动提交站点给搜索引擎请求有但内容不是最新CDN 或浏览器缓存检查响应头 Cache-Control设置 no-cache 或短缓存OpenAI 爬虫不访问robots.txt 未允许检查 robots.txt添加 Allow: /llms.txtMarkdown 被解析成纯文本响应 Content-Type 不是 text/markdowncurl -I 检查响应头在 Nginx 中配置 default_type文件非常大链接过多查看文件体积按内容层级精简只保留核心页面更隐蔽的一个问题是有些搜索引擎会把llms.txt当成普通网页收录导致页面出现在搜索结果里内容却是无样式的纯文本。如果你不希望这样可以在robots.txt里限制非 AI 爬虫访问但普通搜索引擎和 AI 爬虫使用的 UA 有重叠这条规则需要反复测试。9. 最佳实践与使用建议9.1 先小范围验证再全站铺开不要第一次就把整站几千个链接全塞进去。先放权威栏目、最核心文档观察日志和搜索引擎表现。等确认格式被正确解析、没有异常请求后再逐步扩展。9.2 保持文件与站点内容同步llms.txt最大的维护风险是链接失效。建议在 CI/CD 流程中增加链接检查步骤自动检测llms.txt中的 URL 是否返回 200。没有 CI/CD 的站点至少每周手工抽查一次。9.3 区分训练爬虫和搜索爬虫不同爬虫访问llms.txt的动机不同。部分搜索型 AI 产品会把llms.txt当作站点入口读取后继续抓取内部页面。部分训练型爬虫可能完全不看它。不要因为某一个爬虫没来就否定整个方案。9.4 不要过度插入关键词llms.txt的目的是让 AI 理解站点结构不是做 SEO。把摘要写成关键词堆砌只会让解析效果更差。保持自然、简洁、准确。9.5 注意内容授权与隐私如果你的站点包含用户生成内容或者提供的是第三方素材不要在没有授权的情况下把这些页面写进llms.txt。理由很简单llms.txt是给 AI 爬虫看的文件你等于主动告诉模型“这些页面值得读”这会加速素材被用于模型训练或搜索结果。发布前先问自己这些内容是否允许被第三方 AI 系统公开使用9.6 把它当成工程配置不是一劳永逸llms.txt的价值取决于生态和内容的新鲜度。建议每个季度复盘一次日志里有没有爬虫访问文件里有没有失效链接站点结构有没有变化定期维护才能让这个文件在被真正需要的时候保持可用。10. 总结与下一步回到最初的问题“Nobody Fetched My llms.txt”。这大概率不是你的配置错误而是整个生态还在磨合期。llms.txt是一个由内容方主动提供的索引爬虫端是否读取完全取决于对方的产品设计。作为站长你能做的就是把文件放在正确位置、保持内容准确、留好日志然后等生态慢慢跟进。下一步建议按这个顺序验证确认https://你的域名/llms.txt返回 200内容格式正确。检查robots.txt是否允许 AI 爬虫访问该文件。在访问日志里单独记录llms.txt的请求。把llms.txt纳入站点更新流程保证链接有效。定期观察日志看看哪个爬虫开始读这个文件。这个文件不是“部署了就有收益”的万能方案但它是在 AI 搜索和训练爬虫识别站点结构时少数由站长侧完全可控的入口。先把基础工作做好等哪天爬虫生态开始大规模解析llms.txt时你的站点已经准备好了。
