如何让自托管网站做好迎接 AI 智能体的准备

在一条关于 AI 爬虫流量的 Hacker News 讨论中，一位主机管理员从运维方的角度描述了这种负载："大约 6 个相当激进的 AI 机器人"，它们会周期性地卡在商品变体页或分类页上，然后以大约每秒一个请求的速度反复抓取，而这个站点"每次页面加载可能要耗掉整整 1 秒的往返时间（其中大部分花在 MySQL 上）"。同一条评论里给出的累积效果是："几乎相当于网站每天都被 Slashdot 一次"。

让网站做好迎接 AI 智能体的准备，首先是一个容量问题，因此这里的绝大部分工作是服务器配置，只有极少部分是内容策略。这类流量有个好处：它大多不是匿名的。产生这些流量的公司会公布自己爬虫的名称、说明每个爬虫的用途，并告诉你如何关闭它们。下面讲的是该配置什么、每种机制在实际中能强制什么，以及我会跳过的两个步骤：发布 llms.txt，以及为 AI 添加 schema 标记。

TL;DR（太长不看版）

• AI 流量通常分为三类：模型训练、AI 搜索索引，以及由用户触发的抓取。OpenAI 和 Anthropic 为这些用途提供了各自独立的令牌，因此你可以分别控制；而某些多用途爬虫则把多种角色合并在同一个身份下。
• OpenAI、Anthropic、Perplexity 和 Common Crawl 都为各自的自动爬虫提供了 robots.txt 控制方式的文档。例外是由用户触发的抓取程序：Anthropic 对 Claude-User 同样应用 robots.txt，OpenAI 表示相关规则可能不适用于 ChatGPT-User，而 Perplexity-User 通常会忽略它们。
• robots.txt 文件是一种征求同意的机制，而不是访问控制。RFC 9309 并没有赋予它自身任何强制力；守规矩的机器人遵守它能替你减轻负载，但它无法限速、也无法拦下不守规矩的流量。
• 在 Ahrefs 分析客户群覆盖的 137,210 个域名中，已发布的 llms.txt 文件有 97% 在 2026 年 5 月一次请求都没收到。你想发布就发布，但别围绕它搭建工具链。
• 在结构化数据支撑传统搜索功能的地方保留它，但谷歌的文档明确表示，其 AI 功能并不需要任何特殊的 schema 或面向 AI 的文本文件。
• 如果你希望 OpenAI、ClaudeBot、PerplexityBot 或 CCBot 能读到关键内容，就在服务端渲染它。Vercel 的测量发现这些爬虫都不执行 JavaScript；经由 Googlebot 的 Gemini 和 AppleBot 是例外。
• 超出 robots.txt 这类协作式规则之外的强制手段，落在反向代理上、落在你自己运行的 WAF 里，或者落在工作量证明质询之后，成本也依次递增。

本文不涉及的内容

本文讨论的是被智能体访问的网站，而不是与智能体做交易的网站。有四个相邻话题不在讨论范围内。

• 智能体驱动的电商与结账流程，那是另一类网站要面对的另一个问题。
• 围绕训练数据的法律与版权之争，那是一项商业决策，而不是服务器配置。
• WebMCP 的实现教程，因为该标准目前仍处于 origin trial 阶段。
• 除下文唯一一节 Cloudflare 内容之外，各家 CDN 的专属配置。

有哪些 AI 爬虫正在造访你的网站

GPTBot 和 ClaudeBot 收集可能用于模型训练的内容。OAI-SearchBot 和 Claude-SearchBot 支撑 AI 搜索与检索。ChatGPT-User 和 Claude-User 则根据用户操作抓取页面。这些职责在部分厂商那里是分开的，但网上并非每个爬虫都能干净利落地对应到单一用途。

合规的真实情况，比那种笼统说法所暗示的要精确得多。 Anthropic 的爬虫文档 指出 ClaudeBot、Claude-User 和 Claude-SearchBot 都会遵守 robots.txt。 OpenAI 的机器人文档 说明其自动爬虫使用各自独立的控制方式，但 robots.txt 规则可能不适用于 ChatGPT-User，因为那些请求是由人发起的。 Perplexity 的爬虫文档 也做了类似区分：PerplexityBot 遵循站长的设置，而 Perplexity-User 通常会忽略 robots.txt。因此，"AI 机器人一律无视 robots.txt"这种笼统说法，把遵守该文件的、有文档记录的爬虫，与行为因厂商而异的用户触发型抓取程序，以及那些从不表明身份的采集器，全都混为一谈。

下表的信息截至撰稿时。新令牌出现的速度比任何一篇文章能跟进的都快，所以请把它当作一张保质期很短的起点地图。

为 AI 爬虫编写 robots.txt 规则

