robots.txt 在 2026 年的新角色：从搜索引擎到 AI 爬虫的控制面板

「robots.txt 在 AI 爬虫时代扮演什么新角色」，一句话回答：它从一份只给搜索引擎看的抓取说明，变成了站点对外声明「哪些机器人可以读、可以读到哪些路径」的访问控制面板。抓取这件事的参与方不再只有一两家搜索引擎，各类大模型机器人也会来读页面，而这份文件依然是站点能拿出来的、覆盖面最广的声明方式。下面按「原来的作用—新增的约束—匹配规则的变化—与 llms.txt 的分工—后台怎么配」来看。

它原来解决什么问题

最早robots.txt只回答一个问题：爬虫可以请求哪些路径。站点用 User-agent 指定机器人、用 Disallow 排除不想被抓的目录，再配合站点地图把要收录的地址交出去，让新内容有机会尽快进入索引。站内这套动作通常是固定的三件事：robots 配置、sitemap 自动生成、链接推送里向搜索引擎主动推送新地址。robots.txt 管「能不能进」，站点地图管「有哪些门牌号」，两者职责不重叠。

AI 爬虫时代多了哪些约束

变化在于读这份文件的对象变多了。主流 AI 爬虫在抓取页面之前会先读取 robots.txt，声誉良好的机器人会遵守文件里的指令，比如以 GPTBot、Google-Extended 这类产品令牌识别的抓取程序。这带来两个直接结论：一是 Disallow 写错的代价被放大，原本只是少一条搜索收录，现在连模型侧的可见性一起丢掉；二是想限制某类抓取，靠页面里加说明没有用，要在robots.txt里按产品令牌写规则，让规则可被机器读到。

需要说清一点：遵守与否取决于抓取方是否自愿，这份文件是声明而不是强制屏障。真正需要保护的后台路径、内部文档，还是要用权限和鉴权兜住，不能只靠一行 Disallow。

匹配规则里最容易写错的地方

抓取协议（RFC 9309）对大小写的规定是分开的两件事：查找某个 User-agent 对应的规则组时，用大小写不敏感的方式匹配；而路径本身是否命中，应当按大小写敏感来判定。也就是说，写成 /Blog/ 和 /blog/ 是两条规则，服务器区分大小写时其中一条可能完全不生效。

规则冲突时的顺序也要按协议理解：同一个地址同时被 allow 与 disallow 覆盖、且匹配程度相当时，优先采用 allow。常见的排错方法是把宽泛的目录排除写在前面，再把需要放行的具体路径写在后面，逐条比对最终生效的是哪一条，而不是凭直觉猜。

llms.txt 与 robots.txt 的分工

两份文件常被放在一起比较，但管的层次不同。robots.txt 决定「可不可以抓」，llms.txt 决定「抓到之后怎么读」——它用一份纯文本的索引说明站点结构、重点内容与边界，让大语言模型在有限的上下文里先看清站点脉络。AnQiCMS 支持自动生成站点的 llms.txt，也支持robots.txt配置与站点地图输出，三处配置要放在一起核对：被robots.txt排除的目录，写进 llms.txt 也没有意义；只在 llms.txt 出现、却没进站点地图的页面，收录面依然缺位。

后台配置时建议按这个顺序走

先看排除清单：把后台、检索结果页、购物车一类无收录价值的地址列进 Disallow，确认没有误伤正常内容目录。再看放行清单：需要被搜索引擎和模型读取的栏目保持开放，并在 robots.txt 中声明站点地图的地址，让抓取方能自动找到入口。最后看推送：新发布的内容用链接推送主动交给搜索引擎，避免只等被动发现。改完做一次回归检查——直接请求这份文件，确认返回的是最新内容而不是一段缓存或错误页。

常见问题

只拦 AI 爬虫、不拦搜索引擎，该怎么写？ 按产品令牌分组写规则，例如只对对应的抓取令牌设置 Disallow，搜索引擎那组保持原样。改完要核对分组是否真的命中，注意分组名的匹配不区分大小写，而路径匹配区分。

robots.txt 排除后内容就不会被模型引用了吗？ 降低概率，但不等于切断。这份文件靠抓取方自愿遵守，其他入口（聚合站、第三方镜像）仍在被读取，要控制可见性还得配合权限与内容下线。

llms.txt 能替代 robots.txt 吗？ 不能。前者是给模型的阅读索引，后者是访问声明，两者作用层不同，需要同时配置并互相核对。