llms.txt 实战：一份能让 ChatGPT 准确引用你网站的索引文件长什么样
你的网站在 ChatGPT 里总被错误摘要？别查 Schema 了，根目录大概率缺个 llms.txt。它不是给爬虫看的 sitemap，而是给 AI 模型推理时看的“精选导读”，没它兜底，模型只能从 HTML 碎片里瞎猜你是干嘛的。官方对格式规定极严，H1、blockquote 摘要、## Optional 保留段缺一不可，而八成的人会踩放错路径、写成 robots 语法、塞满营销页等五个致命坑导致文件白写。本文拆解了协议规范并附了一份企业站即用模板，写完用 GEO ICU 跑个检测验证，半小时搞定这个零成本文件，就是拿稳了 2026 年 AI 搜索流量的入场券。
上周有位做企业服务 SaaS 的朋友来找我，说他家的产品页接进 ChatGPT 之后被摘录得面目全非——明明是一家做合同生命周期管理的工具，AI 给用户的回答里却把他们描述成"在线合同模板下载站"，连定价区间都对不上。团队先是怀疑 Schema 没写对，又怀疑是被竞品的页面"污染"了语义，折腾了一周去查 robots.txt 和 sitemap.xml，都没找到根因。
我让他把域名丢进 GEO ICU 跑了一遍 16 维审计。报告甩出来，llms.txt 那一项赫然是个刺眼的红叉：文件不存在。问题一下就清楚了——ChatGPT 在没有 llms.txt 兜底的情况下，只能靠爬到的 HTML 片段去猜这家公司到底是干嘛的，猜偏了也就不奇怪。这件事让我意识到一个被严重低估的事实：很多人把 llms.txt 当成"给 AI 看的 sitemap"，写个空文件丢在根目录就交差，但它真正的价值是在你被 AI 错误摘要之前，先把"我是谁、我有什么、去哪查"这件事讲清楚。
一、llms.txt 到底在解决什么问题
要写好这个文件，得先理解它和 robots.txt、sitemap.xml 的分工。robots.txt 管的是"允不允许爬"，sitemap.xml 管的是"我有哪些页面"，而 llms.txt 管的是"这个网站的核心信息是什么、关键文档在哪、按什么顺序读"。
这个区分不是凭空造出来的。Jeremy Howard 在 2024 年 9 月的提案里写得很直白：大模型的上下文窗口塞不下整个网站，把布满导航栏、广告和 JS 渲染逻辑的 HTML 转成 LLM 友好的纯文本既困难又不精确，所以需要一个专门为推理时（inference time）准备的、精炼的 Markdown 入口。换句话说，sitemap.xml 是给爬虫看的全量清单，llms.txt 是给"正在回答用户问题的模型"看的精选导读。
Princeton 和 IIT Delhi 团队在 KDD 2024 上发表的 GEO 论文也印证了这件事的方向：他们对 10,000 条查询做了实验，发现引用来源、补充结构化信息、提升内容可读性这类"降低 AI 理解成本"的策略，能把内容在生成式回答中的可见度最高提升 40%。llms.txt 本质上就是把"降低 AI 理解成本"这件事标准化了。
二、协议规范拆解：六个不能搞错的格式细节
llms.txt 的妙处在于它用 Markdown 结构信息，而不是 XML 或 YAML——这样人和模型都能读，但又能用 parser 和 regex 做精确解析。官方提案对格式的规定比想象中严格，顺序也不能乱：
1. H1 是唯一必填项。 整个文件必须以一个 H1 开头，写项目或站点名称。这是唯一不能省的部分，没有它整个文件就不算合规。
2. blockquote 摘要用 > 引出。 紧跟 H1 的是一个用 > 开头的引用块，写一段简短摘要，要包含理解后续内容所必需的关键信息。模型在上下文紧张时会优先吃这段，所以它不是装饰，是"电梯演讲"。
3. 中间允许放非标题的说明段落。 在摘要和后面的 H2 段之间，可以放任意数量的普通 Markdown 段落、列表，但不能出现 heading。这里通常用来写"重要提示"“术语约定”“版本说明”。
4. H2 划分"文件列表"段。 后续每个 ## 段名 下面跟一个 Markdown 列表，每项是一个必填的 名称 超链接，后面可选地跟一个冒号和该文件的说明。
5. ## Optional 是有特殊语义的保留段。 这一点最容易被忽略。如果你把一段命名为 Optional，意味着模型在上下文不够时可以跳过这些 URL。所以次要信息、外部参考、长篇附录都应该放这里，而不是和核心文档混在一起。
6. 可选的 BOM。 文件开头可以放一个字节顺序标记，多数情况不用管。
官方给的骨架是这样的：
Title
Optional description goes here
Optional details go here
Section name
- Link title: Optional link details
Optional
三、一份可直接套用的企业站模板
下面这版是我给前面那位朋友改的，跑通之后 llms.txt 检测从红叉变成了满分。四个标准段——Overview、Docs、API、Pricing——基本覆盖了大多数企业站的核心信息结构，你可以照着改：
# ContractFlow
> ContractFlow 是一家面向中型企业的合同生命周期管理（CLM）SaaS，
> 核心能力包括合同起草、电子签章、履约提醒、风险条款识别。
> 定价按席位计费，起步 5 席，提供 14 天免费试用。
重要约定：
- 本文件中的所有 .md 链接均为 LLM 友好的纯文本版本，可直接抓取
- 定价信息以 USD 计，最后更新于 2026-06
- API 版本当前为 v2，v1 已弃用
## Overview
- [公司简介](/about.md): 成立于 2021 年，总部在新加坡，服务客户超 800 家
- [产品总览](/product.md): 六大模块的简要说明与适用场景
- [安全与合规](/security.md): SOC 2 Type II、ISO 27001、GDPR 数据处理说明
## Docs
- [快速上手](/docs/quickstart.md): 15 分钟跑通第一份合同
- [合同模板语法](/docs/template-syntax.md): 变量、条件块、循环块的完整语法
- [风险条款库](/docs/risk-library.md): 120+ 条预置风险规则及自定义方法
## API
- [API 概览](/api/overview.md): 认证方式、速率限制、错误码
- [合同接口](/api/contracts.md): 创建、查询、状态变更
- [Webhook 事件](/api/webhooks.md): 签约、到期、风险命中的事件订阅
## Pricing
- [套餐对比](/pricing/plans.md): Starter / Growth / Enterprise 三档的功能与价格
- [计费规则](/pricing/billing.md): 席位、用量、超额计费的具体算法
## Optional
- [客户案例合集](/cases/index.md): 30+ 行业案例，篇幅较长，按需取用
- [迁移指南](/docs/migration.md): 从 DocuSign / PandaDoc 迁移的字段映射表
这份模板有几个点值得说一下：摘要里直接写了计费单位和试用天数，是因为这两条是用户最常问、也最容易被 AI 猜错的；Overview 段放了安全合规，是因为企业服务客户在 AI 回答里查不到合规信息会直接流失；Optional 段刻意把案例合集和迁移指南放进去，是因为它们篇幅大、信息密度低，模型在回答具体问题时应该优先看前面四段。
四、五个高频错误，踩中任何一个都白写
GEOICU 的检测报告里，llms.txt 维度的低分几乎都集中在这五种情况上：
错误一：放错路径。 提案明确规定文件必须放在根路径 /llms.txt，跟 robots.txt 同级。很多人放在 /assets/llms.txt 或者 /docs/llms.txt，模型按惯例去根路径抓，抓不到就当作没有。另外 MIME 类型要设成 text/plain 或 text/markdown，别让服务器默认返回 application/octet-stream，否则部分 AI 爬虫会直接跳过。
错误二：写成 robots.txt 语法。 这是入门者最常见的坑。有人把 llms.txt 写成 User-agent: * Allow: /docs 这种格式，完全是两套东西。robots.txt 是声明式访问控制，llms.txt 是 Markdown 内容索引，语法、用途、读取时机都不一样。混着写既通不过解析器，也会让模型拿到一堆无意义符号。
错误三：链接全是营销页。 有些团队把首页、活动页、注册页全塞进 llms.txt，看起来"内容很丰富"，实际上这些页面 HTML 化之后都是营销话术，对模型回答用户的具体问题毫无帮助。llms.txt 的链接应该指向信息密度高、事实性强的文档——API 说明、定价表、语法手册、合规白皮书。Jeremy Howard 在提案里专门强调过：链接要带简短、有信息量的描述，避免模糊术语和没解释过的行话。
错误四：忽略 Markdown 可读性。 既然格式是 Markdown，就该按 Markdown 的规矩写。常见问题包括：H1 写了多个、blockquote 摘要写成了一整段没有标点的关键词堆砌、列表项的链接描述写成"点击这里"。这种文件人读着费劲，模型解析也容易出错。一个简单的自检方法：把你的 llms.txt 原文直接粘进任意一个 Markdown 预览器，如果它渲染出来乱七八糟，模型读出来也好不到哪去。
错误五：未与 sitemap.xml 对齐。 sitemap.xml 列全量页面，llms.txt 列精选文档，两者不是替代关系而是互补关系。但有一个底线：llms.txt 里链接的每一个 .md 文件，对应的原始 HTML 页面最好在 sitemap.xml 里有声明，否则会出现"llms.txt 说有这篇文档，但搜索引擎不知道这页存在"的割裂状态，影响信源权重的累积。另外提案里特意提到，llms.txt 可以引用站外 URL（比如 GitHub 上的 markdown 文档），这是 sitemap.xml 做不到的，合理利用能补充外部权威信源。
五、用 GEOICU 的检测报告收尾验证
文件写完传上去，别急着宣布胜利。把域名丢回 GEO ICU 再跑一次，重点看 llms.txt 维度的几项子检查：
- 可访问性——文件是否在 /llms.txt 路径返回 200，MIME 类型是否正确
- 格式合规性——H1 是否存在、blockquote 摘要是否存在、H2 段的链接列表是否符合 name: notes 结构
- Optional 段识别——是否正确使用了 ## Optional 语义，把次要信息隔离出去
- 链接有效性——列表里的 .md 链接是否都能正常返回，有没有 404
- 与 sitemap.xml 的对齐度——核心文档是否在两份文件中保持一致
报告会附带原始 HTML 片段，方便你对照定位是哪一行写错了。那位朋友第一版模板跑出来，Optional 段识别失败，原因是他把段名写成了 ## 可选——提案里 Optional 是保留关键字，必须用英文原词，模型和解析器都是按字符串匹配的。改成 ## Optional 之后，分数才真正拉满。
回到开头那个故事。那位朋友补上 llms.txt 之后，大概两周时间，ChatGPT 里搜他们公司名，摘要从"合同模板下载站"纠正成了"合同生命周期管理 SaaS，提供起草、签章、履约提醒"，定价区间也对上了。当然，单靠一个文件不可能解决所有 AI 可见性问题，但它解决的是最底层那层——让模型在第一次接触你的网站时，拿到的是一份你亲手写的、结构清晰的自我介绍，而不是它从 HTML 碎片里拼凑出来的猜测。
llms.txt 不是万能药，但它是 GEO 优化里投入产出比最高的一个动作：一个文件、半小时工时、零运维成本，却能直接改善所有依赖推理时上下文的 AI 引擎对你网站的理解。把它写对，是 2026 年每一个还在乎 AI 搜索流量的站点都该做完的功课。