给 AI 爬虫提供 markdown：6 个文档站里 3 个已经做了

规则变动 · 2026-08-15 · 实测 6 个文档站

样本与口径：对六个文档站各试两种取法——在网址后加 .md，以及发 Accept: text/markdown——UA 用 OAI-SearchBot，2026 年 8 月 15 日，读返回的 content-type。

给 AI 爬虫提供 markdown 这件事已经在悄悄上线了：Anthropic、Next.js、Cloudflare 的文档，在网址后加 .md 都会返回 text/markdown。Cloudflare 更进一步，普通网址上发 Accept: text/markdown 也认。两个站返回 404，还有一个从 .md 路径返回了 HTML——那才是最值得知道的失败形态。

两种机制

它们的区别很要紧。一种要求客户端知道有这么个约定，另一种只需要它发一个本来可能就会发的头。

给 AI 爬虫提供 markdown：谁已经做了

对每个文档入口请求它的 .md 变体。要看的是 content-type 那一列。

Accept 头那一轮：Cloudflare 的文档从普通网址返回了 text/markdown；Next.js 返回 text/html——它支持后缀，不支持协商。

那个什么都不代表的 200

linear.app/docs.md 返回 200 和 text/html。那不是支持 markdown，那是应用的兜底路由拿外壳应答了一个没匹配上的路径。

这跟单页应用上发 llms.txt 踩的是同一个坑，而且值得写成一条通则：在前端渲染的站上，200 只证明有某条路由匹配上了，永远不证明你要的那个文件存在。看 content-type，别看状态码。

为什么要提供 markdown

因为那个转换是有损的，而你现在是在让别人替你做。一个 HTML 页面把内容裹在导航、脚本和版式里；任何消费它的东西都得把这些再剥回去，还要猜结构。提供 markdown 等于把「被裹起来之前那份本来就干净的」直接递过去。

老实的但书：我们不知道有哪个 AI 爬虫真的会去请求这些变体。三个资源充足的文档团队认为值得做，这是关于他们判断力的证据，不是关于爬虫行为的证据。要确认得看服务器日志里有没有对 .md 路径的请求，而别人站点的日志我们没有。

要做的话

从后缀开始，因为那就是静态文件级别的简单。多数文档生成器磁盘上本来就有 markdown 源文件；要做的是把第二个网址路由过去，并带上正确的 content-type。

# 两种方式各验一次
curl -sI https://example.com/docs/page.md | grep -i content-type

curl -sI -H "Accept: text/markdown" https://example.com/docs/page | grep -i content-type

建完之后拿它测自己的站。content-type 是 text/html 就说明没生效，不管状态码写的是什么。

这份测量说明不了什么

六个站、一次快照、只测文档入口。它没有量全网的采用率，没有检查那份 markdown 是完整的还是被截断的，也没有确立有东西在消费它。它是一小撮认真团队各自选择去建什么的一个样本。

常见问题

你们是怎么核实的

每站两次 curl，UA 用 OAI-SearchBot——一次打 .md 路径，一次带 Accept: text/markdown——读返回的 content-type。不渲染，不重试。

这是标准吗

不是。没有规范，也没有关于 markdown 放在哪里的公认约定。这正是各站后缀写法不一样、以及客户端没法依赖它的原因。

它和 llms.txt 什么关系

天然配对：llms.txt 说哪几页值得看，markdown 变体让那几页读起来更便宜。两者互不依赖。

对 Google 有帮助吗

两边都没有证据，而且我们也不预期有。Google 解析 HTML 毫无问题。这件事是给那些不解析的客户端做的。

一句话

六个文档站里三个已经在提供 markdown，还有一个从 .md 网址返回 HTML 却报 200。你要做这件事，用 content-type 验收——然后发出去、再推送收录。