RFC 9309 指出 robots.txt 中的规则并不是一种访问授权。IETF 在 2022 年 9 月标准化了语法、解析与缓存，但并没有把这个文件变成强制机制。实际会咬人的细节在语法之下：文件必须采用 UTF-8 编码，解析器必须能处理至少 500 kibibyte，而当指令冲突时，路径匹配最具体的那条胜出。规则写在文件的什么位置，则完全无关紧要。

面向 AI 机器人的 robots.txt，用的还是你已有的那个文件和那套语法，变的只是令牌清单。按意图来组织规则，它们就能比厂商名单活得更久。如果你反对的是模型训练，那就拦截训练类令牌，放过索引类的：

# Block training, keep AI search indexing
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

如果你想向表中列出的每一个令牌发出全站退出信号，把它们归到同一条规则下即可，没必要把 Disallow 重复十一遍：

# Send a site-wide opt-out signal to named AI tokens
User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: OAI-AdsBot
User-agent: ClaudeBot
User-agent: Claude-User
User-agent: Claude-SearchBot
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Google-Extended
User-agent: CCBot
Disallow: /

但这仍然不是一道通用的封锁。Anthropic 对 Claude-User 应用 robots.txt，可 OpenAI 说规则可能不适用于 ChatGPT-User，而 Perplexity-User 通常直接忽略。如果这些由用户触发的抓取必须被真正拦下、而不只是被劝退，那就把这个决定落到反向代理或 WAF 上。

Google-Extended 是最常被误解的令牌，而如果搜索流量是你的收入来源，这个区分就至关重要。 Google 的爬虫文档 把它描述为一个独立的产品令牌，用于控制被抓取的内容能否用于搜索之外的 Gemini 训练与信息接地，并说明它不影响网站在 Google 搜索中的收录或排名。拦截它，完全不会触及 Googlebot 的搜索行为。

靠手工维护一份令牌清单，不算是个划算的下午。 由社区维护的 ai.robots.txt 仓库 会跟踪 AI 的 user agent，并为 robots.txt、nginx、Caddy、HAProxy、Lighttpd 和 Apache 生成配置。使用 Apache 的运维可以把生成的配置块放在自己其他的 目录级 .htaccess 规则.

小贴士： 别信 user-agent 字符串。它只是一个头部字段，而伪造头部是不要钱的。 Common Crawl 的 CCBot 文档 警告说，有爬虫谎称自己是 CCBot。对 IPv4，请用正向确认的反向 DNS 在以下域名下进行验证： *.crawl.commoncrawl.org至于 IPv6，请改用 Common Crawl 公布的 IP 网段，因为那边目前还不支持反向 DNS。上文提到的各厂商页面同样公布了其他具名爬虫的当前 IP 网段。这是这几家厂商有文档可依的验证途径，而不是 AI 爬虫的普遍属性。

llms.txt 到底有用吗？

以目前的证据看，几乎没有作用。llms.txt 是一份被提议放在网站根目录的纯文本文件，向语言模型提供一份经过整理的内容摘要。发布它成本很低，但现有证据几乎没给你投入其中的理由，而谷歌的文档也说，它的 AI 搜索功能并不需要这个文件。

这个格式极其简单。 llms.txt 提案 始于 2024 年 9 月，文件位于 /llms.txt，并且唯一必需的部分只有一个写着站点名或项目名的 H1 标题。

结论来自实测数据。 Ahrefs 覆盖 137,210 个域名的研究 发现被测域名中有 28% 发布了 llms.txt 文件，而这些文件里有 97% 在 2026 年 5 月一次请求都没收到。在确实到达的请求中，19.5% 来自有名有姓的 AI 工具。Ahrefs 还提醒，被抓取过并不能证明文件真的被使用了。

我对这批数据的解读是：llms.txt 是在押注一项约定，而它所面向的那些系统并没有广泛采纳。你要是喜欢干净整齐的根目录，那就发布吧。但别围绕它搭一条生成流水线，别让它变成部署里的阻塞步骤；谁要是把它当作排名或引用的杠杆卖给你，那就当他跑在证据前面相当远。

核心要点: 在 Ahrefs 的研究中，已发布的 llms.txt 文件有 97% 在 2026 年 5 月完全没有收到请求。

让你的页面对机器可读

Vercel 对爬虫的测量 发现 OpenAI 的各个爬虫、ClaudeBot、PerplexityBot、Meta-ExternalAgent、Bytespider 和 CCBot 都不执行 JavaScript，而经由 Googlebot 的 Gemini 和 AppleBot 会执行。对不渲染的爬虫来说，只有在客户端 hydration 之后才出现的内容是完全看不见的，所以关键内容一律在服务端渲染。标记是个更容易回答的问题，而谷歌自己在这方面的指引直白得反常：

