llms.txt实战：从部署到日志分析，提升AI爬虫可发现性

在实际站点优化工作中，llms.txt已经不再只是一个社区里的新奇概念。有团队在 83 个网站上部署了llms.txt，并连续观察了 12 周，结果 OpenAI 的爬虫总共读取了这份文件 7 次。这个数字看起来不算高，但它背后至少说明两件事：其一，OpenAI 的爬虫确实会按规范检查并读取llms.txt；其二，读取频率并不由文件本身决定，而是由站点权重、内容更新频率、robots.txt 配置和爬虫自身的调度策略共同决定。

这篇文章会围绕这组实测数据展开，先说明llms.txt到底是什么，再带你从零在自己的站点上部署一份可用的llms.txt，然后讲解如何通过访问日志确认 OpenAI 爬虫是否真的来读过，以及遇到“文件放了但没被抓取”的情况时该怎么排查。最后会给出一个可以直接落到发布流程里的优化清单。无论你是个人博客站长、文档站点维护者，还是公司官网的技术负责人，都可以按这篇文章的步骤把 AI 爬虫的可发现性纳入常规运维范围。

1. llms.txt 是什么，以及为什么值得在站点里加一个文本文件

1.1 一个给大模型爬虫看的“站点说明书”

llms.txt是一个放在网站根目录下的纯文本文件，路径通常是https://example.com/llms.txt。它的作用很简单：用大语言模型更容易理解的 Markdown 格式，把站点的名称、简介、核心页面入口和说明集中写清楚。

普通用户访问一个网站时，看到的是经过 CSS 渲染的页面；搜索引擎爬虫读取 HTML 时，还需要处理导航、脚本、样式和各种语义标签。大模型爬虫在最开始判断“这个网站值不值得访问、应该优先访问哪些页面”时，直接读取一份精炼的文本文件，比解析一整棵 DOM 树要高效得多。

一个最小可用的llms.txt大致长这样：

# Example Blog > 一个记录后端工程实践的独立博客，主要分享 Nginx、Python、数据库和可观测性相关内容。 ## Posts - https://example.com/posts/nginx-access-log-analysis: 通过访问日志分析爬虫行为的完整思路 - https://example.com/posts/python-log-parsing: 用 Python 统计日志中的 User-Agent 和状态码 - https://example.com/posts/llms-txt-guide: llms.txt 规范介绍与部署方法 ## About - https://example.com/about: 作者介绍和写作方向

这个格式不是标准组织发布的正式 RFC，而是社区提出并被多个 AI 搜索产品采纳的约定。文件第一行是站点名称，紧接着的引用块可以写一句话摘要，后面的二级标题把链接按主题分组，每个链接后面用冒号跟着一句描述。描述信息不是必须的，但对大模型理解链接内容很有帮助。

容易误解的地方在于：llms.txt不是为了“吸引更多流量”而设计的，它的目标是让已经到来的 AI 爬虫更容易抓住站点骨架，减少无效抓取。

1.2 从 robots.txt 到 llms.txt：不是替代，而是补充

很多开发者第一次听llms.txt时会联想到robots.txt，但两者的职责完全不同。

robots.txt是一份权限声明，告诉爬虫哪些路径可以访问、哪些路径不能访问，以及基础协议级别的规则。它解决的是“能不能来”的问题。llms.txt则是一份内容推荐清单，告诉爬虫来了以后优先读什么。它解决的是“来了之后读什么”的问题。

在实际部署中，这两个文件需要配合使用。robots.txt负责把爬虫挡在后台管理目录、临时页面和敏感路径之外，llms.txt负责把公开的、有长期价值的内容汇总到根路径上。

这里有一个非常常见的误区：有人以为只要在robots.txt里写Allow: /llms.txt，就等于给页面做了 SEO 优化。实际上，robots.txt只是解除了访问限制，真正让爬虫理解站点内容的是llms.txt中给出的链接和描述。反过来，也不要在llms.txt里放置需要权限才能访问的内部地址，爬虫即使读到了这个文件，也无法越过robots.txt或登录鉴权去抓取受限资源。

1.3 83 个站点、12 周、7 次读取：实验到底验证了什么

这轮公开实验的做法并不复杂：团队在 83 个不同网站上放置了格式正确的llms.txt，保持站点原有内容和 robots.txt 规则不变，然后持续观察了 12 周，统计 OpenAI 爬虫对这些文件的访问记录。最终总数是 7 次。

