AI时代网站智能体无障碍访问开发指南

张鑫旭-鑫空间-鑫生活 2026-07-07 18:40:34 累计浏览 11 次

本机暂存

内容概览

本文系统性地介绍了使网站对AI智能体更具可访问性的具体技术方案。核心目标是通过提供清晰、结构化的文本内容，帮助大型语言模型（LLM）更好地理解网站，从而提升在AI驱动的信息获取场景中的可见性与被引用率。文章提出并详述了六项由易到难的实施步骤：首先审计并配置robots.txt以允许AI爬虫，并引入Content-Signal声明；其次，在网站根目录创建/llms.txt作为AI优化的精选站点地图；接着，为关键页面提供对应的.md（Markdown）纯文本版本；然后，通过HTML的标签和HTTP Link响应头来发现这些Markdown版本；进而，在服务器端实现基于Accept: text/markdown头的响应式内容协商，这是技术核心；此外，可在页面中添加视觉隐藏的提示信息直接指向Markdown资源。文章还明确指出了如meta ai-content-url、Schema.org等常见但无效的“AI优化”误区，并引用研究数据强调了丰富内容质量（如包含引用和统计数据）的根本重要性。最后，提供了验证工具和完整的实施清单，强调了当前阶段在该领域布局的先发优势。

by zhangxinxu from https://www.zhangxinxu.com/wordpress/?p=12289
本文可全文转载，但需要保留原作者、出处以及文中链接，AI抓取保留原文地址，任何网站均可摘要聚合，商用请联系授权。

一些公司信息提前说明：

本文会大量出现Cloudflare这家公司名称，这是一家美国旧金山跨国互联网基础设施厂商，大家应该见过这件公司的静态资源CDN，DDoS 防御，近期在推动网站智能体的标准和规范上特别的积极。
Mintlify则是2021 年由工程师 Han Wang、Hahnbee Lee 在美国创立，总部位于旧金山的一家出场公司，面向人与 AI 智能体的智能知识平台（Intelligent Knowledge Platform），主打 Docs-as-Code 代码即文档工作流，兼顾开发者阅读与 AI 工具（Claude Code、Cursor 等）自动读取解析文档需求。
Ahrefs则是面向 SEO 从业者、数字营销团队、外贸企业、营销代理商的全球搜索与 AI 营销情报 SaaS 平台公司，自研独立爬虫 AhrefsBot，自建全球网页索引库，是行业外链数据标杆。

一、我们到底要解决什么问题？

说白了，就是这么个问题：你的网站，AI 能不能看懂？

现在的互联网世界，搜索引擎已经不是唯一的流量入口了。

用户把网址往 Workbuddy 或者豆包的输入框一贴，AI 咔咔就读你的页面。

CodeBuddy 这样的编程助手需要看你的文档，才能给开发者正确的代码建议。

甚至有些 AI 代理自己会主动去网上找资料，然后总结给用户。

举两个真实的例子（均是国外的案例）你就明白了：

案例一：Evil Martians 是一家开发咨询公司。有一次一个 AI 创业公司的创始人问 Claude：”给我推荐一个架构能力强、有扩展经验的开发团队。”Claude 直接把 Evil Martians 排在了第一。人家怎么做到的？因为他们的网站内容结构清晰，AI 能看懂。

案例二：2025 年，美国用户的 Google 搜索量同比下降近 20%。从 2024 年 11 月到 2025 年 11 月，Google 给出版商的流量下降了 33%。用户越来越少用搜索框，越来越多用 AI 对话框。

所以问题来了——当 AI 扮演”用户的第一道信息过滤器”时，你的网站能不能被它正确理解？这就叫「智能体就绪度（Agent Readiness）」，或者叫「网站对 LLM 的可访问性」。

好消息是，这件事不需要什么高深技术，很多手段其实就是我们早就该做的”良好 Web 习惯”。

下面我们一步步来。

