TL;DR / 核心要点总结
- Google 搜索已明确：llms.txt 不是必需项，也不影响排名与可见性。 2026 年 6 月 15 日的官方变更日志写得很直白：不需要，但为其他服务保留也可以。
- “Google 内部打架”是误读。 Search 管搜索结果，Chrome Lighthouse 管浏览器 agent 的可用性；后者检查 llms.txt，不等于搜索会读它。
- 可验证收益非常窄。 Ahrefs 对 13.7 万个域名的日志分析显示，百分之九十七的有效 llms.txt 在 2026 年 5 月零请求；AI 检索爬虫只占请求的百分之一左右。
- 受益者是文档型站点与编码 agent，不是营销站。 如果目标是 AI Overviews 或 ChatGPT 引用，优先修 robots、sitemap、正文与实体，收益更确定。
- 决策可以很具体： 有公开开发者文档就做一个合规版本；没有就最后做，甚至不做；任何情况下都别把它当收录开关或 KPI。
一、先把争论拆开：三个问题被混成了一个
关于 llms.txt 的争论，常见说法互相矛盾：一边说“官方已辟谣”，一边说“Lighthouse 都在检查了”。拆开句子会发现，大家回答的不是同一个问题。
| 问题 | 正确问法 | 答案取决于 |
|---|---|---|
| 它是不是官方标准 | 谁提出的、有没有被搜索引擎采纳 | 提案状态与各产品文档 |
| 它有没有用 | 对谁有用、收益能否被测量 | 站点类型与日志数据 |
| 我要不要做 | 我的站点属于哪种场景、成本多少 | 你的内容形态与目标 |
三个问题可以同时成立：它不是搜索标准，对多数站点没有可测收益，但你的开发者文档仍可能值得放一个。混在一起争论，就会把“Google 搜索不用”听成“完全没用”，或者把“Lighthouse 检查”听成“搜索会读”。
二、官方口径：Search 说不用，Lighthouse 说可选
先看最硬的两条官方口径，它们针对的不是同一个产品。
2026 年 6 月 15 日，Google Search Central 在变更日志里新增了一条说明：llms.txt 这类文件“对 Google 搜索不是必需的，不会负面影响也不会正面影响你的可见性或排名”；如果你要为其他使用它的服务保留，也没问题。
那份 AI 功能文档还写着：要让内容出现在 AI Overviews 与 AI Mode，不需要创建新的机器可读文件、AI 文本文件或额外标记，也没有额外的技术要求——被索引、有资格显示摘要即可。
另一边，Chrome Lighthouse 13.3 在 2026 年 5 月加入 Agentic Browsing 分类，其中一项会取 /llms.txt：取不到且返回 404 时判为“不适用”，只有服务器错误才报错。它衡量的是浏览器 agent 读取站点结构的便利性，不是搜索排名。
两条口径并不冲突，因为它们服务的产品不同。把 Lighthouse 的检查当成 Google 搜索的背书，是这类讨论里最常见的偷换。
还有一个常被当作“官方也在用”的证据：2025 年 12 月，Google Search Central 文档站出现过一份 llms.txt，疑似由 CMS 自动生成，几小时内被移除。文件存在不等于官方支持。
截至本文写作，没有任何主流 AI 平台公开承诺读取第三方站点的 llms.txt。OpenAI、Anthropic、Google（Gemini）给自家文档放 llms.txt，只说明它们认可这种写法，不代表其搜索产品会读你的文件。
三、可验证的收益：日志与相关性研究说了什么
只看能被复现的数据，结论比争论清楚：对多数站点，llms.txt 没有可验证的 AI 引用收益。
Ahrefs 在 2026 年 6 月发布了一项研究，分析了 137,210 个域名的服务器日志，数据窗口为 2026 年 5 月。约 3.8 万个域名发布了有效的 llms.txt；其中百分之九十七在整月没有收到任何请求。
收到请求的那百分之三里，来源也很集中：编码 agent 约占十分之一，Claude-Code 与 GPTBot 居前；SEO 审计与探测工具占两成上下；AI 检索爬虫只有百分之一左右。
OAI-SearchBot、PerplexityBot 与 Claude 的搜索爬虫合计只有几百次请求。Googlebot 的约九百次属于发现 URL 后的常规抓取，不表示它对 llms.txt 有特殊兴趣。
研究者强调，“被取”不等于“被读”，更不等于“被采用”；这些数字是收益的上限。
SE Ranking 另有一项覆盖约 30 万个域名的相关性研究：约一成域名有 llms.txt，但控制其他变量后，它与 AI 引用频率没有可检出的关系；把该变量从预测模型里去掉，模型表现反而略好。
这是相关性设计、没有爬虫日志，因此只能说明“没看到效果”，不能证明“永远不会有”。
两条证据合起来，支持同一结论：它可能有别的用途，但不是“提升 AI 可见度”。
四、它到底对谁有用：文档型站点，而不是营销站
llms.txt 的提案由 Jeremy Howard 在 2024 年 9 月提出，2026 年 8 月更新到 v2。出发点不是搜索排名，而是让 agent 用更少的 token 找到关键内容。
v2 写明主要场景是软件文档：编码 agent 按它找到 API 参考与教程。提案还建议为页面提供 Markdown 版本，并用 rel 关联 HTML 页、Markdown 页与 llms.txt。
这解释了 Ahrefs 的日志结构：Claude-Code 这类编码 agent 是主要读者，AI 搜索的检索爬虫几乎不出现。
反过来，营销站、企业官网、博客不在这个场景里。页面本来就是 HTML，AI 搜索通过既有索引取内容；再写一份导读，不会多一条收录通道。
| 站点类型 | 是否值得做 | 原因 |
|---|---|---|
| 公开 API / 开发者文档 | 值得 | 编码 agent 会按图索骥，Markdown 版本还能减少解析成本 |
| 产品帮助中心 | 可做 | 结构稳定、页面多，导读能降低 agent 的探索成本 |
| 企业官网 / 营销站 | 最后做或不单独做 | 目标是搜索引用，收益路径不成立 |
| 内容站 / 博客 | 不做 | sitemap 与内链已覆盖发现需求，维护成本不划算 |
| 把 llms.txt 当收录开关 | 不要做 | 它不是 robots.txt，不控制抓取，也不屏蔽训练 |
判断标准不是“别人都在做”，而是“有没有一类读者会主动找这份文件”。没有这类读者，做了也只是多一个要维护的 URL。
五、决策树：什么条件下做，什么条件下不做
把上面的证据压成一张判断表，决策就不需要站队。
- 有公开开发者文档，且客户会用编码 agent 读文档 → 做。 放在
/llms.txt或/docs/llms.txt，按规范写，链接指向 Markdown 版本。 - 只有企业官网，目标是 AI 搜索引用 → 不做，或排到最后。 先把 robots、sitemap、正文直出、实体与可摘段落做完。
- 被 Lighthouse 的 Agentic Browsing 报告困扰 → 做一个最小合规文件即可。 404 本来判不适用，不必为分数造文件。
- 想用它阻止训练或控制收录 → 不要做。 训练与检索的开关在 robots.txt 与 noindex，llms.txt 没有这个能力。
- 没有维护人手 → 不做。 一个过期、链接失效的导读，比没有更差。
如果只能留一条：先问“谁会在什么任务里主动来取它”。答不出来，就不做。
六、如果要做：最小合规写法与验收
决定要做，就按提案的格式做。格式不对，agent 解析不了，等于没做。
- 位置：
/llms.txt，或/docs/llms.txt（只覆盖该路径下的页面）。 - 结构：必须有 H1；建议一段 blockquote 摘要；用 H2 分组。
- 条目：用
[名称](URL)；不要只写裸 URL。 - 指向：LLM 友好页面或 Markdown 版本；可访问、非重定向、非 noindex。
- 响应：
text/plain或text/markdown，返回 200。 - 体积：短小，是导读不是镜像。
# 示例站点
> 一句话说明站点是什么、主要服务谁。
## 文档
- [快速开始](https://example.com/docs/start.md): 安装与第一个请求
- [API 参考](https://example.com/docs/api.md): 全部端点与参数验收只有三条：返回 200；H1、摘要与至少一个 Markdown 链接能被解析；链接在无 JS 时可达。
Lighthouse 的审计很宽：404 判不适用，只有服务器错误才报错；别把“通过”当成做对了。
更新频率提前定：文档结构大改时更新一次，不为每篇文章加条目。导读一旦变成第二套目录，就会和 sitemap 打架。
七、比 llms.txt 更值得先做的四件事
如果目标是 AI 搜索可见度，下面四件事的收益路径更清楚。
第一，放行对的爬虫。 OAI-SearchBot、Claude-SearchBot、PerplexityBot 与 Googlebot 各管一段；训练与检索分开管理。见 AI 爬虫排查。
第二，让页面可发现。 sitemap、内链与自指 canonical 是索引入口；内链如何影响实体理解，见内链与实体。
第三，让内容可摘。 正文直出、结论前置、H2 问句化、表格与清单。方法见如何让 AI 引用你的网站。
第四，让实体可信。 名称、定位、头衔一致，About 与 Organization 标记对得上，第三方档案可交叉验证。见品牌实体归属治理。
这四件事的官方机制依据，站内已在六大模型官方规则里汇总；实体与结构化标记的写法见结构化数据指南。
文档站的第五件事才是 Markdown 版本与 rel 关联——它比单独一个 llms.txt 更接近提案的完整用法。整体顺序见GEO 优化怎么做与GEO 框架。
八、我们自己的用法：保留，但不指望它
geova.cn 的 /llms.txt 是 2026 年 9 月加的，现在返回 200、text/plain，列了首页、服务页、工具页和一批文章。
保留的理由只有两个：成本几乎为零；对少数主动找导读文件的 agent，它比从首页猜结构省事。
我们不指望它做三件事：不当排名或引用因素；不当收录开关；不当全站镜像。完整索引以 sitemap 与 /blog 为准，新增文章不逐一同步；它的角色是入口，不是目录。
也没把它接入 KPI。没有可归因的数据表明它带来引用；如果明天删掉，按现有证据，很难预期会有可测量的变化。
保留它，只是成本低到不值得为“删不删”开会。
行动清单
今天做
- 打开
/llms.txt，确认返回 200、Content-Type是text/plain或text/markdown - 确认文件有 H1、摘要与至少一个 Markdown 链接
- 在服务器日志里确认关键检索爬虫的请求与状态码
本周做
- 按站点类型做一次决策：文档站做、营销站延后、内容站不做
- 如果做，把链接改成 Markdown 格式，去掉裸 URL 与死链
- 把 llms.txt 从“AI 可见度 KPI”里移除，改记 GSC 与固定提问集
本月做
- 文档站补 Markdown 版本与
rel关联 - 复查 robots.txt 与 sitemap，确保它们仍是主通道
- 每季度只做一次结构更新，不为单篇文章维护
结语
llms.txt 的问题，不是“有用还是没用”，而是“对谁、在什么条件下、用什么指标衡量”。
对 Google 搜索，它已被明确排除在必需项之外；对 AI 检索爬虫，日志显示它们几乎不读；对编码 agent，它是少量但真实的便利。把这三件事分开，决策就不难：文档站做一个合规版本，营销站把资源放回更靠前的通道。
如果只能记一句：它不是 AI 搜索的入场券，最多是给 agent 的一张便签。
📩 需要帮助？GEO 咨询团队可以为你做什么
如果你已经排除了 llms.txt，想知道下一步该把资源放在哪里：
- 免费工具：先跑一轮 AI 爬虫访问与正文可读性检查，确认通道没有断
- GEO 优化服务：按技术通道、实体、内容可摘性的顺序推进，不靠单点技巧
- GEO 人工诊断：需要对照竞品与引用结果时，做一次基线审计
本文依据 Google Search Central 2026 年 6 月 15 日变更日志与《AI features and your website》文档、Chrome Lighthouse 13.3 的 llms.txt 审计说明、llms.txt 提案 v2（2026 年 8 月更新）、Ahrefs 2026 年 6 月发布的 137,210 个域名日志研究、SE Ranking 约 30 万域名的相关性研究整理。第三方数据均标明来源类型；本文不含自有实验数据、搜索量或见效周期。AI 平台的产品与爬虫策略变化较快，结论截至 2026 年 11 月。