先简单做一个除法：12 周约等于 84 天，7 次读取意味着平均大约 12 天才会读取一次。如果按 83 个站点总数来看，这个频率确实不高。但更准确的理解是：这 7 次是 83 个站点的累计次数，不代表每个站点都被读取了 7 次。更可能是某个权重稍高的站点被读取了 2 到 3 次，而大部分站点在整个周期内一次都没有被读到。

这组数据验证了三件事：

1. OpenAI 爬虫确实会检查llms.txt，说明这个规范在 OpenAI 侧已经被识别。
2. llms.txt本身不会直接提升站点权重，它只是为爬虫提供更方便的内容入口。
3. 爬虫回访频率取决于站点是否值得被频繁更新和抓取，而不是有没有这份文本文件。

因此，看到“7 次”先不用失望。把它当作一个基线，思考如何让站点在内容层面变得更值得被 AI 爬虫回访。

2. 如何在自己的站点部署 llms.txt 并让 OpenAI 爬虫可以访问

2.1 准备环境与前置检查清单

部署llms.txt不需要额外安装任何框架，它就是一个静态文本文件。真正的难点在于确认部署后能通过GET https://example.com/llms.txt稳定返回正确内容，而且没有被 robots.txt、CDN 或 WAF 拦截。

在动手之前，先按下面的清单确认环境：

如果站点用了 Cloudflare、阿里云 CDN、腾讯云 CDN 等产品，还要确认.txt文件没有被缓存策略转成错误的 Content-Type。比如有些 CDN 会默认把未知后缀文件识别为application/octet-stream，虽然爬虫通常也能读取，但更稳妥的做法是在源站显式设置Content-Type: text/plain; charset=utf-8。

2.2 编写 llms.txt 文件：格式规范与示例

llms.txt的格式规范可以概括为：以站点名作为一级标题，以引用块作为摘要，用二级标题分组，链接列表放在分组下。链接必须是完整 URL，不能使用相对路径。

这里给一个适合文档站点使用的示例：

# CloudServer Docs > 面向后端开发者的云服务器运维文档，涵盖 Nginx 配置、日志分析、容器部署和故障排查。 ## Getting Started - https://docs.example.com/getting-started: 从零开始配置一台云服务器的必要步骤 - https://docs.example.com/nginx-basics: Nginx 常用指令与站点配置示例 - https://docs.example.com/log-rotation: 日志切割策略与磁盘占用治理 ## Troubleshooting - https://docs.example.com/troubleshooting/high-cpu: CPU 使用率过高时的定位流程 - https://docs.example.com/troubleshooting/connection-refused: 端口连接失败的排查思路 ## Operations - https://docs.example.com/backup: 数据库冷备与异地备份方案 - https://docs.example.com/monitoring: 基于访问日志的监控指标设计

写的时候注意几个细节：

• 一级标题#和二级标题##一定要存在，爬虫会依赖标题结构判断分组。
• 引用块>不是必须，但写上摘要后，大模型可以更快判断当前站点是否与用户问题相关。
• 链接使用https://绝对地址，不要写www跳转链，避免爬虫需要额外跟踪重定向。
• 每个链接后的描述尽量用一句话说明页面解决什么问题，描述比链接文本本身更重要。
• 文件大小保持在 100 行以内比较合适，强烈不建议把整个 sitemap 复制进来。

2.3 通过 robots.txt 放行 GPTBot：路径与权限控制

OpenAI 对外公开的爬虫主要有两个：

• GPTBot：用于抓取网页内容并用于训练或知识库检索，User-Agent 示例为GPTBot/1.0。
• OAI-SearchBot：用于支持 ChatGPT 搜索和引用场景，User-Agent 示例为OAI-SearchBot/1.0。

默认情况下，robots.txt如果没有禁止任何爬虫，OpenAI 爬虫可以访问站点所有公开路径。但很多生产站点因为流量管控、安全策略，会针对 AI 爬虫做额外限制。比如有人会在robots.txt里写成这样：

User-agent: GPTBot Disallow: /

如果站点保留着这行配置，即使llms.txt已经放在根目录，OpenAI 爬虫也会因为 robots.txt 的规则而拒绝读取。正确做法是在robots.txt里单独放行：

User-agent: GPTBot Allow: /llms.txt Allow: /public/ Disallow: /admin/ Disallow: /api/ User-agent: OAI-SearchBot Allow: / Disallow: /admin/

这段配置的含义是：允许 GPTBot 读取llms.txt和public目录，禁止读取后台和接口路径；允许 OAI-SearchBot 读取全站公开页面，但同样禁止后台路径。