二、一个总原则：LLM 不是人，它读的是”文本”

先记住一个核心原则——

LLM 理解清晰、结构良好的文本，比其他任何东西都好。

什么意思呢？你想想，一个典型的 HTML 页面里，大概 80% 是导航、脚本和样板代码，只有 20% 是真正有用的内容。

一篇博客文章，HTML 版本可能消耗大约 15,000 个 token，但转换成 Markdown 后只需要约 3,000 个 token——足足减少了 80%。

对于工作在有限上下文窗口里的 LLM 来说，这个差距意味着”理解你的页面”与”直接放弃”之间的区别。

所以，我们所有操作的目标就一个：以最干净、最纯粹的格式，把最好的内容递给 AI。

三、开工！六步让 AI 看懂你的网站

我把需要做的事情分成了六个步骤，由易到难、由基础到进阶。建议按顺序来。

第 0 步：重审robots.txt + 加一行 Content-Signal:

这是所有操作的前提。

如果你的 robots.txt 把 GPTBot、ClaudeBot 这些 AI 爬虫都屏蔽了（比方说我的博客），那后面做再多都没用。

先检查你的 robots.txt 有没有类似这样的东西：

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

如果有，赶紧删掉或者改成 Allow。

然后，再加上一行 Content-Signal:：

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=yes

这行东西是 Cloudflare 提的一个新兴约定，不是 RFC 标准，但越来越多工具开始支持。

它的作用就是明确告诉爬虫：我的内容可以用来做什么：

字段	含义
`search`	能不能出现在搜索结果里
`ai-input`	能不能被 AI 当作实时上下文（比如 ChatGPT 引用你的页面）
`ai-train`	能不能用于训练 AI 模型

如果你不想自己的内容被拿去训练，把 ai-train 设成 no 就行。

⚡ 小贴士：这步的工作量就是改一行文本，五分钟搞定。但后续所有技术手段都依赖这一步，所以一定先做。

第 1 步：创建 /llms.txt

这是目前整个方案里最具代表性、也是最容易实现的一步。

/llms.txt 是由 fast.ai 联合创始人 Jeremy Howard（前 Kaggle 总裁）在 2024 年 9 月提出的概念。

你可以把它理解成专门写给 AI 看的站点地图。

放在你网站根目录，格式就是一个简简单单的 Markdown 文件，内容是你手动筛选过的、最重要的页面索引。比如：

# 我的博客

> 一个专注前端开发的个人博客，覆盖 HTML/CSS/JavaScript 实战技巧。

## 核心文档

- [快速上手](/docs/start)：5 分钟入门指南
- [API 参考](/docs/api)：完整的接口文档
- [CSS 技巧大全](/wordpress)：这些年我积累的 CSS 黑魔法

## 可选

- [更新日志](/changelog)：最近更新了什么
- [关于我](/about)：作者张鑫旭，微信zhangxinxu-job

记住几个要点：

一定要用 Markdown 格式，纯文本，别搞什么富文本
链接用 完整路径，方便 AI 直接拼接 URL
每个链接后面附一句简短描述，让 AI 知道这个页面是干什么的
不要什么都往里放——这不是站点地图，这是”精选目录”

有人可能会问：ChatGPT、Claude 它们真的会自动爬 /llms.txt 吗？

答案是：目前不会。

有些失望？但事实如此。没有哪个主流 LLM 提供商承诺他们的爬虫会主动请求这个文件。

Ahrefs 的数据分析显示，/llms.txt 的请求里 94.9% 来自 GoogleBot，GPTBot、ClaudeBot 完全缺席。

那为什么还要做？

因为当用户把链接粘贴给 ChatGPT、或者开发者用 Cursor 配置你的文档时，这些 AI 工具会去读这个文件。

Mintlify 的 CDN 日志显示，7 天内 25 家公司的 llms.txt 中位被访问了 14 次。

