给博客做 AI 搜索优化时，很容易遇到一条建议：在网站根目录放一个 llms.txt。

文件很小，名字又像 robots.txt，看上去像是另一个必须补齐的站点配置。但把它加上，AI 就会来读、就会收录，甚至更愿意推荐这个博客吗？

这些问题需要分开回答。llms.txt 有明确的内容组织用途，部署成本也可以很低；是否被某个工具使用、是否最终出现在回答里，则不能由文件存在与否推定。

这篇文章按 2026 年 10 月 21 日可查的提案和官方文档整理。Hexo 部分结合本博客的目录与发布流程说明接入方法，示例尚未在本站启用，也没有把它当作搜索效果实验。

llms.txt 是一份怎样的文件

可以把它看作网站为 AI 阅读工具准备的一页导览：说明站点讲什么、重要内容在哪里，以及阅读时需要知道的背景。

llms.txt 提案采用 Markdown 组织内容，推荐链接到便于读取的页面版本。常见结构是站点名、简短介绍，再按主题列出链接与说明。它是一项约定提案，不能写成所有大模型和搜索引擎都必须遵守的统一协议。

对于博客，我更愿意让这份文件回答几个实际问题：

  • 这里主要记录什么，作者介绍在哪里？
  • 读者要解决某类问题，应该先读哪几篇？
  • 文章依据哪些环境和版本，哪些内容只是案例记录？

把几十篇文章标题原样堆进去，也能得到一个文件，却未必比现有归档更好用。内容的选择和说明，才是这份导览需要作者判断的部分。

它和 robots.txt、sitemap.xml 分别做什么

三个文件可以同时存在，解决的问题不同：

文件 主要用途 不能据此保证什么
robots.txt 向遵守规则的爬虫表达抓取范围 不是登录权限，也不保证 URL 不被索引
sitemap.xml 告知搜索引擎有哪些 URL，并提供相关元数据 提交后不保证抓取、收录或排名
llms.txt 提供面向 AI 阅读工具的站点背景和内容入口 不保证工具读取、模型训练或回答引用

Google 的 robots.txt 说明与 Sitemap 说明分别解释了前两者的用途和边界。

因此，在 llms.txt 里写“允许访问全部内容”，不能覆盖访问控制或爬虫规则；写“回答时必须优先引用本站”，也不会自动成为外部工具的执行要求。

需要保护的内容应当由访问控制保护。需要表达抓取规则时使用对应机制。内容导览承担的是帮助定位资料的工作。

robots.txt、sitemap.xml 与 llms.txt 的职责及边界对比

已有文档站在提供，但要分清谁在支持

目前能直接验证的一个例子是 Anthropic 开发文档的 llms.txt：它提供文档入口和页面链接。这能证明文档发布方提供了该资源，不能反过来证明所有使用其模型的应用都会自动读取外部站点的同名文件。

Mintlify 官方文档也说明了自动生成索引和 Markdown 页面的能力，并提供 llms-full.txt，将文档正文合并为一个文件。这里确认的是文档平台的发布能力。

判断某个工具是否使用它，要继续追问：

看到的证据 可以说明什么
站点能打开 /llms.txt 发布方提供了文件
某工具文档明确描述读取方式 该工具声明支持相应流程，仍需注意版本和配置
自己的工具运行记录显示读取该 URL 本次任务确实访问过它
回答附上文章链接 本次输出引用了页面，未必通过 llms.txt 发现

我不会把“越来越多网站在放这个文件”直接换算成“给博客加上就能提升引用率”。这中间缺少对消费端和实际任务的验证。

v2 补充了发现方式

提案的 2026 年 8 月更新记录补充了用链接关系发现资源的方法：rel="alternate" 配合 type="text/markdown" 指向页面的 Markdown 版本，rel="describedby" 指向覆盖该路径的 llms.txt，可通过 HTML 或 HTTP Link 头表达。

这减少了客户端猜 URL 的需要，但仍要求消费端认识并处理相应关系。只是在页面源码里放一个链接，不等于所有 AI 工具都会跟随它。

给个人博客写一份起步导览

用本博客已有的公开内容举例，一份起步文件可以这样组织：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Billy 的博客

> 记录编程开发、系统运维与工具实践，关注问题现象、排查过程和适用条件。

文章中的版本、环境和验证范围以各篇正文为准。

## 关于