"你不需要为了出现在这些功能里而创建新的机器可读文件、面向 AI 的文本文件或标记。也不存在什么必须添加的特殊 schema.org 结构化数据。"

Google Search Central 的 AI 指引

有人为 FAQ schema 辩护时常引用的 40% 曝光提升，出自 GEO 论文 ，该论文被 KDD 2024 接收。论文报告的提升幅度确实可达 40%，但它测试的干预手段集中在内容层面的改动，比如引用来源、直接引语、统计数据、专业术语和流畅措辞，而不是 FAQPage 或任何其他 Schema.org 标记。这个数字没错，错的是把它挂到 schema 标记上。

在结构化数据支撑传统搜索功能、并且与可见页面相符的地方保留它。谷歌表示，进入其 AI 功能的资格走的是普通搜索索引这条路，并没有单独的标记要求。只是，没有证据显示它能撬动 AI 的引用。

当 robots.txt 不够用时：在服务器上做限速与 WAF

指令只对愿意配合的机器人有效。在 同一条 Hacker News 讨论里，好几位运维描述了那些不配合的流量：爬虫把请求分散到大量 IP 段上，并轮换 user agent 让自己看起来像普通访客，这同时让简单的按 IP 限速和按 user agent 匹配都失了效。请把这些当作社区的经验之谈，帖子里没有人拿出实测数据。但它描述的，正是 robots.txt 从来就够不着的那群对象。

在爬上这架梯子之前，对那些还愿意配合的流量，还有一招更便宜的：把它放慢。

User-agent: ClaudeBot
Crawl-delay: 1

小贴士： 先限速，再谈封锁。Anthropic 的文档 支持为 ClaudeBot 设置 Crawl-delay ，于是你可以把一个吃资源但守规矩的爬虫放慢，同时把它留下。同一页面还指出，封 IP 并不是一种持久的退出机制。这两点都只针对 Anthropic； Crawl-delay 并不是一条通用指令，所以请先查阅各家厂商自己的文档。

再往后，就都是你自己运行的强制手段了，分为三级，成本和效果同步递增。每一级都换来一些东西，也让出一些东西。

第 1 级：反向代理指令与限速

AI 爬虫限速要从反向代理开始，它是你技术栈里第一个看到请求的环节，能在应用或数据库开始干活之前就把请求放慢。 NGINX 的限速文档 指出，键为空的请求不会被计数，因此一段 map 可以只给你想限速的那些爬虫令牌分配限速键，而让未命中的请求落在 limit_req_zone.

# /etc/nginx/nginx.conf, inside the http block
map $http_user_agent $ai_rate_key {
    default              "";
    ~*GPTBot             $binary_remote_addr;
    ~*OAI-SearchBot      $binary_remote_addr;
    ~*ClaudeBot          $binary_remote_addr;
    ~*Claude-SearchBot   $binary_remote_addr;
    ~*PerplexityBot      $binary_remote_addr;
    ~*CCBot              $binary_remote_addr;
}

limit_req_zone $ai_rate_key zone=ai_slowlane:10m rate=20r/m;

