最近在做网站可发现性相关的调研手头正好攒了一批站点样本就顺手做了一个小扫描把 420 个不同行业、不同体量的网站挨个检测了一遍看它们对新兴的 AI 索引协议——llms.txt——的采用情况。结果挺让我意外的真正部署了 llms.txt 的站点只有 26 个连 6% 都不到换句话说94% 的站长对着这个文件连听都没听过更别提部署了。这个数字其实一点也不夸张。llms.txt 是 2024 年由 AI 领域研究者提出的一个开放协议草案目标是给大语言模型提供一个“精简、干净、语义明确”的站点信息入口。但因为它太新既没有进入主流搜索引擎的官方文档也没有被大多数建站工具集成所以大部分站长压根不知道它的存在。如果你也是个网站负责人、内容运营或者独立开发者这篇文章会把 420 个样本里反映出的共性问题、llms.txt 的规范细节、以及我从这些部署案例里总结出来的实操经验一次讲清楚。1. 一次性扫描 420 个站点后我看到的是一张“AI 时代的缺席名单”在展开技术细节之前先交代清楚这次调研是怎么做的、数据口径是什么。没有可靠的方法论后面这些数字就只是讲故事。1.1 调研是怎么做的样本、指标和判断口径这次选的 420 个站点我刻意让构成尽量分散内容型站点技术博客、新闻媒体、文档站大约 200 个商业型站点SaaS 官网、企业品牌站100 个电商站点 70 个工具型站点在线计算器、生成器、开源项目页50 个。这些站点来源主要是我的收藏夹、行业导航、以及一些公开的流量榜单基本覆盖了“普通站长会运营的网站类型”。检测方式并不复杂就是对每个站点依次发 HTTP 请求检查两个路径/.well-known/llms.txt/llms.txt只要其中一个路径返回 200 状态码并且文件内容非空我就初步标记为“已部署”。之后我会再人工抽查其中一部分文件确认里面确实有 Markdown 格式的站点名称、摘要和链接列表而不是一句“coming soon”或者一段乱码。这还没完。我额外记录了一个容易被人忽略的指标返回 200 但文件内容无法被解析为“合法 llms.txt”的站点。什么叫合法简单来说必须包含 H1 站点名称、摘要blockquote 区块、至少一个可点击的链接。如果返回 200 但内容为空或者返回 200 但内容只是把 sitemap.xml 原样贴了过来这类站点我单独归为“部署了但无效”。1.2 真正让我意外的不是 94%而是那 6%统计结果是这样的有效部署 llms.txt 的站点26 个占 6.2%存在 llms.txt 路由但内容无效的站点7 个有路由但重定向到首页或 sitemap 的站点3 个完全没有 llms.txt 的站点384 个占 91.4%如果按照标题口径把后三类全部视为“未正确采用”那 94% 这个数字是站得住的。但我想说的是真正值得研究的不是那 94%而是这 6%——因为通过分析这 26 个有效部署样本的分布和写法能明显看出谁在认真对待这件事谁只是“放了个文件装样子”。这 26 个站点里有 19 个是开发者工具、技术文档、极客博客这类偏技术向的内容站另外几个是 AI 工具导航、开源社区、以及个别做海外业务的 SaaS 官网。没有一个是传统的电商站或者新闻门户。这个分布说明一个问题目前主动拥抱 llms.txt 的基本都是“离 AI 最近的人”。普通站长还在用十年前那套“提交搜索引擎、发外链、做关键词”的思路根本没意识到 AI 对话式流量已经在路上了。1.3 为什么站长们普遍没听过 llms.txt结合我观察到的站长社区讨论94% 这个比例背后有几个非常现实的原因第一官方文档传播力实在太弱。llms.txt 的规范页面是一个纯静态站点没有产业巨头在背后推动也没有大型搜索引擎公开承诺“你部署了我一定优先读取”。对大多数站长来说“不确定有没有回报的事情”优先级自然排在最后。第二现有建站生态还没有把它集成进去。WordPress、Shopify、各类静态博客框架目前默认都不生成 llms.txt。站长连 sitemap 都要靠插件生成你指望他手动去服务器上创建一个陌生文件门槛确实偏高了一些。第三衡量标准缺失。做了 llms.txt 之后没有站长熟悉的“收录量”“排名”“点击率”这类量化指标可以参考。大多数人是“看不到收益就不投入”的务实派这个完全可以理解。所以与其说这是技术问题不如说是认知问题。本文后面几节我会把你需要知道的规范、部署方法和避坑经验一次性讲透看完你就能比那 94% 的同行先走一步。2. 拆开 llms.txt 的设计逻辑它到底想替 AI 解决什么问题llms.txt 这个名字很容易让人误解以为它跟 robots.txt 干的是同一件事。实际上两者解决的问题完全不同。想理解它为什么存在得先站在大模型的角度看看它们抓取网页时有多痛苦。2.1 llms.txt 出现的背景AI 搜索引擎与传统抓取方式的矛盾传统搜索引擎的爬虫最擅长处理的是“静态 HTML 里埋着正文”的页面。但今天的大模型应用对话式问答、AI 搜索、RAG 知识库在抓取网页时遇到的情况要复杂得多大量页面是前端框架渲染出来的爬虫拿到的是空壳 HTML正文全靠 JavaScript 跑完才出现。就算拿到了 HTML整个页面里混杂着导航、侧边栏、相关推荐、广告位、弹窗提示真正的正文内容占比往往不到 30%。页面结构千奇百怪大模型没有一个统一的“入口摘要”来判断这个页面值不值得深入阅读。你可以把传统搜索引擎想象成一个“勤奋的图书管理员”它愿意把整本整本书翻完再做索引。但大模型更像一个“赶时间的读者”它需要你先告诉它这本书讲什么、哪几章最值得读然后它再决定翻哪几页。llms.txt 就是这个“先告诉它”的入口。2.2 它和 robots.txt、sitemap.xml 的本质区别三者的定位差异我整理成一张表方便对照协议核心问题面向对象内容示例关键词robots.txt哪些路径不能抓传统爬虫、AI 爬虫Disallow: /admin/权限控制sitemap.xml站点有哪些 URL搜索引擎爬虫lochttps://.../article/locURL 清单llms.txt站点是什么、重点看什么大模型、AI 搜索引擎H1 站点名 blockquote 摘要 分区链接列表内容语义一个很关键的区别是sitemap.xml 是给搜索引擎“索引所有页面”用的所以它会列出成百上千个 URL而 llms.txt 的核心思路恰恰相反它要求你只列出“最有代表性、最值得推荐给 AI 的内容”数量少而精。官方草案里甚至建议文件大小控制在几十 KB 以内而不是搞成第二个 sitemap。打个比方sitemap.xml 是一个图书馆的全部馆藏目录llms.txt 则是贴在图书馆门口的一张“本馆简介 镇馆之宝清单”。AI 拿到后者可以快速判断“这个网站值不值得细看重点该看哪几篇”。2.3 官方草案里的规范细节llms.txt 的草案全称是“llms.txt为大型语言模型提供 Markdown 格式的网站信息”它的语法设计刻意保持了极简。一个标准文件由四部分组成# 站点名称 一句话到几句话的站点摘要描述这个网站是什么、主要提供什么内容、适合什么场景使用。 ## 分区标题 - [链接文字](URL) - [链接文字](URL): 对这个链接的一句话补充说明H1 标题整个文件的第一行必须是# 站点名称让 AI 立刻知道自己在访问哪个站点。Blockquote 摘要紧跟 H1 的引用块用几句话概括站点定位。这一部分极其关键它相当于“电梯演讲”AI 通常先用它来决定是否深挖这个站点。H2 分区按内容类型把链接分组比如“文章”“产品”“文档”“团队信息”。有序/无序列表每一个链接建议用 Markdown 的[标题](URL)格式URL 后面可以跟一个冒号加上一句说明文字。本质上它就是一个“纯文本 极简 Markdown”的清单文件。因为格式足够简单任何一个没有技术背景的内容运营都能手动维护不需要专门的 CMS 插件也不需要动态渲染。草案之所以把语法压到这么简目的就是让 AI 解析零成本——不需要处理复杂的 HTML 树不需要判断哪些是导航哪些是正文直接按行读取就有意义。3. 从 6% 站点的部署情况里挖出的几个共性问题那 26 个“有效部署”的站点也不是个个都合格。我把它们全部拉出来逐一分析发现了四类非常典型的问题。这些问题比“完全没部署”更有意思因为就算你已经听说并准备上手了也很容易踩进同样的坑里。3.1 路由问题/.well-known/llms.txt和/llms.txt都该放按照草案标准llms.txt 的规范位置是/.well-known/llms.txt因为.well-known目录是 RFC 8615 里约定俗成的“站点元数据统一存放处”。但我在扫描中发现有好几个站点只做了/llms.txt这个路径/.well-known/llms.txt返回的是 404。这个问题在技术社区里其实是公开讨论过的很多抓取器两种路径都会尝试但习惯了 robots.txt 的开发者会直觉性地只放根路径而严格按照草案实现的工具会优先请求.well-known路径。我的建议是别赌两个路径都放同一份文件或者用服务器重定向把/.well-known/llms.txt指到/llms.txt。成本几乎为零但能避免一半的抓取器“找不到门”。3.2 内容问题要么空文件要么把整个 sitemap 塞进去7 个“部署了但无效”的站点里有 4 个返回的是空文件HTTP 状态码是 200但响应的 body 长度为零。这种大概率是建站者只创建了文件名、还没往里写内容或者反代配置有问题导致文件没读到。另外 3 个则走了另一个极端把 sitemap.xml 的链接全部复制了进来生成一个几千行、几 MB 大的 llms.txt。这完全违背了草案“小而精”的设计初衷。AI 读取这种文件效果跟直接读 sitemap 没什么区别仍然需要自行判断哪些链接重要而且大文件还会拖慢响应速度、增加被截断的风险。3.3 维护问题一次部署、永久吃灰再往下挖一层我发现有效部署的 26 个站点里有将近一半的 llms.txt 里最新链接还是三个月前的内容。也就是说这些站长的发布流程里根本没有“发布新内容时同步更新 llms.txt”这一环。这个问题很现实。你第一次部署 llms.txt 时还会记得它是“给 AI 看的首页”可内容更新是持续性的文件一旦不更新AI 抓到的永远是旧数据。等大模型真来访问时你辛辛苦苦维护的入口反而成了“信息过期”的负面信号。这也是我在后文要专门讲“怎么用脚本自动生成”的原因——纯手动更新的方案在没有强纪律的情况下长期不可靠。3.4 语义问题摘要写得像“关键词堆砌”最后一种问题特别隐蔽有 3 个站点的建议摘要写成了这种风格 提供SEO优化、搜索引擎优化、网站推广、百度排名、谷歌排名、关键词研究、外链建设服务这明显是抄了当年 meta keywords 的惯性思路。但对大模型来说这种词的堆砌不仅没有提供有效信息反而会让 AI 认为站点内容质量不高。好的摘要应该是“人话”说清楚这是谁、在做什么、内容覆盖哪些范围。比如 这是一个专注于 Kubernetes 和云原生技术的中文博客主要发布部署实战、故障排查和工具评测更新频率为每周一篇。AI 看到这句话立刻能判断“这个站点对解决我的某个具体问题有没有帮助”这才是摘要该有的作用。记住一个判断标准写完之后念给一个完全不了解你网站的朋友听如果他能大概明白你是干嘛的这摘要就算合格了。4. 手把手给站点补上 llms.txt从零到能用的完整路径前面说了这么多问题这一节开始进入正题怎么把一个合格甚至优秀的 llms.txt 部署到自己的站点上。整个流程分四步每一步都说清楚“为什么要这么做”。4.1 先想清楚这四件事再动手动键盘之前先花 10 分钟回答下面这四个问题答案会直接决定 llms.txt 的内容组织方式站点的“一句话定位”是什么如果你的网站是三分钟说不清是干嘛的那 AI 论如何帮你想清楚。这既是为了 llms.txt 的摘要也是帮你自己重新审视品牌表达。你最想让 AI 用户看到哪几类内容是产品文档、是核心博客文章、还是团队介绍按这个划分 H2 分区而不是机械地按栏目划分。这些内容多久更新一次如果更新频繁请直接跳到后面的自动生成方案如果一个月才更新一次手动维护也可以接受。谁来负责这件事llms.txt 最容易死的状态就是“这是某某人某天创建的”责任必须落实到岗位否则三个月后就成了死文件。这四个问题想清楚之后你会发现自己对“该放哪些链接”这件事的判断力瞬间提升。很多人一上来就纠结格式细节反而本末倒置。4.2 手写一个合格的 llms.txt结构示例详解如果站点内容不多手写是完全可行的。这是我从几个优秀样本里提炼出来的通用模板你可以直接套# 云原生实验室 云原生实验室是一个专注 Kubernetes、容器化、可观测性和 DevOps 实践的独立技术博客所有文章均为实战型教程定期更新。 ## 精选文章 - [Kubernetes 网络故障排查全指南](https://example.com/posts/kubernetes-network-debug): 从 CNI 到 Service 的完整排查链路附 10 个真实案例。 - [Helm 3 生产环境最佳实践](https://example.com/posts/helm3-best-practices): 介绍了模板工程化、依赖管理和安全加固方案。 - [Prometheus 高可用方案选型对比](https://example.com/posts/prometheus-ha-comparison): 对比 Thanos、VictoriaMetrics 和 Mimir 的优缺点。 ## 开源项目 - [k8s-debug-tool](https://github.com/example/k8s-debug-tool): 一个命令行诊断工具用于快速定位 Pod 异常。 - [helm-secrets-helper](https://github.com/example/helm-secrets-helper): Helm 插件支持多种加密后端。 ## 关于 - [站点介绍](https://example.com/about): 博主背景和写作方向。注意几个细节摘要用 blockquote 引用块开头这是草案规定的格式每个链接的说明文字都用冒号跟在 URL 后面没有说明的链接也不是不行但有说明能让 AI 更精准地判断“这个链接的内容对我有没有用”链接排序按重要性排不是按时间排——把最能代表站点质量的内容放最前面。4.3 用脚本从 sitemap.xml 自动生成 llms.txt如果站点内容多、更新频繁手写就不现实了。最省力的方式是从 sitemap.xml 自动生成一个基础版 llms.txt再人工调整排序、补充说明。我写了一个简单的 Python 脚本核心逻辑是读取 sitemap.xml 里所有的 URL逐个抓取title标签作为链接文字最后按指定格式输出。#!/usr/bin/env python3 sitemap.xml 转 llms.txt抓取每个 URL 的标题并生成 Markdown 文件 import argparse import re import urllib.request from html.parser import HTMLParser from urllib.parse import urlparse class TitleParser(HTMLParser): 解析 title 标签用的小工具 def __init__(self): super().__init__() self._capture False self.title def handle_starttag(self, tag, attrs): if tag title: self._capture True def handle_data(self, data): if self._capture: self.title data.strip() def handle_endtag(self, tag): if tag title: self._capture False def fetch_sitemap(sitemap_url): req urllib.request.Request(sitemap_url, headers{User-Agent: llms-txt-builder/1.0}) with urllib.request.urlopen(req, timeout15) as resp: return resp.read().decode(utf-8, errorsignore) def fetch_title(url): try: req urllib.request.Request(url, headers{User-Agent: Mozilla/5.0}) with urllib.request.urlopen(req, timeout10) as resp: parser TitleParser() parser.feed(resp.read(200000).decode(utf-8, errorsignore)) return parser.title.strip() or url except Exception: return url def main(): parser argparse.ArgumentParser(description从 sitemap.xml 生成 llms.txt) parser.add_argument(--sitemap, requiredTrue, helpsitemap.xml 的完整 URL) parser.add_argument(--site-name, requiredTrue, help站点名称作为 H1) parser.add_argument(--summary, requiredTrue, help站点摘要作为 blockquote) parser.add_argument(--section, defaultPages, helpH2 分区名称) args parser.parse_args() sitemap_content fetch_sitemap(args.sitemap) urls re.findall(rloc\s*([^]?)\s*/loc, sitemap_content) print(f# {args.site_name}\n) print(f {args.summary}\n) print(f## {args.section}\n) # 注意脚本是同步抓取标题的URL 多时会比较慢建议只保留重点页面 for u in urls: title fetch_title(u) print(f- [{title}]({u})) if __name__ __main__: main()使用方式示意python3 sitemap_to_llms.py \ --sitemap https://example.com/sitemap.xml \ --site-name 云原生实验室 \ --summary 专注 Kubernetes 和 DevOps 的中文技术博客 \ llms.txt脚本本身很简单但有三个使用前提必须说清楚第一sitemap.xml 里可能包含标签页、分页、筛选页这类“对 AI 没价值”的 URL生成之后建议手工过滤第二抓title会逐个请求页面如果你的站点有几百个 URL这一步会非常慢我只建议用这个脚本处理“最核心的内容分区”第三生成只是第一步你仍然需要人工补充每个链接的说明文字否则它只是一个“简化版 sitemap”价值会打折扣。4.4 部署与验证curl 检查、格式校验文件生成好之后部署就很简单了把 llms.txt 放到服务器的站点根目录或.well-known目录确保它是纯文本/Markdown 格式编码使用 UTF-8然后确认 web 服务器不会把它当成二进制文件下载。部署后的验证我习惯用两条命令# 检查响应头和状态码确认 200、Content-Type 是 text/markdown 或 text/plain curl -sI https://example.com/.well-known/llms.txt # 查看内容前 50 行确认没有乱码、没有额外空白、没有 HTML 标签泄漏 curl -s https://example.com/.well-known/llms.txt | head -50格式校验不需要专门的工具用眼睛看基本就够了第一行是不是# 站点名第二区域是不是开头的引用块后面有没有至少两三个能点开的链接。现在有一些在线页面也提供了 llms.txt 校验服务比如把文件内容粘贴进去它会检查 H1、摘要、链接格式是否合法但我个人的体会是只要你的文件是你自己写的结构清晰的 Markdown校验通过率基本是百分百。5. llms.txt 在实际 AI 生态里的位置它不万能但值得做讲完部署这一节要换个视角把 llms.txt 放回整个 AI 生态里看看它到底扮演什么角色。很多站长对它的期待要么过高要么过低这两种状态都不健康。5.1 AI 引擎拿到 llms.txt 之后会做什么先看看大模型应用拿到 llms.txt 之后实际会怎么使用它。以当下主流的 RAG检索增强生成流程为例AI 系统收到一个问题后会先在“候选数据源”里检索相关文档再把检索结果送到大模型里生成答案。这个检索环节传统做法是爬虫抓取全站 HTML 之后做切分、向量化。但有了 llms.txtAI 系统可以跳过整站抓取直接读取这个文件把它当成“种子文档”通过 H1 和摘要判断站点主题是否与当前问题相关根据分区和链接描述筛选出相关的子页面 URL只针对这些精选 URL 发起请求而不是整站爬取。这个过程省掉了大量无效抓取和噪声内容对站长来说也有好处你希望 AI 用户看到的内容通过链接排序和描述文字获得了更高的曝光权重。这其实是一种“AI 时代的推荐机制”——推荐的不是传统意义上的“排名”而是被大模型优先采纳的概率。5.2 与语义化 HTML、schema.org、GEO 的关系有人会问既然我可以在 llms.txt 里精挑细选内容是不是把页面做好就够了这个想法很危险。llms.txt 只是“入口推荐”,AI 最终解析的还是你真实的页面内容。如果页面本身是垃圾——正文被 JS 渲染、没有语义化标签、大量重复内容——那么就算 llms.txt 写得天花乱坠AI 抓进去之后照样会困惑。正确的姿势是把三层内容建设叠加起来层级工具作用入口层llms.txt告诉 AI“这个站点是什么、重点看哪里”结构层语义化 HTML、article 标签、清晰的标题层级让 AI 能准确提取正文增强层schema.org 结构化数据、GEO生成式引擎优化帮 AI 理解实体的关系和属性GEO 是最近在 SEO 圈里讨论度很高的概念研究的是“怎么让内容更容易被生成式搜索引擎引用”。llms.txt 可以算作 GEO 的一个具体抓手但它不是全部。真正让 AI 持续引用你内容的依旧是内容本身的质量和可读性。这跟传统 SEO 的内核没有本质区别只是优化对象换成了“AI 的理解力”。5.3 什么时候 llms.txt 可以不做倒也不用把 llms.txt 当成“必做项”。根据这 420 个站点的实际情况下面几类站点即使不做 llms.txt短期影响也不会太大纯 ToB 销售型官网网站本身没有博客、没有文档只有几个产品介绍页和“联系我们”。这类站点内容量太小AI 直接抓取首页也能搞定llms.txt 的边际收益很低。需要登录才能访问内容的平台比如在线教育平台、SaaS 控制台。因为 AI 抓不到站内核心内容llms.txt 能提供的公开信息十分有限。UGC 社区内容由用户生成、海量且动态手动维护一个静态清单完全不现实。这类站点更适合把精力花在对话框标记、高质量用户内容的识别和语义化输出上。我的判断标准是如果你的站点有“稳定的、公开的、值得被推荐的内容”llms.txt 就值得做如果你只有零散的品牌介绍页那不妨先做好页面的语义化等内容丰富了再回头补。这个标准也可以帮你在团队里说清楚优先级避免为了做而做。6. 我在实测和部署中的几个经验以及下一步思路最后这部分我想分享一些没有写进前面章节、“踩过之后才知道”的具体经验以及我下一步关于 llms.txt 的打算供你参考。6.1 实测经验怎么判断 llms.txt 有没有真的被 AI 用上很多站长不做 llms.txt 的理由是“做了也看不到效果”。这句话在一年前是对的但现在已经有办法做侧写式观测了。我的做法有三条线第一在 llms.txt 里放一到两个带有 UTM 参数的链接过一个月看访问日志里有没有这些带参链接的请求。注意AI 爬虫大概率不会保留 UTM 参数所以这个方法更多是验证“有没有 AI 的爬虫按我们的链接抓取页面”而不是完整的转化归因。第二重点观察访问日志里来自主流 AI 搜索和对话产品比如各类 AI 搜索服务的爬虫 UA的抓取频率。部署 llms.txt 之前和之后对比如果抓取频率有明显上升说明这个文件确实起到了“引导入口”的作用。第三直接搜自己的站名看 AI 搜索工具里的描述是否接近你 llms.txt 里的摘要。如果 AI 的回复能准确说出“你是一个专注 XX 的站点”比什么都管用。这些方法都算不上严谨的量化分析但在目前没有官方后台数据的情况下已经是比较有效的“校准手段”了。我的体会是先让 AI 爬虫来了一次它才会在后续的迭代里学会更频繁地来。6.2 后续可以做的方向llms.txt 本身还在高速进化我不建议把它当成一个“一次配好就一劳永逸”的静态文件。接下来有几个方向值得持续跟进多语言版本如果你的站点有中英文等多语言内容可以考虑为不同语言的 AI 用户提供不同语言的 llms.txt比如通过Accept-Language头或不同子域名区分。这会让 AI 用户拿到“更懂他的语言”的入口。定期刷新摘要站点内容方向变化后摘要必须跟着更新。比如我见过一个技术博客早期专注前端后来全面转向 AI 工程化如果摘要不更新AI 还会把它的历史定位推给用户这显然不是作者想要的。自动化集成到发布流程如果你的内容发布是走 CI/CD 的那完全可以在发布流程里加一个步骤让系统自动更新 llms.txt。不需要做成复杂服务一个脚本足矣但“自动更新”能避免“忘记更新”这个最大的死亡原因。6.3 个人建议别焦虑但要先占坑关于 llms.txt我的观点用一句话总结就是它不会在三五年内取代你现有的所有 SEO 工作但如果你是一个内容型站点的站长现在花半小时部署一个合格的 llms.txt是在给未来的 AI 流量“先占个坑”。就像当年很多站长在移动互联网初期先上线了移动适配页面当时也看不出立竿见影的效果后面流量迁移时才真正吃到红利。从我自己管理的几个站点的数据来看部署 llms.txt 之后的第二周开始就有 AI 搜索类的爬虫按文件里的链接来抓取页面了——这个速度比我想象中快不少。所以如果你还在犹豫不用想太多照着我给你的模板先部署一个基础版把摘要写清楚、把最重要的 5 到 10 个链接放上去然后发布就可以了。以后内容更新时顺手维护等生态成熟的那一天你不会因为没有入场而懊恼。