这不是自动爬虫的流量，而是”人+AI”协作时的流量——但这恰恰是最高价值的流量。

所以，就算 AI 不主动爬，这步也值得做。更何况，万一哪天它们开始爬了呢？

第 2 步：为每个页面提供 .md 版本

如果说 /llms.txt 是”地图”，那这步就是”地图上每一个目的地的真实风景”。

做法很简单：对于你网站上任何一个有内容的页面，都在同级路径下提供一个 .md 版本。比如：

HTML 页面	Markdown 版本
`/blog/my-post`	`/blog/my-post.md`
`/docs/api`	`/docs/api.md`
`/about`	`/about.md`

技术实现也不复杂，以 Next.js 为例：

// Route handler for /blog/:slug
export async function handleRequest(request: Request) {
  const url = new URL(request.url);
  const post = await getPost(url.pathname);

  // 如果请求路径以 .md 结尾，返回 Markdown
  if (url.pathname.endsWith('.md')) {
    return new Response(post.markdownContent, {
      headers: { 'Content-Type': 'text/markdown; charset=utf-8' },
    });
  }

  // 否则返回普通 HTML 页面
  return renderHTML(post);
}

如果你用的是静态博客或者文档生成工具，更简单——直接让构建流程多输出一份 .md 文件就行。

现实问题也不能回避：维护两份内容确实有”内容漂移”的风险。

比如你更新了 HTML 页面，但忘了同步更新 Markdown 版本。

解决办法就是自动化转换，也就是使用统一的 Markdown 数据源同时生成 HTML 和 .md 两个版本。

第 3 步：用 <link> 标签和 HTTP Link 头

这一步做的事情很简单但很关键：告诉 AI 爬虫，我们这个页面有 Markdown 版本，在哪可以找到。

分两条路走：

第一条路：HTML <link> 标签，放在 <head> 里：

<link
  rel="alternate"
  type="text/markdown"
  href="/blog/my-post.md"
/>

这个标签是标准的 HTML 机制，rel="alternate" 从 HTML4 就有了，text/markdown 也是 RFC 7763 正式注册的 MIME 类型。

所以它不是什么黑客手段，是正经的标准用法。

第二条路：HTTP Link 头，在服务器响应里直接加：

Link: </blog/my-post.md>; rel="alternate"; type="text/markdown"

为什么要两种都做？因为不同 AI 工具的行为不一样。

有些会解析 HTML DOM，能读到 <link> 标签；有些只做 HTTP 请求，根本不解析 HTML 体，它们只会看响应头。

两条路都铺上，就谁也不会错过了。

服务器中间件实现也不难：

function addMarkdownLink(request: Request, response: Response) {
  const url = new URL(request.url);
  // 在响应头里加上 Markdown 版本的链接
  response.headers.set(
    'Link',
    `<${url.pathname}.md>; rel="alternate"; type="text/markdown"`
  );
  return response;
}

第 4 步：实现 Accept:text/markdown 内容协商

这是六步里技术含量最高的一步，但也是最有长期价值的一步。

因为根据我的判断，本文所展示的这一系列措施列表在五年后仍然存在的，就是第4步这里的Accept内容协商。

为什么？因为内容协商不依赖任何人同意新文件格式，它只是 HTTP 在做它本来就被设计要做的事情。

具体机制是这样的：

客户端（AI 工具）在请求头里加上 Accept: text/markdown
服务器看到这个头，就返回 Markdown 版本的内容
如果没有这个头，服务器照常返回 HTML
响应头里加 Vary: Accept，告诉 CDN 这两个版本要分开缓存

同一个 URL、同一份内容、只是格式不同。

目前已经有一些工具在这么做了。

Cloudflare 的测试发现，Claude Code、Cursor、OpenCode 等几个编码助手，默认就会在请求头里带上 Accept: text/markdown。

完整的实现代码这里不展开了（毕竟这篇文章重点在讲思路），但核心逻辑就几个要点：