需要强调一点：llms.txt应该尽可能放在根目录，并且不要被Disallow规则覆盖。有些站点会写Disallow: /*.txt$，这会把所有文本文件都挡掉，llms.txt也会跟着失效。

2.4 静态站点与动态站点的部署方式差异

不同站点架构部署llms.txt的方式略有差别。

对于纯静态托管，比如 GitHub Pages、Cloudflare Pages 或 Vercel，直接把llms.txt放到构建产物的根目录即可。以 Next.js 为例，把文件放在public/llms.txt下，构建后就能通过/llms.txt访问。

对于使用 Nginx 的服务器，如果文件位于站点根目录，默认配置下已经可以访问。如果希望做更严格的缓存控制，可以单独写一个 location：

location = /llms.txt { default_type text/plain; charset=utf-8; add_header Cache-Control "public, max-age=3600"; try_files $uri =404; }

这里default_type保证返回的 Content-Type 是text/plain，Cache-Control让 CDN 可以不频繁回源，但保留 1 小时新鲜度，避免内容更新后迟迟不生效。

对于 Django、Flask、Spring Boot 这类动态站点，不要生成一个实际文件，而是直接通过路由返回纯文本。关键点也是两个：状态码必须是 200，Content-Type 必须正确。

from flask import Response @app.route("/llms.txt") def llms_txt(): content = """# Example Blog > 分享后端工程实践的个人博客。 """ return Response(content, mimetype="text/plain; charset=utf-8")

部署完成后，先用 curl 检查：

curl -i https://example.com/llms.txt

i参数会输出响应头。如果看到HTTP/2 200和content-type: text/plain; charset=utf-8，说明文件已经可以正常访问。

3. 如何判断 OpenAI 爬虫是否真的读取了 llms.txt

3.1 从访问日志里识别 GPTBot 与 OAI-SearchBot

部署完成只是第一步，关键是确认爬虫是否来过。最直接的方法是查 Web 服务器的访问日志。

OpenAI 官方公开的 User-Agent 大致是这样的：

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.0; +https://openai.com/gptbot

搜索爬虫的 UA 会包含OAI-SearchBot：

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot

在日志里直接搜llms.txt和GPTBot就能看到相关记录。下面是一条典型的 Nginx 访问日志：

192.0.2.10 - - [10/Jan/2025:08:12:43 +0000] "GET /llms.txt HTTP/1.1" 200 118 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.0; +https://openai.com/gptbot"

这条日志里的关键信息是：

• 请求方法为GET，路径是/llms.txt。
• 状态码为200，说明文件被正常返回。
• User-Agent 中明确包含GPTBot/1.0。
• Referer为空，说明这是爬虫主动访问，不是从某个页面点击进入。

3.2 用 Nginx 为 llms.txt 单独记录访问日志

如果站点日志量很大，每次都用grep过滤会比较费劲。一个更清晰的做法是在 Nginx 里为/llms.txt单独设置访问日志。

log_format llms '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'; location = /llms.txt { access_log /var/log/nginx/llms_access.log llms; default_type text/plain; charset=utf-8; try_files $uri =404; }

这样所有针对/llms.txt的请求都会写进llms_access.log，其他路径仍然记录在原来的访问日志中。排错时会非常方便。

需要注意的是，如果前面配了 CDN，访问日志里的 IP 可能是 CDN 节点而不是源站。此时要在 Nginx 中获取X-Forwarded-For头，或者直接在 CDN 日志侧分析。

3.3 用脚本统计读取次数、来源 IP 和 User-Agent

拿到llms_access.log后，可以用命令或脚本统计 OpenAI 爬虫读取了多少次。

先用最简单的命令行方式：

grep "llms.txt" /var/log/nginx/access.log | grep -E "GPTBot|OAI-SearchBot" | wc -l

这样能看到次数，但看不到时间分布和来源 IP。更适合的做法是写一个小脚本，输出每天的读取次数、UA 和 IP：

#!/usr/bin/env python3 import re from collections import Counter, defaultdict from datetime import datetime LOG_PATH = "/var/log/nginx/llms_access.log" OPENAI_PATTERN = re.compile(r"GPTBot|OAI-SearchBot", re.I) daily = defaultdict(int) uas = Counter() ips = Counter() with open(LOG_PATH, "r", encoding="utf-8", errors="ignore") as f: for line in f: if not OPENAI_PATTERN.search(line): continue if "/llms.txt" not in line: continue m = re.search(r"\[(\d{2}/\w+/\d{4}):\d{2}:\d{2}:\d{2}", line) if m: day = m.group(1) daily[day] += 1 ip_m = re.match(r"(\d+\.\d+\.\d+\.\d+)", line) if ip_m: ips[ip_m.group(1)] += 1 ua_m = re.search(r"\"([^\"]*(?:GPTBot|OAI-SearchBot)[^\"]*)\"$", line) if ua_m: uas[ua_m.group(1)] += 1 print("Daily reads:") for day in sorted(daily): print(f" {day}: {daily[day]}") print("Top IPs:") for ip, cnt in ips.most_common(10): print(f" {ip}: {cnt}") print("User-Agents:") for ua, cnt in uas.most_common(10): print(f" {ua}: {cnt}")

正常输出类似：

Daily reads: 10/Jan/2025: 1 23/Jan/2025: 1 01/Feb/2025: 1 ... Top IPs: 192.0.2.10: 4 192.0.2.88: 3 User-Agents: GPTBot/1.0: 5 OAI-SearchBot/1.0: 2

有了这个脚本，就能复现类似“12 周 7 次”的观测基线。

3.4 实验周期与频次分析：7 次意味着什么

以 12 周为周期，如果总读取次数只有 7 次，平均约 12 天一次。但在实际分析时，不能只看平均值，要看时间分布。

有两种典型情况：

• 如果 7 次集中在前两周，说明部署初期爬虫发现过一次，后面因为内容没有变化，就不再频繁回来。
• 如果 7 次均匀分布在 12 周里，说明站点在爬虫调度队列中保持了稳定的回访频率。

第一种情况更常见。llms.txt本身不会触发“内容更新”信号，它只是降低爬虫理解站点的成本。要让爬虫保持回访，更多要依赖站点内容本身的变化，比如新增文章、更新文档、调整首页结构。

所以，12 周 7 次这个数据更适合作为基线：说明你的站点已经被 OpenAI 爬虫“发现”，但不代表它进入了高频抓取名单。

4. 为什么 12 周只被读取 7 次：从爬虫机制看几个关键因素

4.1 爬虫不是每时每刻都来，抓取策略决定低频率

大模型爬虫和搜索引擎爬虫的工作方式不完全一样。搜索引擎需要尽可能全面地索引全互联网页面，因此会维护庞大的抓取队列，对重要页面甚至可以达到按天甚至按小时更新。大模型爬虫的优先级更偏向“理解站点结构”和“发现高质量内容”，不会对每个零散页面做高频回访。

OpenAI 爬虫在发现一个站点后，通常会先读取robots.txt，再尝试读取llms.txt，然后根据文件中的链接访问少量核心页面。这个过程完成后，它会根据站点更新频率决定下一次回访时间。对于大多数更新不频繁的个人博客或企业官网，回访周期可能在数天到数周之间。

因此，12 周 7 次并不是异常现象。它反映的是这一个站点群体在 OpenAI 爬虫队列中的平均优先级，而不是llms.txt失效了。

4.2 站点权重、内容更新频率和 sitemap 的影响

爬虫判断一个站点是否值得回访时，会综合参考多个信号：

• 外链数量和质量：被越多外部站点引用，爬虫越容易认为该站点有权威性。
• 内容更新频率：新页面的增加速度和规律性会触发重新抓取。
• sitemap.xml 的提交和变化：sitemap 更新会提醒爬虫“这里可能有新内容”。
• 页面的可访问性和响应速度：频繁 5xx、超时和重定向会降低抓取优先级。

一个很常见的组合是：站点有一个稳定更新的博客，每周发一篇新文章，同时每次发布后更新sitemap.xml。这种情况下，AI 爬虫回访频率会比 12 周 7 次更高。如果站点的内容半年都不变，即使llms.txt写得再规范，爬虫也没有足够动力频繁回来。

4.3 robots.txt 里的路径限制和 Crawl-delay 设置

有些站点为了防止爬虫对服务器造成压力，会在robots.txt里写Crawl-delay: 3600，意思是要求爬虫至少间隔 3600 秒才能再次抓取。但Crawl-delay不是所有爬虫都认可，不同引擎有不同解释。对于 OpenAI 爬虫，官方文档更多强调的是通过 robots.txt 和 IP 访问频率控制系统来管理抓取压力。

如果站点曾经对 GPTBot 返回过429 Too Many Requests或403 Forbidden，爬虫会记录这些失败信号，并主动降低后续抓取频率。更严重的情况是站点在前端通过 WAF 直接拦截了 OpenAI 官方 IP 段，这会导致爬虫完全无法访问，连llms.txt也不例外。

所以在排查“为什么读取次数低”时，先看历史日志里有没有大量 5xx 和 429，再检查robots.txt是否曾经禁止过相关 UA。这些策略性的限制，往往比文件本身更能解释低频访问。

4.4 实验结论可能被站点规模稀释：83 个站点的样本问题

83 个站点这个样本量，和整个互联网的站点数量相比非常小。更关键的是，这 83 个站点可能是不同域名、不同类型、不同流量的组合。有的站点可能每天都有新文章，有的站点只是静态介绍页。最后统计出 7 次读取，很可能来自其中少数几个站点。

如果要做一份更严谨的报告，至少要拆出三个指标：

• 83 个站点中，被 OpenAI 爬虫读取过llms.txt的站点数量。
• 读取次数按站点分布，而不是只看总量。
• 站点内容更新频率和读取次数之间的相关性。

因此，不要得出“llms.txt 没用”或“OpenAI 不重视 llms.txt”这类结论。它只能说明，在这组站点里，OpenAI 爬虫对llms.txt的读取整体偏低频，需要一个更大的样本和更长的观察周期才能得出更稳定规律。

5. 常见问题排查：llms.txt 放了却没被读取时怎么办

5.1 现象 1：爬虫来了但没请求 llms.txt

如果日志里能看到 GPTBot 访问了其他页面，但就是没有访问/llms.txt，优先检查以下原因。

第一，robots.txt是否对/llms.txt设置了禁止规则。有些通用 robots 模板会写Disallow: /*.txt$，这个规则会拦截 llms.txt。修正后要等爬虫下一次读取 robots.txt 才会生效。

第二，CDN 缓存是否把旧文件缓存了。如果源站llms.txt已经更新，但 CDN 节点上缓存的还是 404 页面，爬虫请求时就会拿到错误结果。可以在 CDN 控制台强制刷新该 URL。

第三，爬虫是否因为之前遇到 5xx 而停止回访。检查同一时段内服务器返回的状态码，如果站点稳定性差，爬虫会逐渐减少抓取。

grep "GPTBot" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c

这个命令会输出 GPTBot 请求的所有状态码次数，能快速发现是 200 多、还是 404、403、500 居多。

5.2 现象 2：llms.txt 返回 404 或 403

404 通常是路径问题。很多站点把llms.txt写成了llms.txt.txt，或者放到了子目录比如/static/llms.txt，但爬虫只会去根路径查看。用 curl 直接验证：

curl -s -o /dev/null -w "%{http_code} %{content_type}\n" https://example.com/llms.txt

预期输出是200 text/plain; charset=utf-8。如果输出是 404，检查文件位置和 Web 服务器配置。

403 更可能是安全策略导致的。比如 WAF 规则对未知后缀文件进行拦截，或者云厂商的对象存储默认权限是私有。对于对象存储桶，要确认文件有公开读权限，或者设置了 CDN 回源鉴权。

5.3 现象 3：日志里出现 User-Agent 但不是 OpenAI 官方爬虫

在统计 OpenAI 爬虫时，不能只凭 User-Agent 字符串就下结论，因为有很多第三方爬虫会在 UA 里携带 “OpenAI” 字样，但它们并不是 OpenAI 官方爬虫，数据也不代表真实的 GPTBot 行为。

有一个常见例子是某些 SEO 工具模拟 GPTBot 的 UA 去检查站点内容，或者在 UA 中混入“OpenAI”关键词来伪装。为了准确识别，建议做两层校验：

• 第一层：UA 是否包含GPTBot或OAI-SearchBot。
• 第二层：反查来源 IP 的 PTR 记录或 ASN，确认这些 IP 属于 OpenAI 对外公开的爬虫网段。

nslookup 192.0.2.10

如果 PTR 记录中出现openai.com相关的 hostname，可信度会更高。只保留同时通过两层校验的请求，再统计读取次数，数据才更有参考价值。

5.4 排查链路与验证命令清单

无论遇到哪种现象，都可以按下面这条链路排查：

1. 确认 DNS 解析正确。
2. 确认robots.txt没有禁止 GPTBot 或 OAI-SearchBot。
3. 确认llms.txt在根目录且直接 URL 返回 200。
4. 确认响应头Content-Type是text/plain或text/markdown。
5. 确认 CDN 和 WAF 没有拦截.txt请求。
6. 确认访问日志记录了完整 UA。
7. 用 UA 和 IP 双重校验，排除伪装爬虫。

可以把这些步骤整理成一组命令，方便每次发布后验证：

echo "== 1. DNS ==" dig example.com +short echo "== 2. robots.txt ==" curl -s https://example.com/robots.txt echo "== 3. llms.txt status ==" curl -s -o /dev/null -w "%{http_code}\n" https://example.com/llms.txt echo "== 4. content type ==" curl -sI https://example.com/llms.txt | grep -i content-type echo "== 5. recent openai crawler access ==" grep -E "GPTBot|OAI-SearchBot" /var/log/nginx/access.log | tail -20

这条链路跑完，基本能定位绝大多数“放了 llms.txt 却没被读取”的问题。

6. 从实验数据到生产实践：llms.txt 的优化方向与最佳实践

6.1 不同站点类型的 llms.txt 写法差异

不是所有站点都适合用同一种llms.txt结构，要根据站点类型决定放什么链接、放多少链接。

博客类站点可以这样写：

# Backend Notes > 专注后端工程和可观测性的技术博客。 ## Latest Articles - https://example.com/posts/nginx-request-log-analysis: 从 Nginx 日志中提取关键请求字段 - https://example.com/posts/python-asyncio-timeout: asyncio 中设置超时的几种方式 - https://example.com/posts/llms-txt-deployment: 在静态站点上部署 llms.txt 的完整流程 ## About - https://example.com/about: 博主介绍与联系方式

核心原则是：llms.txt里只放有价值且长期稳定的入口。临时促销页、带签名参数的链接、需要 JS 才能跳转的地址都不适合放进去。

6.2 把 llms.txt 和 sitemap、内容更新联动起来

sitemap.xml通常包含站点全量 URL，llms.txt只需要放最核心的入口。两者可以配合使用：sitemap 告诉爬虫“我有这么多页面”，llms.txt 告诉爬虫“这些页面最值得先看”。

如果你维护的是一个博客，每次发布文章后都手工修改llms.txt很容易遗漏。可以用一段简单的脚本，在发布时自动更新“Latest Articles”部分。比如从文章目录的前 10 篇生成链接：

#!/usr/bin/env python3 from pathlib import Path POSTS_DIR = Path("content/posts/") LLMS_TXT = Path("public/llms.txt") posts = sorted(POSTS_DIR.glob("*.md"), key=lambda p: p.stat().st_mtime, reverse=True)[:10] lines = ["# Backend Notes", "", "> 专注后端工程和可观测性的技术博客。", "", "## Latest Articles", ""] for p in posts: slug = p.stem title = p.read_text(encoding="utf-8").splitlines()[0].lstrip("#").strip() lines.append(f"- https://example.com/posts/{slug}: {title}") LLMS_TXT.write_text("\n".join(lines) + "\n", encoding="utf-8")

把这段脚本挂到 CI 或 Git 钩子里，每次发布文章后自动重新生成llms.txt，就能保证文件内容始终和站点最新内容同步。对爬虫来说，一个内容有变化的llms.txt，比一个半年不变的静态文件更有回访价值。

6.3 可复用发布检查清单

在把部署llms.txt纳入日常工作后，可以参考下面这份发布检查清单：

这份清单的目的是让llms.txt成为站点发布流程的一部分，而不是一个部署完就遗忘的静态文件。

6.4 后续可以关注的扩展方向：更多 AI 爬虫和结构化链接

OpenAI 不是唯一对外公开爬虫规则的厂商。实际环境中，还有其他 AI 搜索产品、知识库工具、RAG 系统也会抓取网站。未来可以在同一套日志统计体系里加入更多 User-Agent 规则，观察不同 AI 爬虫对llms.txt的读取频率。

从规范演进角度看，llms.txt目前还是一个相对简单的文本协议，它不提供访问统计、不支持权限校验、也不保证所有爬虫都会读取。但它为站点和 AI 之间建立了一个低成本的“内容目录”机制。如果你的站点有很多结构化内容，比如 API 文档、安装指南、价格表，llms.txt能让 AI 工具更快找到正确答案，间接提升站点在 AI 搜索场景中的出现频率。

回到开头那组实验数据：83 个站点部署llms.txt，12 周里 OpenAI 爬虫读取了 7 次。它真正提醒我们的不是“读取次数太少”，而是“可发现性和内容质量才是长期竞争力”。部署llms.txt只是第一步，持续更新站点内容、维护 robots.txt、分析访问日志、观察爬虫行为，才是决定站点能否被 AI 工具持续使用的关键。