“做了 llms.txt真正有用的是把它当 API 来设计而不是当文件来发布。”最近在技术社区看到关于 llms.txt 的讨论明显变多。有人把它叫做“给大模型看的 robots.txt”也有人说这是“AI 时代的 sitemap.xml”。这些说法都对了一半。不少人兴致勃勃地写好 llms.txt、部署到线上然后等了一个星期发现网站流量没涨、AI 回复里也没有自己的品牌信息于是产生一个灵魂拷问Nobody fetched my llms.txt到底哪里出了问题这篇文章从 llms.txt 的真实定位讲起逐步拆解文件规范、创建方式、部署验证、被忽略的原因以及真正值得投入的工程策略。读完你可以判断自己的 llms.txt 到底缺了什么以及下一步应该把力气花在哪里。无论你是个人站长、内容平台开发者还是正在做 AI 搜索、知识库产品的工程师这篇文章都能帮你少走一段弯路。1. 为什么 llms.txt 最近突然被频繁讨论打开任意技术社区llms.txt 近期的讨论热度都在上升。很多人第一次听到它是在某个大模型应用项目的 README 里第二次是在同事分享的“AI 网站检索标准”文章里第三次就是自己动手建站时被提醒“记得加 llms.txt”。要说清楚这件事需要先把概念和动机分开。动机层面上大模型应用爆发后模型本身越来越强但模型能拿到什么信息依然取决于检索和上下文喂给它的内容。传统网页由 HTML 构成HTML 里充满了样式、脚本、导航、广告区块。对人类的视觉阅读很友好对 LLM 的语义读取却不友好。即使爬虫拿到了网页还要做正文抽取、去噪、清洗、转 Markdown工程链路长且容易出错。llms.txt 想解决的正是这个问题让网站主动提供一个经过整理的 Markdown 版内容清单告诉语言模型“我有哪些页面、这些页面是干什么的”。这里要区分三个文件文件服务对象核心作用robots.txt搜索引擎爬虫声明哪些路径可以爬、哪些不能爬sitemap.xml搜索引擎爬虫列出站点 URL帮助爬虫发现页面llms.txtLLM 及相关工具提供 Markdown 格式的站点摘要和页面索引判断就一句话llms.txt 不是搜索引擎优化工具而是 LLM 上下文优化工具。它提升的不是收录率而是模型理解网站的效率和准确度。从当前生态看llms.txt 仍处于提议标准阶段各家大模型厂商和垂直搜索引擎并未统一接入。但它已经出现在不少开源项目、文档站生成器和个人博客里。因为它实现成本低收益可预期所以讨论热度持续上升。2. llms.txt 的文件规范与核心原理llms.txt 的定位很像一份“给 AI 看的站点白皮书”。它不是一个复杂规范要点集中在三个部分。2.1 文件位置与命名约定俗成的放置位置是站点的根路径https://example.com/llms.txt这意味着部署 llms.txt 不需要额外的后端逻辑也不需要改站点架构。只要能在根路径返回文本文件即可静态托管、Nginx、云存储都能做到。2.2 基础结构一个合法的 llms.txt 通常由三部分组成Markdown 注释形式的项目说明用于补充 H1 标题信息。站点概述块用 H1 标题加引用形式提供站点整体描述。文件索引块用列表形式列出内容区块每行包含三个字段标题、路径、描述。建议的基础模板如下# Example.com Example.com 是一个面向开发者的技术博客提供编程教程、工具评测和工程实践案例。 ## 技术教程 - [Python 入门教程](/python-basics.md): 面向初学者的 Python 语法和实战教程 - [Spring Boot 集成指南](/springboot-integration.md): Spring Boot 与常用中间件的集成步骤 ## 工具评测 - [API 调试工具对比](/api-tools-comparison.md): 主流 API 调试工具的优缺点分析结构看起来很简单但三个字段的写作质量直接决定这份文件是否可用。2.3 与 robots.txt 的本质区别robots.txt 是“禁止清单”告诉爬虫不要访问哪些路径。llms.txt 是“推荐清单”告诉模型优先阅读哪些内容。这两者可以同时存在也可以相互独立。实际场景中最合理的使用方式是robots.txt 管控抓取边界llms.txt 推荐高质量内容入口。3. 从零开始创建自己的 llms.txt 文件3.1 明确站点的 AI 场景创建之前想清楚你的内容最可能在哪些 AI 场景被用到。常见场景包括用户向 AI 客服提问产品功能AI 需要快速定位 FAQ 和文档。用户让 AI 推荐工具AI 需要读取评测文章判断优缺点。用户要求 AI 总结某个项目AI 需要理解项目简介、核心组件和技术栈。不同场景决定文件里放什么路径、什么描述。一个只放首页链接的 llms.txt 价值有限一个堆满全部 URL 的 llms.txt 也会削弱模型的选择准确率。3.2 控制文件大小建议把 llms.txt 控制在合理范围内。站点页面上千时不应该把所有 URL 都放进去而是提供分类、优先级和代表页面。通用做法是顶部写站点整体描述。每个栏目用二级标题区分。每个分类下列出 5 到 20 个高质量入口。完整内容列表交给其他机制比如进一步向模型提供按需检索的 API。3.3 描述写作原则路径后的描述不要写成关键词堆砌也不要照搬 HTML title。它应该是一句能帮助模型判断“这条链接是否满足用户当前问题”的语义说明。对比一下- [API 文档](/api/): API 接口文档 - [API 文档](/api/): 提供认证、订单、支付三类接口的完整调用示例包含 Java 和 Python 代码第二条描述显然更能帮助 LLM 做信息路由。描述写得好模型就能少拉取无关页面回答准确率也会更高。3.4 示例个人技术博客的 llms.txt# TechBlog TechBlog 是一个中文技术博客主要分享 Java 后端、Python 自动化、数据库设计和 AI 工程化实践。 ## 后端开发 - [Spring Boot 3 应用搭建实战](/posts/springboot3-setup.md): 从零搭建 Spring Boot 3 项目包含依赖管理和接口示例 - [MySQL 索引优化实践](/posts/mysql-index-tuning.md): 高并发场景下索引设计与慢查询排查 ## Python 自动化 - [Python 爬虫请求库对比](/posts/python-http-clients.md): Requests、httpx、aiohttp 的适用场景对比 - [Pandas 数据清洗入门](/posts/pandas-cleaning-101.md): 使用 Pandas 处理缺失值、重复值和异常值 ## AI 工程化 - [本地大模型部署方案](/posts/local-llm-deploy.md): Ollama、vLLM 与 llama.cpp 的部署选型 - [RAG 系统评估方法](/posts/rag-evaluation.md): 从检索质量到生成质量的分层评估思路这个文件可以直接放在静态站点根目录。如果你的博客生成器是静态的把 llms.txt 加到静态文件目录即可。4. 部署与验证不只是“放到服务器根目录”创建文件只是第一步部署方式和可访问性决定了后续能否被正常抓取。4.1 静态托管部署方式以 Nginx 为例可以确保根路径返回 llms.txtserver { listen 80; server_name example.com; location /llms.txt { root /var/www/example.com; default_type text/plain; } }如果你用的是 GitHub Pages、Cloudflare Pages、Vercel 这类平台直接把 llms.txt 文件放到静态资源目录的根路径即可。4.2 验证响应头发布后第一件事检查是否正确返回文本内容而不是 HTML 页面。curl -I https://example.com/llms.txt预期响应头类似HTTP/2 200 content-type: text/plain; charsetutf-8 cache-control: public, max-age3600如果返回了text/html说明请求被框架路由接管了需要在配置里放行这个路径。4.3 Python 解析验证示例用下面的脚本验证文件格式是否合理import requests import re url https://example.com/llms.txt resp requests.get(url, timeout10) resp.encoding utf-8 if resp.status_code ! 200: print(状态异常:, resp.status_code) exit(1) lines resp.text.strip().splitlines() link_count 0 for line in lines: if line.startswith(- [): link_count 1 title re.search(r- \[(.?)\], line) path re.search(r\]\((.?)\), line) desc line.split(): , 1) print(标题:, title.group(1) if title else N/A) print(路径:, path.group(1) if path else N/A) print(描述:, desc[1] if len(desc) 1 else 缺少描述) print(总计链接数:, link_count)这个脚本不验证链接是否全部有效但能快速发现标题缺失、路径缺失、描述缺失三类常见问题。4.4 链接有效性批量检查llms.txt 里给的路径如果大量失效模型抓取时会拿到 404降低整份文件的可信度。建议发布后用脚本做一次批量检查while IFS read -r line; do url$(echo $line | grep -oP (?\)\()[^)] | sed s|^/|https://example.com/|) if [ -n $url ]; then code$(curl -o /dev/null -s -w %{http_code} $url) echo $code $url fi done llms.txt当然只检查状态码还不够还需要确认这些路径确实包含了可供模型读取的 Markdown 或 HTML 内容而不是一片空白。5. 为什么还没人来抓取真实情况与常见误区这是标题里最尖锐的问题Nobody fetched my llms.txt。严格说绝大多数站点发布 llms.txt 之后确实不会立刻有大量抓取器访问。原因要从生态现状和产品逻辑两个层面看。5.1 提议标准还处在早期阶段llms.txt 目前是社区推动的提议标准有开源仓库、有讨论、有示例但还没有成为像 robots.txt 那样的行业共识。各家大模型厂商是否接入、以什么方式接入仍没有统一答案。这不是 llms.txt 的致命伤。早期标准的价值恰恰在于沉淀共识先让站点主知道“AI 时代需要主动提供语义化内容”再逐步影响工具链和模型厂商。指望发布当天就被所有 AI 应用读取在现阶段不现实。5.2 很多 AI 抓取器还没把 llms.txt 纳入主路径当前 LLM 获取网页信息的方式主要仍是传统爬虫链路发现 URL、抓取 HTML、清洗正文、转换为文本。llms.txt 只是额外信号不是唯一入口。对大模型应用来说更好的设计是先尝试读 llms.txt拿不到再走传统抓取。但这套逻辑依赖调用方主动实现标准未落地前很多产品不会投入开发。5.3 内容质量才是决定抓取价值的关键即使没有任何抓取器访问 llms.txt它本身仍然有价值。它把站点的高质量内容按语义结构整理了一遍。这会间接影响模型在回答问题时的偏好。当模型通过传统方式抓取页面时页面里如果包含清晰的 Markdown 结构、明确的分段和简洁的描述也会有更好的解析效果。换句话说llms.txt 写得好的站点往往其他页面的结构也清晰。两者是互为正反馈的关系不是单点决定论。5.4 常见误区把 llms.txt 当 Sitemap 用最典型的误区是把 sitemap.xml 里所有 URL 原样复制到 llms.txt然后用脚本每周全量生成。这会带来两个问题文件体积过大浪费上下文空间。模型读完一遍也没有重点反而无法高效路由。llms.txt 的正确设计是“精”而不是“全”。它更像一份菜单让模型按需点菜而不是把整个后厨的存货全部堆在门口。6. 常见问题与排查方法问题现象可能原因排查方式解决方案访问 llms.txt 返回 404静态托管目录不对或框架路由拦截检查请求日志和静态资源配置将文件放到站点根目录并放行路由返回类型是 text/htmlNginx 或框架匹配到了默认页面查看响应头 content-type配置 default_type text/plain中文乱码文件编码不是 UTF-8用编辑器查看文件编码统一保存为 UTF-8链接大量 404路径写错或页面已下线用脚本批量检查状态码修正路径清理失效链接AI 仍然答不出站点内容llms.txt 未被调用或内容价值不足检查抓取日志和官方接入文档优化描述质量提供按需检索接口重复内容过多把导航、标签页也写进去了人工审核路径列表只保留独立内容页面文件太大全量 URL 导入统计文件行数按分类只留高质量入口7. 最佳实践与工程建议7.1 把 llms.txt 当作 API 摘要来设计面向 LLM 的内容索引和面向搜索引擎的索引有本质差异。搜索引擎需要穷举 URLLLM 需要理解语义入口。写每个链接描述时想象一下“模型读懂这句话后能否决定是否打开这个页面”如果答案是“能”描述就是合格的。7.2 静态生成与数据库驱动的取舍小站点用静态文件最简单改动后重新部署即可。大站点建议用代码动态生成核心逻辑通常是从内容数据库查询分类和文章。按“分类 标题 路径 描述”的模板渲染。写入public/llms.txt或在请求时实时输出。通过 CI 流程校验链接和格式。动态生成的好处是内容更新不会滞后。坏处是需要保证输出排序稳定避免每次构建生成顺序不同导致文件频繁变动。7.3 监控与日志建议在 Nginx 或 CDN 层记录/llms.txt的访问日志定期观察是否有主流 AI 爬虫访问。如果发现某个 UA 持续抓取说明该平台的接入策略已经变化可以据此调整内容优化方向。日志示例grep llms.txt access.log | awk {print $1, $6, $7, $12} | sort | uniq -c | sort -nr | head7.4 隐私与权限边界llms.txt 的所有内容都是公开可读的不要写入内部接口、带敏感参数的路径、内网地址或未发布内容。它和 robots.txt 一样本身不提供访问控制。如果某些页面只允许登录用户访问不要放进 llms.txt。7.5 结合结构化数据一起使用llms.txt 解决的是“模型快速理解站点结构”的问题结构化数据解决的是“模型理解页面实体属性”的问题。两者互补。对技术文档站可以同时做到llms.txt 提供站点整体导读。页面内提供 JSON-LD 结构化数据描述文档类型、作者、更新时间。robots.txt 声明低价值路径禁止抓取。sitemap.xml 保留完整 URL 列表方便搜索引擎收录。这种组合方式在工程上是干净的不同文件各司其职最终服务于同一个目标让 AI 以更低成本理解站点内容。7.6 生产环境的变更节奏修改 llms.txt 不需要像修改核心服务那样走严格发布流程但建议遵守“先在测试环境验证多条抓取路径再同步到生产”。线上更新时注意 CDN 缓存过期时间。如果缓存设置过长可能出现文件已更新、但抓取器拿到的仍是旧版本的情况。建议把/llms.txt的cache-control设置为较短时长比如 600 秒既能降低回源压力也能及时反映内容变化。8. 从 llms.txt 到 AI 内容工程的全链路思考回到最初的疑问为什么我的 llms.txt 没人抓取最直接的回答是现阶段很多 AI 产品还没有把 llms.txt 纳入主抓取路径这是生态成熟度问题不是个人操作问题。但更有价值的回答是llms.txt 只是一个入口真正决定 AI 能否用好你站点内容的是下面三层结构第一层语法层。文件结构是否合法链接是否有效描述是否完整。这是最低门槛用脚本就能检查。第二层语义层。文件里的描述是否真正帮模型做判断内容分类是否符合用户提问习惯。这一层需要结合用户问题和搜索日志持续优化。第三层接口层。如果站点内容量很大光靠文件列表无法覆盖所有场景。更合理的做法是在 llms.txt 里给出核心入口同时提供一个按需检索的接口让模型根据用户问题动态获取更细致的内容。这个三层结构适合所有正在尝试 AI 化内容分发的团队。先守住语法层再打磨语义层最后扩展接口层。顺序不能反。9. 总结与后续实践建议如果你正在搭建个人博客或产品文档建议今天就把 llms.txt 加上。文件小、成本低、风险可控而且它迫使你用“机器视角”重新审视站点内容结构这个整理过程本身就有价值。做完之后重点不是每天盯访问日志而是持续优化两件事描述是否准确、路径是否有效。等到主流 AI 产品大规模接入 llms.txt 时你的站点已经具备清晰的内容语义结构不需要临时返工。后续值得深入学习的方向包括如何构建一个基于 llms.txt 的站点级 RAG 问答机器人。如何设计动态生成 llms.txt 的后端服务。如何分析 AI 爬虫的接入策略判断不同平台的抓取偏好。如何把 llms.txt、结构化数据、站点搜索日志结合起来做内容价值评估。llms.txt 目前还年轻没有统一的官方标准也缺少成熟的治理机制。但对工程师来说这是一个低成本参与机会你先跑通、先定义质量、先形成流程未来标准成熟时你已经领先一步。“Nobody fetched my llms.txt”不应该是终点。把它当成起点重新思考你的内容如何被机器读懂、被 AI 复用这条路比等一个标准落地更有价值。