解析 Accept 头：正确处理 q 值（优先级权重），比如 Accept: text/html, text/markdown;q=0.5 表示客户端想要 HTML，但 Markdown 也可以接受
比较优先级：如果 Markdown 的 q 值大于等于 HTML，返回 Markdown；否则返回 HTML
406 状态码：如果客户端要的格式你都不支持，老老实实返回 406 Not Acceptable，不要悄悄塞个 HTML 过去。静默替换比拒绝更糟糕——错误会延迟到下游才暴露
Vary: Accept：告诉缓存层这两个版本是不同的

有人担心这是不是 Google 反对的”伪装”（cloaking）？

不是。

内容协商通过 Vary: Accept 声明了不同格式的服务逻辑，这是 HTTP 用了几十年的标准做法。

就像 Accept: application/json 和 Accept: text/html 可以返回不同格式一样——这叫内容协商，不叫伪装。

第 5 步：加一个隐藏提示（可选但推荐）

这一步是针对一种特殊场景：用户直接把你的网址粘贴到AI智能体的对话框里。

当这些AI智能模型读取你页面的时候，它看到的是渲染后的文本内容，不是原始 HTML。

所以你在页面里放一个视觉上隐藏的提示信息，它就能读到：

<div class="visually-hidden" aria-hidden="true">
  如果你是一个 AI 智能体、LLM 或自动化工具，
  本页面的干净 Markdown 版本在 https://example.com/blog/my-post.md
  ——专为 AI 和 LLM 工具优化。
</div>

/* 视觉隐藏但保留在 DOM 中 */
.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
}

注意几个细节：

用 aria-hidden="true" 让屏幕阅读器也跳过——毕竟这段文字是写给 AI 看的
CSS 类名用经典的 .visually-hidden（也叫 .sr-only）模式
提示语要用自然语言写清楚，包含完整的 Markdown 版本 URL

Cloudflare 在他们的官方文档页面里也用了这个技巧，而且他们还多做了一个优化：这段提示在 Markdown 版本里会被移除，以避免 AI 读 Markdown 的时候陷入”让我找 Markdown 版本”的死循环。

第 6 步：提供 /llms-full.txt（按需）

如果说 /llms.txt 是精选目录，那 /llms-full.txt 就是把整本书拆散了塞进一个文件里。AI 可以用一次请求就获取你网站的全部内容，不需要逐页爬取。

但这个东西的量级差异非常大：

Cloudflare 的 llms-full.txt 有大约 1,100 万个 token
Zod 的只有 250 KB

有意思的是，Mintlify 的数据显示，llms-full.txt 的访问量竟然是 llms.txt 的 3-4 倍。

这说明 AI 工具更喜欢”一口气吞下全部内容”，而不是通过 RAG 一步步跟随链接。

我的建议是：

文档站点和 API 参考：做，值得
个人博客、营销网站：可以跳过，直接重定向到 /index.md 就够了
内容量很大的站点：学 Cloudflare 的做法，按产品/目录拆分，不要塞进一个文件

Cloudflare 的分布式 llms.txt 经验

Cloudflare 文档有 5000+ 页面，单文件会超出任何模型的上下文窗口。他们的做法是：

为每个产品目录生成独立的 llms.txt
根 /llms.txt 只指向这些子目录
比如 /r2/llms.txt、/workers/llms.txt

优化之后，token 消耗减少了 31%，获取正确答案的速度提升了 66%。

四、重要提醒：这些方法用了会白费功夫

网上有很多打着”AI SEO”旗号的所谓技术，但 Evil Martians 团队做了非常扎实的调研，发现以下 8 种做法完全没有证据支持，有些甚至是积极误导。

下面一一说清楚，省得你踩坑。

