Stripe 7 万字节 llms.txt，输给了 Vercel 的 5.4K

一句话结论：两个大站都在根目录挂了 llms.txt，但一个 92% 的链接指回 50 万～97 万字节的 HTML 渲染页，另一个用 5.4K 清单直接给出 .md 与 JSON 端点——文件名叫一样，对代理的实际价值差了一个量级。

背景：llms.txt 的成本不在写，在你让它指向哪里

llms.txt 是 Jeremy Howard 在 2024-09-03 提出的提案（规范在 llmstxt.org），结构极简：一个 H1 写站名，紧跟一段 blockquote 摘要，然后若干 H2 分节，每节下面是一串 Markdown 链接。另有一个约定俗成的 Optional 分节，放"上下文紧张时模型可以跳过"的链接。

它的初衷是给检索系统一张"策划过的地图"，顺带解决两件事：一是让代理不必从导航栏里猜内容边界，二是省 token。第二件事恰恰是最容易被做废的——如果地图上的每一条链接都指向一个 60 万字节的渲染页，那么 llms.txt 省下的那点字节，会在代理跟进第一条链接时全部还回去。

采纳率方面，公开可查的口径并不乐观：2026 年 1 月一份基于 Common Crawl 的非正式调查称，top 100M 域名中 llms.txt 的占比约 0.4%，且集中在技术、SaaS 与开发者工具类站点（该数字为第三方自述，非本次复现）。

落地实测清单：同一份文件，两条完全相反的路

以下是 2026-11-11 本机直接抓取两家站点根目录 llms.txt 的原始结果（未压缩原始字节，非第三方转述）。

两者 H2 的命名方式，直接暴露了各自的产品思路：

# Stripe
## Payments        ## Connect        ## Payment Links   ## Checkout
## Elements        ## Billing        ## Invoicing       ## Tax
...（共 31 个 H2，按产品线铺开，308 条链接）

# Vercel
## When to use Vercel        ## How agents should use Vercel
## Agent setup               ## Documentation
## REST API and developer resources       ## Self-serve onboarding
## Knowledge Base            ## Learning and updates
## Optional
（共 9 个 H2，28 条链接，其中 21 条直指 .md）

Vercel 的第二个 H2 干脆叫 "How agents should use Vercel"——它不是在给人写目录，是在给代理写使用说明。

跟进这些链接会发生什么：抽样实测

从 Stripe 的 284 条非 .md 链接中随机抽 8 条，逐条请求：

200 | text/html; charset=utf-8 | 811,891 B | https://stripe.com/startups
200 | text/html; charset=utf-8 | 553,522 B | https://stripe.com/connect/pricing
200 | text/html; charset=utf-8 | 520,920 B | https://stripe.com/resources/more/alipay-an-in-depth-guide
200 | text/html; charset=utf-8 | 843,727 B | https://stripe.com/pricing
200 | text/html; charset=utf-8 | 973,373 B | https://stripe.com/customers
200 | text/html; charset=utf-8 | 602,420 B | https://stripe.com/industries/insurance
200 | text/html; charset=utf-8 | 596,294 B | https://stripe.com/payments/link
200 | text/html; charset=utf-8 | 504,804 B | https://stripe.com/resources/more/what-is-micro-deposit-verification-here-is-how-it-works

8/8 全部命中 HTML 渲染页，单页 504,804～973,373 字节。

同一方法抽 Vercel 的 7 条非 .md 链接，目标性质完全不同：

200 | application/json                  | 11,859 B     | https://vercel.com/docs/taxonomy.json
200 | application/json                  | 11,873,079 B | https://vercel.com/docs/graph.json
200 | application/json                  | 12,296,056 B | https://vercel.com/openapi.json
200 | application/ai-catalog+json       | 2,088 B      | https://vercel.com/.well-known/ai-catalog.json
200 | application/json                  | 570,520 B    | https://ai-gateway.vercel.sh/v1/models
200 | text/plain; charset=utf-8         | 98,538 B     | https://vercel.com/academy/llms.txt
读取超时（>25s）                        | —            | https://vercel.com/docs/llms-full.txt

注意 Vercel 也不是全对：graph.json 11.8 MB、openapi.json 12.3 MB，这种体量对上下文有限的代理来说等同于"不可读"，只能靠才端点切片。但它至少把目标从"给人看的页面"换成了"给机器读的数据"。

两个文件的分工，两家都只做了一半

llms-full.txt 是 llms.txt 的全文变体，本意是让代理一次拿全、不用逐页跟进。实测：

• https://stripe.com/llms-full.txt → 404

• https://vercel.com/llms-full.txt → 404

• https://vercel.com/docs/llms-full.txt → 存在（页面里被引用），但 25 秒读不完

真正做对的是子树分册：https://stripe.com/docs/llms.txt 返回 99,193 字节的 text/markdown（注意不是 text/plain），这是把 31 个产品线塞进一个根文件之外的正确做法。而按产品继续细分的 https://stripe.com/payments/llms.txt 则是 404——分册只做了一层。

内容协商：一家认，一家不认

v2 讨论里常见的一条是"同一 URL 通过 Accept: text/markdown 返回 Markdown"。实测两家：

Vercel 的 /docs 在协商后体积从 903,432 字节降到 9,366 字节，降幅 99%。Stripe 的 /payments 无论怎么请求都是 1.2 MB 的 HTML，且不带 Vary——这意味着即便将来 CDN 层加了协商，缓存也可能把 HTML 版本串给要 Markdown 的请求。

robots 与 AI 爬虫：两家都没有针对性放行，但都没有拦

坊间最常见的翻车是"写了 llms.txt，同时在 robots.txt 里把 AI 爬虫整站 Disallow"，结果文件对最可能读它的 bot 不可见。实测两家都没有这个问题，但也没有主动网开一面：