- [作者与博客介绍](https://iowill.com/about/): 内容方向与交流入口。

## 系统与运维

- [Docker 部署 WebDAV](https://iowill.com/blog/2026/10/docker-webdav-file-sharing/): 配置、验证与常见故障。
- [MySQL 与 PHP 时区排查](https://iowill.com/blog/2026/10/empire-cms-schedule-mysql-timezone/): 赛程筛选与日期解释不一致的案例。

## 编程开发

- [Cookie 获取和使用差异](https://iowill.com/blog/2026/10/kuaishou-douyin-cookie-login-differences/): 区分导入成功、业务登录与当前账号身份。

## Optional

- [文章归档](https://iowill.com/archives/): 按时间浏览其他内容。

这份示例有意使用实际存在的 HTML 页面地址，没有为它们编造 .md 链接。它先展示站点导览的组织方式；如果要按提案提供更便于工具读取的内容，还应另外发布经过整理的 Markdown 页面。

链接说明尽量描述文章解决的问题。没有测过的内容，不写成实测结论；不用“全网最权威”之类宣传词，也不把同一组关键词复制到每个条目后面。

至于 llms-full.txt，个人博客可以先不做。将全部正文合并，会增加体积，也让局部更新和按需选文变得不直观。只有确实需要整站离线阅读或批量上下文输入时，再判断它是否值得维护。这是维护成本上的取舍，不是文件越大效果越好。

Hexo 博客怎样接入

对于普通 Hexo 项目，手工维护起步文件时，可以把它放到源目录：

1
2
3
hexo/
  source/
    llms.txt

再检查配置，确保文件按预期原样复制，不被套上页面模板。如果需要显式跳过渲染，可以在 _config.yml 原有 skip_render 列表中追加文件名，保留已有条目：

1
2
skip_render:
  - llms.txt

构建后检查的是 public/llms.txt，不是只检查源目录。Hexo 的生成行为可参考官方生成文档。

本博客还有一层自己的发布约束：Actions 只部署 hexo/public，check_publish_tree.py 与本地 release.py 分别维护允许发布的路径。当前白名单尚未包含 llms.txt。

因此，如果本站后续启用，需要同时完成源文件、发布边界校验和本地 release 的接入。直接在仓库根目录手写一个文件，既不符合当前源工程约定，也不会自动进入 Actions 上传的产物。

文章更新时，导览也要更新

手工精选适合小规模起步；文章持续增长后，可以将“选择哪些文章”与“生成哪些文字”分开维护。

例如，在源数据中保留精选文章的永久链接，生成时从 Hexo 文章模型读取标题、摘要和 URL。文章重命名或修订摘要后，输出随构建更新；指定链接不存在时让校验报错，避免留下静默失效的入口。

Hexo Generator API允许生成器返回输出路径和内容。这适合接入构建，而不是发布之后再手工修改生成文件。

设计时我会保留几条检查：

  • 只引用已发布内容，排除草稿、未来文章和维护文件。
  • 使用文章实际永久链接，不从标题重新猜路径。
  • 保持稳定顺序，只有内容变化才改变输出。
  • 不默认把所有文章都加入精选列表。

Markdown 正文也需要可靠来源

本站新文章使用 Markdown，历史文章中还有带 front matter 的 HTML。二者不能简单地改个文件扩展名，就都宣称成了干净的 Markdown。

若以后提供 Markdown 阅读入口，新文章应从可靠的文章数据导出；历史 HTML 则要检查转换是否保留代码、图片、表格、链接与锚点。输出前还应去掉仅供构建使用的配置或模板标记。

先给少数精选文章提供经过核对的正文版本，比一次性导出一大批未经检查的文件更便于维护。对应 URL 真正上线后，再加入导览和页面发现链接。

验证文件可读，也验证它是否被使用

发布后可以先做最直接的检查：

1
curl -i https://example.com/llms.txt

将示例域名替换为自己的站点，检查状态码、响应类型和正文，确认没有返回 404、验证页或整张 HTML 首页。然后逐项访问链接，检查它们是否指向公开且内容正确的页面。

如果提供 Markdown 版本，还要打开正文核对。仅有 HTTP 200 并不够：文件可能缺少代码块、图片说明，或仍包含导航与模板噪声。

接下来可以选择一个能查看网络或工具调用记录的 AI 阅读流程，给它明确任务，例如“找出本站 WebDAV 文章中的配置前提并列出来源”。再检查它实际读取了哪些 URL，是否沿导览进入目标文章，以及最终引用是否准确。这是建议的验证方法，本文没有把它写成已经完成的实验。

文件可访问、工具实际读取、沿链接访问与回答引用的不同证据层次

服务器或 CDN 日志能帮助确认文件被请求，但不能单凭 User-Agent 字符串确认访问者身份，更不能由一次请求证明文章进入了模型训练或排名系统。

博客要不要加，先看能否持续维护

如果博客已经有清晰的内容结构，精选文章也会持续维护，增加一份小型导览可以作为内容分发实验。反过来，如果正文经常过期、链接已经失效，先修正文通常更值得投入时间。

对于 Google 搜索中的 AI Overviews 和 AI Mode，官方说明明确指出，不需要额外创建 AI 文本文件，也没有特殊的附加技术要求；符合基本条件同样不保证抓取、索引或展示。这项说明针对 Google 的这些搜索功能，不能延伸成所有 AI 产品的统一行为。

我的判断是：可以把 llms.txt 当作一份需要维护的内容入口，评估它是否帮助具体工具找到准确资料。文件能否正常读取、链接是否有效、正文是否可靠，都可以检查；“加上以后大模型一定推荐我”，则不能作为发布后的验收标准。