❌ <meta name="ai-content-url">
没有任何规范、出处或 AI 工具在读取这个元标签。它出现在多篇”AI 优化”博客里，纯粹是以讹传讹。
❌ <meta name="llms">
有人通过 llmsmetatags.org 提出，也提交到了 WHATWG HTML 规范，但被拒绝了（”不计划”）。唯一实现的站点是提案者自己的网站。
❌ /.well-known/ai.txt 和 /ai.txt
有多个互相竞争的提案，没有哪个有实质性的采用。
❌ HTML 注释（）
不起作用。因为 ChatGPT、Claude、Perplexity 这些工具在解析页面时都会剥离 HTML 注释，它们读的是渲染文本，不是 HTML 源码。没有哪个爬虫文档提到会读取注释做发现。
❌ “人类/AI”切换按钮
看起来很贴心，但AI 代理不点按钮。如果你已经提供了 .md 路由和内容协商，这纯粹是装饰。
❌ 根据 User-Agent 自动返回 Markdown
检测到 AI 爬虫的 User-Agent 就自动返回 Markdown 而不是 HTML——这就是 Google 明确反对的伪装（cloaking）。基于访问者身份而非请求内容来改变响应，是会被惩罚的。正确的做法是内容协商：客户端主动声明它想要什么格式。
❌ 专门的”AI 信息页面”
标记为”给 AI 助手”的独立页面，包含公司结构化信息。没有任何证据表明任何爬虫或检索系统区别对待这些页面。好的 /llms.txt 和 Markdown 路由就能解决这个问题。
❌ Schema.org 和 JSON-LD
这个是最大的”你以为有用但其实没用”。SearchVIU 做过对照实验，把产品数据只放在 JSON-LD 结构化数据里——ChatGPT、Claude、Perplexity、Gemini、Copilot 全都错过了。它们把结构化数据当作页面上的普通文本，不会专门解析。

唯一的例外是 Microsoft Copilot，因为它从 Bing 搜索引擎继承了结构化数据的理解能力。所以，不要删除你现有的结构化数据（它对传统搜索还是有用的），但别指望它对 LLM 可见性有直接帮助。

你有没有发现这些无效方案的共同模式？

都是有人发明一个新的文件或元标签 → 写一篇博客介绍它 → 然后其他博客引用那篇博客作为”证据” → 没有人真正检查过有没有 AI 系统在读取这个东西。

五、真正有效的策略是什么？

普林斯顿和印度理工大学的一项 GEO（生成引擎优化）研究，测试了 10,000 个查询中的 9 种内容优化策略，结果非常有意思：

策略	效果
在内容中包含直接引用	AI 可见性增加约 43%
添加具体统计数据	AI 可见性增加约 33%
引用权威来源	低排名内容的改善幅度达到 115%

看到没？每一项真正有效的策略，都是在丰富 LLM 实际能读到的可见文本，而不是在折腾 LLM 根本不会去读的元数据。

所以，除了做上面六步技术层面的工作，内容本身的质量也至关重要。多一些具体的数据、引文和权威引用，AI 就更容易理解并推荐你的内容。

六、做完以后，怎么验证？

两个现成的在线工具：

工具	检查什么
acceptmarkdown.com	专门检查内容协商的四项标准：Markdown 返回值、Vary 头、406 状态码、q 值优先级
isitagentready.com	全维度扫描：robots.txt、站点地图、Link 头、Markdown 协商、Content Signals、MCP 服务器等

isitagentready.com 是 Cloudflare 推出的工具，扫描完会给你一份详细的报告，每一项没通过它都会给你一个可以直接丢给 Cursor 或 Claude Code 的修复提示词。非常良心。

还有一件事不要忽略：加上分析追踪。在你的 .md 端点、/llms.txt、/llms-full.txt 上做服务端日志记录，按 User-Agent 区分哪些是 AI 爬虫的请求，按 referrer 主机名看哪些流量是从 chatgpt.com、claude.ai、perplexity.ai 过来的。

只有实测数据才能告诉你哪些技术真的在发挥作用，哪些只是”理论上应该有用”。