llms.txt部署后无人抓取？原因分析与排查指南

如果你的站点在根目录放了llms.txt，访问也正常，但服务器日志里始终等不到对应请求，那么这篇文章就是给你看的。

llms.txt是最近两年在站长圈和 AI 应用开发圈里被反复提到的站点说明文件。它的思路很像robots.txt和sitemap.xml的混合体：网站主在根目录放一个 Markdown 格式的文件，告诉大语言模型和 AI 爬虫“这个站是什么、有哪些值得读的页面、每个页面是干什么的”。按理说这能帮模型少抓垃圾页面、提高信息抽取效率，但现实是，很多人部署完之后发现：根本没有人来获取这个文件。

这不是服务器配置问题，而是整个生态还没有完全接受这个约定。本文会把llms.txt的来历、规范、部署方式、验证方法，以及“为什么没人抓取”的原因逐层拆开。看完你就能判断：你的站点要不要上llms.txt，上了之后到底怎么确认有没有被 AI 爬虫取走，以及下一步还能做什么。

1. 核心能力速览

从硬件角度看，部署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 脚本快速检查链接 URL：

import re from urllib.parse import urlparse with open("llms.txt", "r", encoding="utf-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-age=600"; }

从“性能观察”的角度，你可以重点看三个指标：

• llms.txt的请求 QPS。
• 请求来源 IP 是否属于已知 AI 爬虫 IP 段。
• 文件完整下载时间。

这些指标可以通过下面的命令快速测量：

time curl -s -o /dev/null https://example.com/llms.txt

如果时间大于 1 秒，说明文件太大或网络链路有问题，需要进一步优化。

8. 常见问题与排查方法

更隐蔽的一个问题是：有些搜索引擎会把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是一个由内容方主动提供的索引，爬虫端是否读取完全取决于对方的产品设计。作为站长，你能做的就是把文件放在正确位置、保持内容准确、留好日志，然后等生态慢慢跟进。

下一步建议按这个顺序验证：

1. 确认https://你的域名/llms.txt返回 200，内容格式正确。
2. 检查robots.txt是否允许 AI 爬虫访问该文件。
3. 在访问日志里单独记录llms.txt的请求。
4. 把llms.txt纳入站点更新流程，保证链接有效。
5. 定期观察日志，看看哪个爬虫开始读这个文件。

这个文件不是“部署了就有收益”的万能方案，但它是在 AI 搜索和训练爬虫识别站点结构时，少数由站长侧完全可控的入口。先把基础工作做好，等哪天爬虫生态开始大规模解析llms.txt时，你的站点已经准备好了。