如果你也曾在服务器上放了一个llms.txt文件然后打开访问日志等了一周发现连一个 AI 爬虫都没有来过——别急着怀疑自己。这个标题描述的状态其实是很多早期采用者的真实体验。llms.txt是 2024 年开始在技术社区里被反复讨论的一个倡议模仿robots.txt的命名方式在站点根目录放一个纯文本 Markdown 文件用统一格式告诉大语言模型“这个网站有哪些值得读的内容”。听起来很美好但现实是把一个文件放在根目录不等于它会被自动发现、自动读取、自动变成模型知识。掉进这个坑之后我有一个越来越明确的判断llms.txt的价值不在于“创建”而在于“内容索引链路”的完整程度。文件本身只是入口真正决定它能不能被用到取决于站点结构、内容组织、外部链接、监控验证这些环节有没有同时跟上。如果只有孤零零的一个文件没人抓是常态而不是意外。1. 先搞清楚llms.txt 到底想解决什么问题很多人第一次听说llms.txt会把它和robots.txt放在一起理解。这种直觉没错但很容易带来一个误解以为它是给爬虫指路的门牌。实际上它的目标并不是“让爬虫能爬到”而是“让大模型能更快理解一个网站的结构和重点”。1.1 从 robots.txt 到 llms.txt给爬虫的路标给模型的目录robots.txt解决的是“准许和禁止”的问题。它告诉搜索引擎爬虫哪些路径不能访问哪些目录不要索引sitemap 在哪里。它是一个控制访问边界的协议。llms.txt解决的是“理解成本”的问题。它不关心你能不能爬而是关心如果一个 AI 系统已经拿到了网站内容它如何用最小代价搞清楚这个网站是做什么的、哪些内容最重要、文档入口在哪里。为方便理解你可以把llms.txt想象成一本给 AI 看的“读者手册”封面是站点名称序言是站点摘要目录是分类过的核心链接。模型拿到以后不需要从一个完整的 HTML 页面里费劲剥离导航、广告和脚本直接按目录找它需要的章节就可以了。在设计思路上它更像“读书先看目录”的工作方式而不是“把所有文字都扔给模型”的粗暴做法。1.2 它解决的不是“抓取”而是“理解成本”网站内容的传统消费方式是浏览器获取 HTML然后交给人类渲染阅读。 HTML 里充满了标签、样式、脚本、导航栏、埋点代码模型工具去解析这些内容既耗时又容易产生噪声。llms.txt的做法很直接用一份标准化的 Markdown 文件把站点信息保留下来。它的结构大体上包含三个部分站点主要名称和描述一组“重要链接”通常是核心栏目、文档、最重要的内容入口可选的其他链接按主题或分类排列。这种格式的好处是让大模型不必做大量清洗直接拿到一个可读性很强的站点摘要。这实际上是把网站的“信息架构”单独提炼出来作为 AI 可以访问的公开元数据。所以它真正改善的不是“抓没抓到”而是“抓到了以后要用多少成本才能理解”。让 AI 系统更容易理解你的站点才是llms.txt的核心目标。1.3 你期望的“抓取”和协议真正能保证的“抓取”问题是很多人在部署这个文件时期望的是“立刻被 GPT 的爬虫收录以后模型回答里会出现我的网站”。这种期望把llms.txt当成了 SEO 外挂但协议本身没有这个能力。llms.txt目前只是一个社区倡议不是 W3C 等标准组织发布的正式标准也没有统一的注册中心。这意味着不是所有 AI 爬虫都会主动访问llms.txt即使访问了也不代表模型会在训练或检索时引用你的内容即使引用了距离“回答中生成你的网站”还有语义匹配、内容质量、可信度等多层门槛。从实际效果看在 2024 年和 2025 年的生态里你能验证到的“被读取”信号通常来自少数支持该协议的工具和爬虫。大多数大模型厂商仍然按照自己的抓取策略工作不会为了一个新文件改变整个管线。因此一个更理性的目标是把llms.txt当作所有 AI 可读内容里成本最低、结构最清晰的那一块基础设施而不是保证流量的魔法文件。2. 为什么“没人抓”是常态现实中的发现机制如果你用了个人的 VPS、博客或文档站部署llms.txt后没人请求这不一定是你做错了什么。真实世界里AI 系统发现一个新页面远比“把文件放到根目录”复杂得多。2.1 大模型是怎么发现网站内容的大语言模型的训练语料大多来自大规模的网络公开数据常见来源包括 Common Crawl、搜索引擎索引、特定领域数据集和学术语料。这些数据的采集通常是一个成熟的爬虫体系它们从一个已有的 URL 种子集合开始沿着页面里的链接不断扩展。这个流程有一个关键特点爬虫需要先知道一个 URL 存在然后才可能去请求它。如果你只是在网站根目录添加了一个新文件但没有任何已有页面链接到它它就没有被发现的入口。除非爬虫恰好知道“每个网站都可能有一个 llms.txt”并主动去探测否则它没有任何动机去请求这个路径。这就解释了为什么一个孤立文件的访问量常常是零互联网上的爬虫不是按“查看所有网站根目录是否存在某个约定文件”的方式运行的它们更关心已有链接和已有页面的更新频率。2.2 搜索引擎索引不等于 LLM 会读取还有一层常见的混淆我把页面提交给了搜索引擎为什么大模型还是不用搜索引擎收录网页和 LLM 使用你的内容是两条不同的流水线。搜索引擎收录是为了网页检索而大模型要么在训练阶段消化海量语料要么在推理阶段通过检索增强生成RAG去动态读取网页。这两者的调度机制、抓取规则、内容偏好可能完全不同。更重要的是即使一个 AI 爬虫访问了你的网站它也不一定读取llms.txt。很多模型公司并没有在爬虫里内置对该协议的支持它们仍以抓取 HTML 为主。你提供的llms.txt对它们来说可能只是另一个无关文本文件。这就形成了一种典型的生态困局一边是网站主希望用新协议降低模型理解成本另一边是模型方选择保守继续沿用老一套抓取方案。新旧标准交替期出现“没人抓”实在太正常了。2.3 “没人抓”的具体原因清单要把问题从“焦虑”变成“可排查清单”我建议你按下面这个顺序逐项检查检查维度具体问题可能结果文件可达性能否通过https://你的域名/llms.txt直接访问404、403、跳转异常文件格式是否纯 Markdown、UTF-8 编码、无 BOM 或乱码解析失败网络环境服务器在国内/国外、CDN 缓存策略是否拦截抓取超时或拿到旧内容入口引用首页、sitemap、robots.txt、页脚是否放了这个链接爬虫无从发现外部链接是否有其他网站、GitHub、社区页面链接到你的站点爬虫种子集合中缺少入口爬虫调度搜索引擎和 AI 爬虫更新周期通常较长哪怕文件上线抓取也要数周以上内容价值链接列表是否空泛、缺少说明或分类混乱即使抓到也可能判定为低质量内容实际排查时要遵循“先看现象、再看输入、再看环境、再看参数、最后看工具边界”的顺序。先确认curl -I https://example.com/llms.txt返回 200再确认文件内容没有语法问题然后才去讨论爬虫为什么不来。很多“没人抓”的案例实际上是文件路径写错了或者用了相对链接。3. 让 llms.txt 真正被用的六个关键动作如果说前两章解释的是“为什么”这一章要回答“怎么办”。我不建议你把所有时间花在反复修改文件内容上更有效的方式是围绕llms.txt建立一套完整的内容发布与验证体系。3.1 第一步先把文件内容做成“高密度目录”一个常见的误区是把llms.txt写得像网站所有文章的完整列表。这样做反而会让模型抓不住重点。更好的做法是把它做成“高密度目录”。一个比较稳妥的结构是# Example Blog A blog about DevOps, Kubernetes, and practical automation. ## Important Links - [Home](https://example.com/) - [About](https://example.com/about) - [All Articles](https://example.com/archive) ## DevOps - [How to Write a Kubernetes Operator](https://example.com/posts/kubernetes-operator) - [Zero-Downtime Deployments](https://example.com/posts/zero-downtime) ## Automation - [Ansible vs Terraform: A Pragmatic Comparison](https://example.com/posts/ansible-vs-terraform)在这里文件的标题、站点描述、重要链接、分类链接都很清晰。大模型拿到这份内容能快速建立“这是一个关注 DevOps 的博客核心文章有哪些”的心理模型。操作建议先列出网站最重要的 5 到 10 个入口再按分类补充 15 到 30 条高质量链接。不要为了填充数量把几十篇无关日志全部放进去。对 AI 来说信息密度和结构优先级比全量列表更重要。3.2 第二步让文件成为站点信息架构的一部分光有文件不够需要把它挂入站点的信息体系。常见做法有四个在 HTML 的head中添加link relllms.txt href/llms.txt告诉支持该协议的客户端这里有一份站点文本索引。在robots.txt中显式放行/llms.txt避免被某些保守爬虫误拦。在sitemap.xml中追加这个文件对应的 URL让搜索引擎和通用爬虫也能把llms.txt当作一个普通页面去抓取。在站点页脚或“关于页”里添加一行普通人类可读的链接写清楚“为 AI 提供本站内容索引”。这些动作听起来简单但它决定了爬虫是否有一个从已有页面出发、走到llms.txt的路径。孤立的根目录文件不会有这个路径除非你主动把它嵌入到现有导航结构中。3.3 第三步在内容页面里提供“人机都能读”的上下文llms.txt只是一个目录它会暴露你的内容入口但并不会替代每个页面的内容。为了让模型在进入具体链接后能顺利理解页面你还需要让页面本身具备良好的机器可读性。最基础的一组操作包括为每个页面设置唯一的title和meta description不要全站都用一句相同的模板保持正文中的标题层级清晰h1到h3的顺序合理在关键文档里写清楚“这个项目是做什么的”“适合谁使用”“维护者是谁”如果站点使用了 JavaScript 渲染至少保证核心内容可以通过静态 HTML 访问。这些不是llms.txt专属的要求但它们会直接影响模型在读取你的链接时是否认为内容值得被采纳。一个又乱又不能静态访问的站点即使llms.txt写得再标准后续内容读取质量也会很差。3.4 第四步主动曝光而不是等爬虫上门生态还不成熟的时候被动等待几乎没有效果。你要做的是把llms.txt的存在主动传播出去。比较自然的曝光路径包括如果网站有 GitHub 仓库在 README 里加一段说明提到“本站/本项目提供llms.txt可作为 AI 内容索引”在个人主页、社交媒体简介或技术社区签名里附上https://example.com/llms.txt的链接把项目或网站提交到相关技术目录、主题聚合站点吸引人类用户点击间接提高页面的爬虫优先级针对内容型站点可以在技术论坛或社区分享一篇“我是如何为网站添加 llms.txt”的实践贴让读者访问你的网站。这里要注意不要编造“官方提交入口”之类的说法。现在没有统一注册中心更多依赖的是普通链接和社区传播。你每增加一条站外链接都相当于在爬虫的种子集合里多留下一个入口。3.5 第五步用标准词、元信息和结构化数据做增强llms.txt文件本身是纯文本但你可以通过两个间接手段提升解读效果第一在文件链接文本中使用准确的描述词。比如不要只写“点击这里”而要写“开源的 Kubernetes 事件管理工具”。模型在读取链接时锚文本本身就是内容摘要的一部分含糊的锚文本会浪费这个机会。第二在全站页面中补充 JSON-LD 结构化数据尤其是Organization、WebSite、Article等类型。结构化数据和llms.txt虽然形式不同但目标一致降低机器理解成本。当 AI 爬虫访问你的页面时两者可以互相印证。不过要克制不要在llms.txt里堆砌 SEO 关键词。这个文件的读者是模型模型对重复、无意义的词同样会给出低权重。清晰、简洁、语义准确的文本永远比过度优化更有效。3.6 第六步建立一个可验证的抓取闭环最后一步也是很多人忽略的一步监控和验证。如果没有日志和访问记录你很难知道一个方案是不是真的被使用了。你至少可以做三件低成本的事# 检查文件是否可以正常访问 curl -sI https://example.com/llms.txt # 检查文件内容 curl -s https://example.com/llms.txt | head -50然后定期检查服务器访问日志看是否存在路径为/llms.txt的请求并关注 User-Agent 中是否出现常见的 AI 爬虫标识比如GPTBot、ClaudeBot、Google-Extended、Amazonbot等。不同模型的爬虫标识会变化具体要以官方文档为准但不是所有 AI 访客都会直接请求这个文件。最后用“结果”而不是“请求数”来验证。你可以在站点里放几篇值得被 AI 引用的原创内容然后在支持联网搜索的产品或 RAG 应用里做一次提问测试看它能不能找到你的页面。如果找不到再回溯文件路径、入口链接、内容质量这三个环节。注意只靠访问日志判断“没人抓”是不准确的。很多企业级模型会通过代理服务、第三方检索服务或离线语料读取内容不会直接发请求到你的服务器。所以日志没有记录不等于内容没有被使用但日志有记录至少说明已经有了真实的抓取行为。4. 从文件到体系边界、维护与长期价值现在你已经知道llms.txt不是写了一劳永逸的静态文件。它更像是一块“面向 AI 时代的内容基础设施”的切面。但要真正判断它适不适合你的项目还得把边界想清楚。4.1 llms.txt 的优势与真正适用场景从实际使用情况看它最适合以下几类网站个人技术博客或专栏内容以文章为主信息结构清晰开源项目的文档站有一批稳定、长期有效的文档入口产品官网希望向 AI 系统准确传递产品定位、功能和使用入口以知识整理为目标的站点例如工具导航、教程合集、资源索引。这些站点的共同特征是内容相对稳定URL 不会频繁变化信息架构本身有整理价值。对这类站点来说llms.txt是在人类导航之外额外提供一条机器可读的路径。4.2 如果暂时没人抓还值得维护吗这个问题取决于你对它的定位。如果把它定位成“SEO 加速器”希望下个月就能带来 AI 流量那大概率会失望。当前生态下模型是否采用这份文件取决于爬虫是否支持、语料是否访问、内容质量是否匹配变量很多。但如果把它定位成“未来 AI 访问内容的低成本入口”那维护它就是值得的。理由很简单这个文件最少一次花费十几分钟维护成本几乎为零它不依赖任何平台账号不需要担心平台政策变化它的存在相当于提前把站点内容的结构化版本准备好了当支持llms.txt的工具逐渐增加时你已经站在第一批站点之中。我更倾向把它看作“内容组织能力”的一种训练。你在写llms.txt的过程实际上是在逼迫自己梳理站点结构、提炼核心页面、为每篇文章写出清晰的摘要。即使llms.txt最终没有成为标准这个过程也不会浪费。4.3 长期视角llms.txt 与“为 AI 组织内容”的趋势把它放到更大的背景里看llms.txt只是“面向 AI 组织内容”这个大趋势中的一个具体方案。未来AI 代理会越来越多地代表用户浏览网页、查找信息、比较产品和执行任务。到那时机器可读的内容入口会变得和今天的移动端适配一样重要。如果每个网站都靠模型从复杂的 HTML 中猜结构成本太高也不可靠。替代方案一定是在标准页面之外提供更明确、更机器友好的信息层。llms.txt可能不会成为最终答案但它至少让人们意识到我们应该主动为 AI 读者准备一份清晰的内容目录而不是让模型在一个充满广告和脚本的页面上自己猜。所以回到最开始那个问题Nobody Fetched My Llms.txt真正的问题不是“没有 AI 来抓”而是“我是否已经把内容组织到 AI 可以轻松理解的状态”。文件里的每一条链接都是你向这个目标前进的一步。下次再检查日志的时候不要只数请求次数。先看看文件可不可达看看站外有哪些入口再想想如果明天有一个 AI 代理来访问我的站点它能在多少次点击之内准确理解“这个网站是什么、哪里最有价值”能做到这一点即使现在没有 fetch也已经把正确的事做好了。 llms.txt没人抓？从内容索引链路看AI爬虫为何不来及应对策略
如果你也曾在服务器上放了一个llms.txt文件然后打开访问日志等了一周发现连一个 AI 爬虫都没有来过——别急着怀疑自己。这个标题描述的状态其实是很多早期采用者的真实体验。llms.txt是 2024 年开始在技术社区里被反复讨论的一个倡议模仿robots.txt的命名方式在站点根目录放一个纯文本 Markdown 文件用统一格式告诉大语言模型“这个网站有哪些值得读的内容”。听起来很美好但现实是把一个文件放在根目录不等于它会被自动发现、自动读取、自动变成模型知识。掉进这个坑之后我有一个越来越明确的判断llms.txt的价值不在于“创建”而在于“内容索引链路”的完整程度。文件本身只是入口真正决定它能不能被用到取决于站点结构、内容组织、外部链接、监控验证这些环节有没有同时跟上。如果只有孤零零的一个文件没人抓是常态而不是意外。1. 先搞清楚llms.txt 到底想解决什么问题很多人第一次听说llms.txt会把它和robots.txt放在一起理解。这种直觉没错但很容易带来一个误解以为它是给爬虫指路的门牌。实际上它的目标并不是“让爬虫能爬到”而是“让大模型能更快理解一个网站的结构和重点”。1.1 从 robots.txt 到 llms.txt给爬虫的路标给模型的目录robots.txt解决的是“准许和禁止”的问题。它告诉搜索引擎爬虫哪些路径不能访问哪些目录不要索引sitemap 在哪里。它是一个控制访问边界的协议。llms.txt解决的是“理解成本”的问题。它不关心你能不能爬而是关心如果一个 AI 系统已经拿到了网站内容它如何用最小代价搞清楚这个网站是做什么的、哪些内容最重要、文档入口在哪里。为方便理解你可以把llms.txt想象成一本给 AI 看的“读者手册”封面是站点名称序言是站点摘要目录是分类过的核心链接。模型拿到以后不需要从一个完整的 HTML 页面里费劲剥离导航、广告和脚本直接按目录找它需要的章节就可以了。在设计思路上它更像“读书先看目录”的工作方式而不是“把所有文字都扔给模型”的粗暴做法。1.2 它解决的不是“抓取”而是“理解成本”网站内容的传统消费方式是浏览器获取 HTML然后交给人类渲染阅读。 HTML 里充满了标签、样式、脚本、导航栏、埋点代码模型工具去解析这些内容既耗时又容易产生噪声。llms.txt的做法很直接用一份标准化的 Markdown 文件把站点信息保留下来。它的结构大体上包含三个部分站点主要名称和描述一组“重要链接”通常是核心栏目、文档、最重要的内容入口可选的其他链接按主题或分类排列。这种格式的好处是让大模型不必做大量清洗直接拿到一个可读性很强的站点摘要。这实际上是把网站的“信息架构”单独提炼出来作为 AI 可以访问的公开元数据。所以它真正改善的不是“抓没抓到”而是“抓到了以后要用多少成本才能理解”。让 AI 系统更容易理解你的站点才是llms.txt的核心目标。1.3 你期望的“抓取”和协议真正能保证的“抓取”问题是很多人在部署这个文件时期望的是“立刻被 GPT 的爬虫收录以后模型回答里会出现我的网站”。这种期望把llms.txt当成了 SEO 外挂但协议本身没有这个能力。llms.txt目前只是一个社区倡议不是 W3C 等标准组织发布的正式标准也没有统一的注册中心。这意味着不是所有 AI 爬虫都会主动访问llms.txt即使访问了也不代表模型会在训练或检索时引用你的内容即使引用了距离“回答中生成你的网站”还有语义匹配、内容质量、可信度等多层门槛。从实际效果看在 2024 年和 2025 年的生态里你能验证到的“被读取”信号通常来自少数支持该协议的工具和爬虫。大多数大模型厂商仍然按照自己的抓取策略工作不会为了一个新文件改变整个管线。因此一个更理性的目标是把llms.txt当作所有 AI 可读内容里成本最低、结构最清晰的那一块基础设施而不是保证流量的魔法文件。2. 为什么“没人抓”是常态现实中的发现机制如果你用了个人的 VPS、博客或文档站部署llms.txt后没人请求这不一定是你做错了什么。真实世界里AI 系统发现一个新页面远比“把文件放到根目录”复杂得多。2.1 大模型是怎么发现网站内容的大语言模型的训练语料大多来自大规模的网络公开数据常见来源包括 Common Crawl、搜索引擎索引、特定领域数据集和学术语料。这些数据的采集通常是一个成熟的爬虫体系它们从一个已有的 URL 种子集合开始沿着页面里的链接不断扩展。这个流程有一个关键特点爬虫需要先知道一个 URL 存在然后才可能去请求它。如果你只是在网站根目录添加了一个新文件但没有任何已有页面链接到它它就没有被发现的入口。除非爬虫恰好知道“每个网站都可能有一个 llms.txt”并主动去探测否则它没有任何动机去请求这个路径。这就解释了为什么一个孤立文件的访问量常常是零互联网上的爬虫不是按“查看所有网站根目录是否存在某个约定文件”的方式运行的它们更关心已有链接和已有页面的更新频率。2.2 搜索引擎索引不等于 LLM 会读取还有一层常见的混淆我把页面提交给了搜索引擎为什么大模型还是不用搜索引擎收录网页和 LLM 使用你的内容是两条不同的流水线。搜索引擎收录是为了网页检索而大模型要么在训练阶段消化海量语料要么在推理阶段通过检索增强生成RAG去动态读取网页。这两者的调度机制、抓取规则、内容偏好可能完全不同。更重要的是即使一个 AI 爬虫访问了你的网站它也不一定读取llms.txt。很多模型公司并没有在爬虫里内置对该协议的支持它们仍以抓取 HTML 为主。你提供的llms.txt对它们来说可能只是另一个无关文本文件。这就形成了一种典型的生态困局一边是网站主希望用新协议降低模型理解成本另一边是模型方选择保守继续沿用老一套抓取方案。新旧标准交替期出现“没人抓”实在太正常了。2.3 “没人抓”的具体原因清单要把问题从“焦虑”变成“可排查清单”我建议你按下面这个顺序逐项检查检查维度具体问题可能结果文件可达性能否通过https://你的域名/llms.txt直接访问404、403、跳转异常文件格式是否纯 Markdown、UTF-8 编码、无 BOM 或乱码解析失败网络环境服务器在国内/国外、CDN 缓存策略是否拦截抓取超时或拿到旧内容入口引用首页、sitemap、robots.txt、页脚是否放了这个链接爬虫无从发现外部链接是否有其他网站、GitHub、社区页面链接到你的站点爬虫种子集合中缺少入口爬虫调度搜索引擎和 AI 爬虫更新周期通常较长哪怕文件上线抓取也要数周以上内容价值链接列表是否空泛、缺少说明或分类混乱即使抓到也可能判定为低质量内容实际排查时要遵循“先看现象、再看输入、再看环境、再看参数、最后看工具边界”的顺序。先确认curl -I https://example.com/llms.txt返回 200再确认文件内容没有语法问题然后才去讨论爬虫为什么不来。很多“没人抓”的案例实际上是文件路径写错了或者用了相对链接。3. 让 llms.txt 真正被用的六个关键动作如果说前两章解释的是“为什么”这一章要回答“怎么办”。我不建议你把所有时间花在反复修改文件内容上更有效的方式是围绕llms.txt建立一套完整的内容发布与验证体系。3.1 第一步先把文件内容做成“高密度目录”一个常见的误区是把llms.txt写得像网站所有文章的完整列表。这样做反而会让模型抓不住重点。更好的做法是把它做成“高密度目录”。一个比较稳妥的结构是# Example Blog A blog about DevOps, Kubernetes, and practical automation. ## Important Links - [Home](https://example.com/) - [About](https://example.com/about) - [All Articles](https://example.com/archive) ## DevOps - [How to Write a Kubernetes Operator](https://example.com/posts/kubernetes-operator) - [Zero-Downtime Deployments](https://example.com/posts/zero-downtime) ## Automation - [Ansible vs Terraform: A Pragmatic Comparison](https://example.com/posts/ansible-vs-terraform)在这里文件的标题、站点描述、重要链接、分类链接都很清晰。大模型拿到这份内容能快速建立“这是一个关注 DevOps 的博客核心文章有哪些”的心理模型。操作建议先列出网站最重要的 5 到 10 个入口再按分类补充 15 到 30 条高质量链接。不要为了填充数量把几十篇无关日志全部放进去。对 AI 来说信息密度和结构优先级比全量列表更重要。3.2 第二步让文件成为站点信息架构的一部分光有文件不够需要把它挂入站点的信息体系。常见做法有四个在 HTML 的head中添加link relllms.txt href/llms.txt告诉支持该协议的客户端这里有一份站点文本索引。在robots.txt中显式放行/llms.txt避免被某些保守爬虫误拦。在sitemap.xml中追加这个文件对应的 URL让搜索引擎和通用爬虫也能把llms.txt当作一个普通页面去抓取。在站点页脚或“关于页”里添加一行普通人类可读的链接写清楚“为 AI 提供本站内容索引”。这些动作听起来简单但它决定了爬虫是否有一个从已有页面出发、走到llms.txt的路径。孤立的根目录文件不会有这个路径除非你主动把它嵌入到现有导航结构中。3.3 第三步在内容页面里提供“人机都能读”的上下文llms.txt只是一个目录它会暴露你的内容入口但并不会替代每个页面的内容。为了让模型在进入具体链接后能顺利理解页面你还需要让页面本身具备良好的机器可读性。最基础的一组操作包括为每个页面设置唯一的title和meta description不要全站都用一句相同的模板保持正文中的标题层级清晰h1到h3的顺序合理在关键文档里写清楚“这个项目是做什么的”“适合谁使用”“维护者是谁”如果站点使用了 JavaScript 渲染至少保证核心内容可以通过静态 HTML 访问。这些不是llms.txt专属的要求但它们会直接影响模型在读取你的链接时是否认为内容值得被采纳。一个又乱又不能静态访问的站点即使llms.txt写得再标准后续内容读取质量也会很差。3.4 第四步主动曝光而不是等爬虫上门生态还不成熟的时候被动等待几乎没有效果。你要做的是把llms.txt的存在主动传播出去。比较自然的曝光路径包括如果网站有 GitHub 仓库在 README 里加一段说明提到“本站/本项目提供llms.txt可作为 AI 内容索引”在个人主页、社交媒体简介或技术社区签名里附上https://example.com/llms.txt的链接把项目或网站提交到相关技术目录、主题聚合站点吸引人类用户点击间接提高页面的爬虫优先级针对内容型站点可以在技术论坛或社区分享一篇“我是如何为网站添加 llms.txt”的实践贴让读者访问你的网站。这里要注意不要编造“官方提交入口”之类的说法。现在没有统一注册中心更多依赖的是普通链接和社区传播。你每增加一条站外链接都相当于在爬虫的种子集合里多留下一个入口。3.5 第五步用标准词、元信息和结构化数据做增强llms.txt文件本身是纯文本但你可以通过两个间接手段提升解读效果第一在文件链接文本中使用准确的描述词。比如不要只写“点击这里”而要写“开源的 Kubernetes 事件管理工具”。模型在读取链接时锚文本本身就是内容摘要的一部分含糊的锚文本会浪费这个机会。第二在全站页面中补充 JSON-LD 结构化数据尤其是Organization、WebSite、Article等类型。结构化数据和llms.txt虽然形式不同但目标一致降低机器理解成本。当 AI 爬虫访问你的页面时两者可以互相印证。不过要克制不要在llms.txt里堆砌 SEO 关键词。这个文件的读者是模型模型对重复、无意义的词同样会给出低权重。清晰、简洁、语义准确的文本永远比过度优化更有效。3.6 第六步建立一个可验证的抓取闭环最后一步也是很多人忽略的一步监控和验证。如果没有日志和访问记录你很难知道一个方案是不是真的被使用了。你至少可以做三件低成本的事# 检查文件是否可以正常访问 curl -sI https://example.com/llms.txt # 检查文件内容 curl -s https://example.com/llms.txt | head -50然后定期检查服务器访问日志看是否存在路径为/llms.txt的请求并关注 User-Agent 中是否出现常见的 AI 爬虫标识比如GPTBot、ClaudeBot、Google-Extended、Amazonbot等。不同模型的爬虫标识会变化具体要以官方文档为准但不是所有 AI 访客都会直接请求这个文件。最后用“结果”而不是“请求数”来验证。你可以在站点里放几篇值得被 AI 引用的原创内容然后在支持联网搜索的产品或 RAG 应用里做一次提问测试看它能不能找到你的页面。如果找不到再回溯文件路径、入口链接、内容质量这三个环节。注意只靠访问日志判断“没人抓”是不准确的。很多企业级模型会通过代理服务、第三方检索服务或离线语料读取内容不会直接发请求到你的服务器。所以日志没有记录不等于内容没有被使用但日志有记录至少说明已经有了真实的抓取行为。4. 从文件到体系边界、维护与长期价值现在你已经知道llms.txt不是写了一劳永逸的静态文件。它更像是一块“面向 AI 时代的内容基础设施”的切面。但要真正判断它适不适合你的项目还得把边界想清楚。4.1 llms.txt 的优势与真正适用场景从实际使用情况看它最适合以下几类网站个人技术博客或专栏内容以文章为主信息结构清晰开源项目的文档站有一批稳定、长期有效的文档入口产品官网希望向 AI 系统准确传递产品定位、功能和使用入口以知识整理为目标的站点例如工具导航、教程合集、资源索引。这些站点的共同特征是内容相对稳定URL 不会频繁变化信息架构本身有整理价值。对这类站点来说llms.txt是在人类导航之外额外提供一条机器可读的路径。4.2 如果暂时没人抓还值得维护吗这个问题取决于你对它的定位。如果把它定位成“SEO 加速器”希望下个月就能带来 AI 流量那大概率会失望。当前生态下模型是否采用这份文件取决于爬虫是否支持、语料是否访问、内容质量是否匹配变量很多。但如果把它定位成“未来 AI 访问内容的低成本入口”那维护它就是值得的。理由很简单这个文件最少一次花费十几分钟维护成本几乎为零它不依赖任何平台账号不需要担心平台政策变化它的存在相当于提前把站点内容的结构化版本准备好了当支持llms.txt的工具逐渐增加时你已经站在第一批站点之中。我更倾向把它看作“内容组织能力”的一种训练。你在写llms.txt的过程实际上是在逼迫自己梳理站点结构、提炼核心页面、为每篇文章写出清晰的摘要。即使llms.txt最终没有成为标准这个过程也不会浪费。4.3 长期视角llms.txt 与“为 AI 组织内容”的趋势把它放到更大的背景里看llms.txt只是“面向 AI 组织内容”这个大趋势中的一个具体方案。未来AI 代理会越来越多地代表用户浏览网页、查找信息、比较产品和执行任务。到那时机器可读的内容入口会变得和今天的移动端适配一样重要。如果每个网站都靠模型从复杂的 HTML 中猜结构成本太高也不可靠。替代方案一定是在标准页面之外提供更明确、更机器友好的信息层。llms.txt可能不会成为最终答案但它至少让人们意识到我们应该主动为 AI 读者准备一份清晰的内容目录而不是让模型在一个充满广告和脚本的页面上自己猜。所以回到最开始那个问题Nobody Fetched My Llms.txt真正的问题不是“没有 AI 来抓”而是“我是否已经把内容组织到 AI 可以轻松理解的状态”。文件里的每一条链接都是你向这个目标前进的一步。下次再检查日志的时候不要只数请求次数。先看看文件可不可达看看站外有哪些入口再想想如果明天有一个 AI 代理来访问我的站点它能在多少次点击之内准确理解“这个网站是什么、哪里最有价值”能做到这一点即使现在没有 fetch也已经把正确的事做好了。