# /etc/nginx/sites-available/example.conf, inside the server block
location / {
    limit_req zone=ai_slowlane burst=10 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

需要调的是这一对参数： burst=10 nodelay。超过平均速率的请求可以立刻消耗掉 burst 额度，而再超出的请求默认会收到 503 。设得太紧，你会把一个正常的爬虫在抓取途中弹掉，而这种问题比一次宕机更难排查。Caddy 用一个 matcher 和一个 handler 表达同样这两个概念；如果你正在两者之间做选择，那么 把配置文件并排对照 ，比一个合成的吞吐量数字更有参考价值。

这一级的局限在于，慢车道仍然依赖对方声明的 user agent。一个披着 Chrome user agent 的采集器会完全绕开这个针对爬虫的键；要抓住那类流量，需要基于 IP 或路径行为的更宽泛限速，或者下面那一级的 WAF。

第 2 级：自己运行的 Web 应用防火墙

WAF 把判断依据从单个头部字段，挪到一套同时读取请求模式、路径和速率的规则上——当流量不再自报家门时，你要的正是这个。把它跑在自己的机器上，规则和日志就都留在自己的磁盘里，凌晨三点你也能直接 grep。 BunkerWeb 就是这样一个项目， SafeLine 是另一个。只要主机满足项目对架构和资源的要求，两者都能跑在 VPS 上；我们为两者都提供了一键版本，替你省去安装步骤——尽管打包本身并不是有意思的部分。

这也正是这一级的代价。规则需要维护，而一条紧到足以逮住铁了心的采集器的规则，早晚会逮到真人。SafeLine 的 Monitor、Balanced 和 Strict 三种模式 把这个取舍摆到了明面上：先观察流量足够长的时间、找出误报，再让 WAF 自动返回 403。

第 3 级：工作量证明质询

Anubis 干脆绕开了身份识别这个难题。对于你选中要发起质询的流量，它会让请求在源站响应之前先付出一点计算成本。它的 策略系统 还能按匹配规则对请求执行放行、拒绝或质询。 项目的 README 把它称作一个围绕质询构建的 Web AI Firewall Utility，用于保护上游资源不被采集机器人消耗。它无需每个机器人都如实表明身份就能起作用。

项目自己就把这种做法称为核弹式回应，这份保留是有道理的。这笔税会落到你的策略所质询的任何流量头上——如果规则太宽，就可能包括用慢设备的真人，或者正常的爬虫。把这一级留作后手，专门对付真正怀有敌意的流量。一个过于热情的爬虫，通常只是限速问题，而限速你已经有了。

为突发流量做容量规划

爬虫负载往往成阵而来，但它究竟是吃 CPU、吃数据库还是吃 I/O，取决于应用本身和被抓取的 URL。在上文那个 WordPress 的例子里，运维把一秒钟页面耗时的大部分追溯到了 MySQL——所以那次具体事件，是一场披着流量问题外衣的数据库瓶颈。

这就把容量规划变成了一道资源分配题，而且是道让人不舒服的题：余量是持续在花钱，却只有在你控制不了的那次尖峰里才对得起这笔钱。但还是照着尖峰去准备吧。如果 BunkerWeb 和应用、数据库共用一台主机，别把 8 GB 当成整套技术栈的推荐配置。 BunkerWeb 的快速上手指南 建议：测试环境或服务数量很少的部署用 2 vCPU、8 GB 内存；保护大量服务的生产环境则至少 4 vCPU、16 GB 内存。在此之上，还要再加上应用自身的 CPU 峰值、数据库内存和 I/O 余量。

当请求处理或查询执行卡在 CPU 上时，主频更高的核心有帮助；当你需要同时推进更多工作时，核心数更多才有帮助。请依据峰值并发、p95 响应时间、数据库 CPU 与 I/O 等待，以及缓存未命中率来定规格，而不是只看爬虫流量。

自己运行这一层，对底下那台机器提出了两个要求：一是 root 权限，因为上面每一种机制说到底都是一个你要编辑的配置文件和一个你要重启的服务；二是足够的余量，好让规则干活的时候，一波突发流量不至于把站点压垮。如果你正为此挑选或迁移一台机器，我们的 Linux VPS 能提供这套技术栈所需的 root 权限，也让你在敲定长期规格之前，先把代理加 WAF 的配置跑一遍试试。

在拥有 root 权限、NVMe 与 AMD EPYC 强大性能的 Linux VPS 上构建应用。

查看 Linux 套餐

Cloudflare 针对 AI 流量的新默认设置

Cloudflare 在其 2026 年 7 月的 AI 流量公告。自 2026 年 9 月 15 日起，新接入 Cloudflare 的域名在展示广告的页面上，Training 和 Agent 两类默认被拦截，Search 仍然放行。现有客户可以提前更改该设置，且这些控制项在各档套餐中都可用。

值得借鉴的，是 Cloudflare 在自家公告里点明的那个麻烦。按它的分类，Googlebot、Applebot 和 Bingbot 都同时承担搜索与训练两种工作，因此拦掉 Training 这一类的客户，也把这些爬虫一并拦掉了——连带那份他们本想保留的搜索行为。任何把多用途爬虫当成只有单一职责来处理的类别级控制，都埋着同一个陷阱。

如果你的站点不在 Cloudflare 后面，这里没有哪一条是你能拉动的杠杆。但还是要知道它要来了，因为九月流量的分布会因此变动；你手上的手段，依旧是 robots.txt 里的令牌，以及上文那一层代理。

WebMCP：值得关注，但还不值得为它动工

WebMCP 是 Model Context Protocol 在浏览器一侧的对应物，后者是让智能体调用结构化工具、而不是靠猜的一套约定。Chrome 的 WebMCP origin trial 公告 把目标说得很直白：与其让智能体去猜某个按钮或表单字段是干什么的，不如让网站直接暴露结构化的函数和带注解的控件，供智能体直接调用。

这是第一次像样地尝试让智能体在你的站点上除了阅读还能做点别的，也因此是本文里最有意思的一部分。它同时也还处于实验且未完成的状态：2026 年 6 月开放的 Chrome 149 origin trial。盯着规范就好。先别围绕它上线生产依赖，也别把它算进容量规划里。

常见问题

User-agent: GPTBot
Disallow: /

grep -ohE 'GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot|ChatGPT-User' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn