如何让网站对AI大模型可见：6种有效做法完整指南
浏览：10
巴克励步
大模型更擅长读干净、结构化的正文；目标是把最有信息量的内容以尽量少的噪声交给模型，而不是堆叠未经验证的元数据。本文涵盖 llms.txt、.md 路由、Link 头与内容协商等六种有效做法，并辨析八种常见无效「AI SEO」技巧。
核心观点
大模型更擅长读干净、结构化的正文；目标是把「最有信息量的内容」以尽量少的噪声交给模型——而不是堆叠未经验证的元数据。
背景：搜索不再是唯一入口
Gartner 曾预测到 2026 年传统搜索量会因 AI 聊天机器人等下降约 25%；后续公开数据也在相近量级波动：2025 年，美国用户的 Google 搜索量同比下降近 20%，而 2024 年 11 月至 2025 年 11 月期间，Google 搜索流量对出版商的影响下降了 33%。
当用户向 AI Chat 提问、把链接丢给豆包、Gemini、ChatGPT，或让 Cursor、VS Code 一类AI 开发平台去抓文档时，模型依赖的是从你站点抽取的信息——这一过程常常是混乱、有损信息、甚至被跳过。
好消息是：Web 上早有机制可缓解——HTTP 内容协商、
<link>、结构化 Markdown 端点——都不算新奇。新的是：LLM 与 AI 代理给了我们把这套机制接好的理由；多数实现可在一小时以内完成。第0步：检查
robots.txt。若默认配置把 GPTBot、ClaudeBot 等挡在站外，下面所有技巧都无从谈起。原文建议花约十分钟做一次审计。下文按影响力 / 工作量排序介绍这六条技巧：
优先级一览
# | 机制 | 重要性 | 工作量 |
|---|---|---|---|
1 | /llms.txt | 关键 | 低，静态文件 |
2 | .md 路由 | 关键 | 低–中，路由 + 内容 |
3 | HTML <link rel="alternate" type="text/markdown"> + HTTP Link 头 | 高 | 低，模板 + 中间件 |
4 | 视觉隐藏的 DOM 提示 | 中 | 低，一个组件 |
5 | /llms-full.txt | 低–中 | 低，静态文件或重定向 |
6 | Accept: text/markdown 内容协商 | 高 | 低–中，服务端逻辑 |
+ | 对 AI 相关端点的分析/日志 | 运维向 | 中 |
1. llms.txt 是什么？为什么值得做？
若你只做清单里的一件事，优先做这个。
llms.txt 是放在站点根目录的 Markdown 文件，为 AI 系统提供精选的重要页面地图，可类比 LLM 时代的 robots.txt。该格式由 Answer.AI 的 Jeremy Howard 于 2024 年 9 月提出，规范见 llmstxt.org：通常包含站点名 H1、摘要引用块，以及带注释链接的 H2 分区。Anthropic、Mintlify、GitBook、Docusaurus、VitePress，以及 Baklib 等网站与社区目录等生态在快速增长，「约 2100+ 站点」已经支持 llms.txt。
示例：Baklib
# Baklib
> Baklib 是一款 AI 赋能的企业级内容云平台，集知识库、资源库、应用库于一体，一站式解决内部知识沉淀、数字资产管理与外部品牌门户、客户服务等多场景内容管理需求。
For complete documentation in a single file, see [Full documentation](https://www.baklib.com/llms-full.txt).
Append `.md` to any page URL to view its content in Markdown format.
## Key pages
- [developers](https://www.baklib.com/developers)
- [partners](https://www.baklib.com/partners)
## partners
- [Baklib学者计划：助力学生技术传播实践](https://www.baklib.com/partners/learning)
- [功能特性](https://www.baklib.com/features)
## 功能特性
- [数据分析](https://www.baklib.com/features/anlytics)
- [AI Ready](https://www.baklib.com/features/ai-ready)
- [独立部署与私有化](https://www.baklib.com/features/on-premise)
......不过...
没有主流 LLM 厂商正式承诺其爬虫会读取该文件。Ahrefs 分析指出 OpenAI、Anthropic、Google、Meta 均未「背书」；对 1000 个 Adobe Experience Manager 域名的日志研究也显示：大模型爬虫很少主动请求
/llms.txt，请求中很高比例来自 Googlebot，GPTBot / ClaudeBot / PerplexityBot 可能缺席；Google 的 John Mueller 亦曾表示「目前没有 AI 系统在用 llms.txt」（表述以原文引述为准）。另一方面，Mintlify 对 25 家公司 CDN 日志的分析又显示：
llms.txt 与 llms-full.txt 仍有一定访问量，且 ChatGPT 占相当比例。差异可能来自受众：面向开发者的文档站比泛企业站更容易被 AI 工具访问。为何仍排第一？ 价值不仅在「自动索引」，更在人类或编码工具把 URL 交给 LLM 时的可读性——它更像「AI 中介对话里的 README」，而非单纯爬取目标。创建成本低、副作用小，但要对「今天实际能做什么」有清醒预期。
2. 为何 .md 路由才是「真正指向的内容」？
清单里其它条目多是指针；指针指向的应是干净 Markdown。
llmstxt.org 建议：任何有实质内容的页面，应在同一 URL 追加
.md 提供 Markdown 孪生，例如 example.com/blog/post 对应 example.com/blog/post.md；首页则可为 /index.md。👋
示例：Baklib
当用户在 ChatGPT 里打开
example.com/llms.txt 并跟随链接时，若落地是干净 Markdown 而非「HTML 大杂烩」，回答质量会明显提升。原文举例：真实博文从约 15000 token 的 HTML 降到约 3000 token 的 Markdown，约 80% 体量缩减——在上下文窗口有限时，这可能是「模型读懂」与「直接放弃」的差别。不过...
与
llms.txt 类似：没有强证据表明 LLM 爬虫会自发大量拉取 .md。对两个高流量站点的 CDN 分析甚至发现：即便 .md 已在 llms.txt 列出，GPTBot / ClaudeBot / PerplexityBot 对 .md 的请求仍可为零。价值仍主要在人类发起的交互：用户贴 URL，工具跟随链接，最终拿到 Markdown。这与「爬虫会自动索引 Markdown」不是一回事。
另有研究视角：HtmlRAG 指出 HTML 保留标题、元数据、表格布局等语义，在部分 RAG 管线中检索表现可能更好。原文结论：最强理由不是 Markdown 天生更优，而是现实站点 HTML 往往被导航、脚本、样板代码严重污染；若你的 HTML 已经语义干净，差距会缩小。
工程风险：双轨维护 HTML 与 Markdown 容易漂移。应自动化转换或坚持单一事实来源（SSOT）。
🤙
关于这个风险，Baklib 则提供了一个最优解：你只需要给需要输出给.md文件的变量添加“to_markdown”: true ，则内容就会同步到 .md 文件：
"settings": [
{
"id": "title",
"type": "text",
"label": "标题",
"to_markdown": true
},
{
"id": "description",
"type": "textarea",
"label": "摘要",
"to_markdown": true
},
...3. 如何让 LLM「发现」Markdown 版？<link> 与 HTTP Link 头
这是同一件事的两种宣告方式，面向两类客户端。
HTML <link> 标签
放在
<head> 中，任何处理 HTML 的爬虫都能读：<link
rel="alternate"
type="text/markdown"
title="Markdown version"
href="/blog/my-post.md"
/>机制与 RSS 发现（
application/rss+xml）、多语言 hreflang 类似。rel="alternate" 自 HTML4 起即存在于 WHATWG HTML；text/markdown 亦已由 RFC 7763 注册。HTTP Link 响应头
语义相同，但在读取响应体之前即可见。部分 AI 代理（尤其自主代理与编码助手）根本不解析 HTML，只发 HTTP 请求并读头：
Link: </blog/my-post.md>; rel="alternate"; type="text/markdown"或者在请求中间件里添加一行代码即可为全站附加markdown请求提示，见 TypeScript 示例：
function addMarkdownLink(request: Request, response: Response) {
const url = new URL(request.url);
response.headers.set(
'Link',
`<${url.pathname}.md>; rel="alternate"; type="text/markdown"`
);
return response;
}建议两者都上：HTML 标签覆盖解析 DOM 的爬虫；HTTP 头覆盖不解析正文的抓取器。
4. 若用户只是把 URL 贴进 ChatGPT 呢？
很多指南忽略的场景：人类把 URL 贴进 ChatGPT / Claude，模型读到的是渲染后的页面文本——没有爬取、没有头信息，只有「模型能看见的字」。
做法：在 DOM 中加入视觉隐藏的块（对明眼用户不可见，但存在于文档中），用自然语言提示 Markdown 版的地址；并对该块使用
aria-hidden="true"，让屏幕阅读器跳过——这条消息是给 LLM 的，不是给无障碍辅助技术的。示例：你可以查看 www.baklib.com下每篇文章的源代码，会发现源代码中有如下提示：
<div class="absolute w-px h-px p-0 overflow-hidden whitespace-nowrap" aria-hidden="true">
A Markdown version of this page is available at
{{ page.url }}.md — optimized for AI and LLM tools.
</div>
Baklib 全站页顶即有类似「若你是 AI 代理 / LLM / 自动化工具，可在某 URL 获取干净 Markdown…」的提示。它对先处理原始 HTML 再渲染的爬虫帮助有限，但对对话式使用非常直接；成本也最低。
5. 何时需要 /llms-full.txt？
它是
/llms.txt 的「伴侣」：虽非 llmstxt.org 正式规范的一部分，但被 Baklib、Mintlify、Fern 等文档平台广泛采用（见 Mintlify 博文链接）。/llms.txt：精选链接索引。/llms-full.txt：整站或整库文档的合并正文，一次抓取、少跳转，适合「单请求吞完整文档集」。
小站可把公开内容拼进一个 Markdown；大站更现实的做法是重定向到
/index.md 或提供代表性子集。规模差异极大：Cloudflare 的 llms-full.txt 可达千万 token 量级；亦有项目控制在约 250 KB。文档站可能很合适；营销站或博客可能过度——重定向到 /index.md 也可接受。Mintlify 的日志分析还发现：
llms-full.txt 访问量可达 llms.txt 的 3–4 倍，且 ChatGPT 占相当比例。一种解释是：模型更偏好「一次嵌入完整文档」而非多跳 RAG 跟链接。👋
示例：Baklib
6. 面向 LLM 的「内容协商」是什么？
客户端发送：
Accept: text/markdown, text/html;q=0.9服务器在同一 URL 上优先返回 Markdown，否则回退 HTML；用
Vary: Accept 让 CDN 分别缓存。这与 HTTP/1.1（1997）以来「同一资源多表示」的机制一致。Checkly 对 AI 代理行为的分析 指出：Claude Code、Cursor 等已常把
Accept: text/markdown 作为偏好类型。与第 3 节的 HTTP
Link 头组合，可在单一处理器里覆盖多种客户端（原文含完整 TypeScript 示例）。与「提示类」技巧的本质区别
内容协商不要求客户端掌握站点私有约定：只要发对头，符合规范的服务器就返回 Markdown。作者认为：若赌五年后仍存活的机制，更可能是这条——因为它依赖的是 HTTP 本身，而非新文件格式共识。
不过...
Google 将「对爬虫呈现与用户不同内容」定义为 cloaking。原文强调：同一 URL、同一信息内容、仅表示形式不同，并用
Vary: Accept 声明，属于 HTTP 常规用法；与「给爬虫另一篇文章」不同。类比：Accept: application/json 与 Accept: text/html 共存多年，不会被称为 REST API 在伪装。那么，什么对「AI SEO」技巧不管用？
团队在 30+ 博文、GitHub 与提案里筛过一轮，下列 8 类要么无证据，要么具有误导性：
- 来历不明的「AI 专用」
<meta>类标签
无规范、无提案来源、也找不到哪个 AI 产品会读；却出现在多篇「针对 AI 优化」的转载文中。 **/.well-known/ai.txt与/ai.txt
存在多份彼此竞争的提案，缺乏有意义的统一采用**。- HTML 注释
<!-- … -->
多数 LLM 解析路径会剥离注释；ChatGPT / Claude / Perplexity 常基于渲染后文本，而非原始 HTML 源。没有爬虫文档把「读注释做发现」当作可靠机制。 - 人类/AI 切换按钮
若已提供.md路由与内容协商，按钮对不会点击的代理基本是装饰。 - 按 User-Agent 嗅探并自动给 AI 爬虫返回 Markdown
这是按「访客是谁」而非「请求什么表示」区分内容，属于 cloaking 风险区；合规替代方案是**Accept: text/markdown协商**，由客户端显式声明格式偏好。 - 单独的「给 AI 助手看的说明页」
没有证据表明爬虫或检索系统会区别对待；好的/llms.txt与干净 Markdown 路由已能覆盖需求。 - 把产品数据只放在 Schema.org / JSON-LD 里
SearchVIU 等对照实验中，ChatGPT、Claude、Perplexity、Gemini、Copilot 等未必消费 JSON-LD 中的独占信息；业界报道也指出部分产品把结构化数据当普通文本处理。例外：微软 Copilot 可能继承 Bing 对 schema 的理解（原文给 SearchVIU、SERoundtable、Search Engine Land 等链接）。结论：不必拆掉已有结构化数据，但别指望单靠它就能提升「被 LLM 直接看见」的概率。
共性：许多方案在重复解决 HTTP 与标准 Web 机制已经能解决的问题；模式往往是某人发明新文件或 meta、写博文、其它博文互相引用——却没人验证是否有 AI 系统真的读取。
普林斯顿与 IIT 德里等在 KDD 2024 的 GEO 基础研究 也支持这一方向：在 1 万条查询上测试九种内容优化策略，有效的是直接引用、统计数据、权威来源等可见正文增强；而非模型读不到的元数据。（原文还半开玩笑：本段引用权威研究本身也是一种 GEO 技巧。）
如何知道「有没有用」？
不测就不知道。
Cloudflare 2025 Radar 等显示 AI 相关抓取在增长，但「爬虫流量」不等于「你的内容被正确引用」。应对
.md 端点、/llms.txt、/llms-full.txt 做服务端埋点：按 User-Agent 区分 AI 爬虫与普通访问，按 Referer 主机名捕捉来自 chatgpt.com、claude.ai、perplexity.ai 的流量——这是记录谁拉了什么，不是按访客改内容，故不构成 cloaking。const url = new URL(request.url);
if (url.pathname.endsWith('.md')) {
const ua = request.headers.get('user-agent') ?? '';
const ref = request.headers.get('referer') ?? '';
analytics.track('markdown_fetch', { ua, ref, path: url.pathname });
}注意：传统前端分析脚本对 AI 爬虫常无效（不执行 JS），需要服务器日志或边缘日志中的原始 UA。
上线顺序建议
- 审计
robots.txt，勿误伤 AI 爬虫。 - 添加根路径
/llms.txt（静态 Markdown，约五分钟）。 - 为各页面提供
.md路由（一切指针的最终落点）。 - 加
<link rel="alternate" type="text/markdown" …>与 HTTPLink头。 - 实现
Accept: text/markdown内容协商（基础设施级，值得在前后置就绪后做）。 - 对端点做分析与监测。
目标不是「操纵 AI」，而是像多年坚持语义化 HTML 一样，让内容对语言模型与代理也可读；其中大部分其实也是早该做好的 Web 卫生习惯。
常见问题（FAQ）
必须6条建议全上吗？
可从**/llms.txt+.md路由`** 开始，覆盖最常见访问模式，其余按需迭代。
会伤害 Google SEO 吗？
原文称：rel="alternate"、已注册 MIME、带Vary: Accept的协商均属标准 HTTP；他们在 evilmartians.com 上运行数月未观察到明显排名异常（个体站点仍建议自行监测）。
ChatGPT / Claude / Perplexity 会自动爬 llms.txt 吗？
尚未成为厂商正式承诺的行为；当前价值主要在人类或工具把 URL 交给模型的路径。若未来自动爬取跟进，属于额外收益。
如何衡量效果？
见上文「如何知道有没有用」：服务端埋点 + UA + Referer。
Baklib 已经做到了哪些部分？
- Baklib 作为 AI Ready内容管理平台，已从底层 MCP 设计到上层体验应用都贯穿大模支持。
- Baklib 的站点都默支持 llms.txt 和 llms-full.txt
- Baklib 的每篇文章都支持 .md 格式，而且支持自定义输出（只需要给变量指定属性： "to_markdown": true）