• stripe.com/robots.txt：643 字节，主体是 User-agent: ia_archiver 段与 User-agent: * 段，全文中 GPTBot / ClaudeBot / OAI-SearchBot / Google-Extended / PerplexityBot / CCBot 等关键词命中 0 次，即默认放行。

• vercel.com/robots.txt：575 字节，User-Agent: * 下先 Allow 几个 OG 图接口，再 Disallow: 空行，再 Disallow /api/、/oauth 等；AI bot 关键词命中同样为 0 次。

UA 层也没有差别对待：分别用 GPTBot、ClaudeBot、普通 Chrome 三种 UA 请求两站根目录 llms.txt，三次返回的状态码、Content-Type、字节数完全一致（Stripe 均 69,923 B，Vercel 均 5,397 B），不存在 CDN 按 UA 拦路径的情况。

可以直接抄的检查命令

# 1. 文件是否真的存在、类型对不对（应为 text/markdown 或 text/plain，绝不能是 text/html）
curl -sI https://yourdomain.com/llms.txt | grep -iE 'HTTP/|content-type|cache-control'

# 2. 统计链接构成：多少条指向 .md，多少条指向 HTML
curl -s https://yourdomain.com/llms.txt \
  | grep -oP '\]\(\K[^)]+' \
  | awk '{ if ($0 ~ /\.md$/) md++; else html++ } END { print "md="md" other="html }'

# 3. 抽一条 HTML 链接看代理要付多少字节（这条路决定了 llms.txt 是否白做）
curl -s -o /dev/null -w '%{http_code} %{content_type} %{size_download}\n' https://yourdomain.com/some-page

第 3 条是最容易被忽略、也最能判定成败的一步：llms.txt 的体积不等于代理的读取成本，链接目标的体积才是。

结果：没有排名数据，但有一个可量化的"读取成本"差

两家站点都没有公开 llms.txt 相关的引用量、排名或流量变化，本次实测也无法观测到 AI 引用命中。能在本机量出来的只有一件事：代理沿同一条 llms.txt 走一步的成本。

• 走 Stripe 的路径：读 69,923 字节索引 → 抽中一条产品页 → 再加 50 万～97 万字节 HTML。索引与内容的比例约 1 : 8～14。

• 走 Vercel 的路径：读 5,397 字节清单 → 取 /docs.md 9,366 字节，或取 taxonomy.json 11,859 字节。比例约 1 : 2。

• 两者的单次读取量差距在一到两个数量级；而 llms-full.txt 在两家根路径都缺席，说明"让代理一次拿全"的分支实际上都没落地。

定性观察（不是数据）：Stripe 的 llms.txt 更像一份给人读的产品目录，它的信息组织方式（31 个产品线 H2、308 条链接）与官网导航几乎同构，等于把 HTML 里已有的结构又抄了一遍 markdown；Vercel 的文件短到 68 行，但每条链接都指向机器友好的表示（.md、json、ai-catalog.json），并且明确写了"代理该怎么用我"。

复盘：3 条能直接抄的配置 + 2 条踩坑

可以直接抄的：

1. 链接目标按机器可读性排序：.md > .json/结构化端点 > HTML 渲染页。经验线是单条链接目标的体积控制在 llms.txt 自身体量的 1～2 倍以内，超出就改用分册。

2. 做了内容协商就必须带 Vary: Accept，并确认同一 URL 的两种表示都能被 CDN 正确缓存；否则协商等于没做（Stripe 的 /payments 就是无 Vary 且始终返回 HTML 的例子）。

3. 大站按子树拆 llms.txt，根文件只做入口。Stripe 的 /docs/llms.txt（99,193 字节 text/markdown）证明这条路可行；但按产品再细分的 /payments/llms.txt 是 404，说明分册要一次性规划到二级，别只拆一半。

两条踩坑提醒：

1. 别只写 llms.txt 而漏掉 llms-full.txt 的校验：两家根路径的 llms-full.txt 都是 404，Vercel 的那个虽然存在但大到读不完。发布前用 curl -sI 把两个路径一起验，缺一个就在文件里明说"仅提供索引，无全文版"，别让代理白跑。

2. <link rel="alternate"> 数量多不等于有 Markdown 通道：Stripe 的 /payments 页面有 89 条 alternate，全部是 hreflang 语言版本，type="text/markdown" 是 0 条。做 v2 那套 rel="alternate" type="text/markdown" + rel="describedby" 时，直接按 type= 过滤计数，别按 rel= 计数。

标注

• llms.txt 形态：两站根文件均为 v1 形态（H1 + blockquote 摘要 + H2 链接列表，未使用 v2 讨论中的分段锚点等扩展写法）；Vercel 在页面级另加了 v2 的 <link rel="alternate" type="text/markdown"> 与 Accept 内容协商。

• 规范状态：llmstxt.org 提案 + 作者主张，LLM 厂商未官方确认为必须读取；本次实测的两站均未在 robots.txt 中针对 AI 爬虫做显式 Allow。

• 数据口径：表格内所有字节数、状态码、Content-Type、链接计数均为 2026-11-11 本机用 PowerShell（.NET HttpClient）与 Python 标准库直接请求取得，为未压缩原始字节，非第三方复现；0.4% 采纳率、Common Crawl 抽样为第三方自述，本文未复现。

• 复盘时间：2026-11-11。

• 来源：https://stripe.com/llms.txt 、https://stripe.com/docs/llms.txt 、https://vercel.com/llms.txt 、https://vercel.com/docs 、两站 robots.txt；规范参考 llmstxt.org。

• 标签：llms.txt、AI可见度、AIWO、结构化暴露、开发者文档站