面向 AI 爬虫的 robots.txt：2026 完全指南

简短的答案

不要再把“AI 机器人”当成一个整体来看待。它们分为三类，经济逻辑完全不同，而对这三类一视同仁地写上一行 Disallow，几乎总是错误的取舍。

训练爬虫是在请求从你的产品目录中学习。检索索引器是在请求获得引用它的能力。用户触发抓取器则是一位客户，此时此刻，正在询问你的产品。屏蔽第一类是一项授权决策。屏蔽第三类等于直接挂断电话。

Forrester 发现，94% 的企业采购者在最近一次采购过程中使用了 AI。以 AI user-agent 命中你源站的抓取请求中，有相当一部分并不是在扒数据——而是某个人正开着一份物料清单，处在决策中途。你的 robots.txt 应该把它们区分开，而大多数网站并没有做到。

2026 年真正重要的每一个 AI 用户代理

上面这张表里有五点经常被误解或者被漏掉，值得明确说清楚。

`Google-Extended` 和 `Applebot-Extended` 不是爬虫。 这两者都不抓取任何东西。它们是授权令牌：Google-Extended 控制的是 Googlebot 已经抓到的内容能否用于训练 Gemini、以及能否作为其回答的事实依据；Apple 的文档也明确写道，Applebot-Extended“不抓取网页”，而是“仅用于决定如何使用 Applebot user agent 已抓取的数据”。对 Applebot-Extended 设置 Disallow，并不会把你从 Siri、Spotlight 或 Safari 的结果中移除。

在用户触发抓取这件事上，Anthropic 是个例外。 OpenAI 声明，对于 ChatGPT-User，“由于这些动作由用户发起，robots.txt 规则可能并不适用”。Perplexity 表示 Perplexity-User“通常会忽略 robots.txt 规则”。Google 的文档在谈到自家用户触发抓取器时写道：“由于抓取是由用户请求的，这些抓取器通常会忽略 robots.txt 规则”。Amazon 则称 Amzn-User“可能不会遵循全部 robots.txt 指令”。与之相反，Anthropic 在文档中说明其机器人遵守 robots.txt，并点名 Claude-User 是站点所有者可以用来控制用户发起请求的令牌。如果你把这一整组全部 Disallow，真正会停下来的偏偏是 Claude——这与大多数人的本意恰好相反。

Amazon 和 Meta 各自运行着一支分工不同的机队。 除 Amazonbot 之外，Amazon 还记录了 Amzn-SearchBot（用于包括 Alexa 与 Rufus 在内的搜索体验）和 Amzn-User（实时的用户操作），并称这两者都不会为生成式 AI 训练而抓取。Meta 用 Meta-ExternalAgent 做训练与索引，用 Meta-ExternalFetcher 处理用户请求的抓取，后者可能会绕过 robots.txt。

Bytespider 是政策问题，不是 robots.txt 问题。 ByteDance 声称自己尊重 robots.txt；站点运营者却普遍反映情况并非如此。如果你想拦住它，就在边缘拦，别指望这个文件。

关于 `Gemini-Deep-Research` 的一点说明： Google 已公布的爬虫文档尚未把这个令牌列入常见爬虫或用户触发抓取器名单，但它已经在实际使用中，而且主要分销商已经按名称对它做了处理——Digi-Key 的 robots.txt 明确放行了 Google-Extended 和 Gemini-Deep-Research，同时放行的还有 GPTBot、ChatGPT-User、OAI-SearchBot、PerplexityBot、Perplexity-User、ClaudeBot、Claude-User 和 Claude-SearchBot。把它加进去；robots.txt 里出现一个无法识别的令牌是无害的。

屏蔽每一类分别要付出什么代价？

对于产品目录本就公开、并且已经在各聚合平台被镜像的制造商或分销商来说，屏蔽训练类基本上只是象征性动作：数据无论如何都会通过分销商的产品列表和 Common Crawl 抵达模型。真正改变的，是模型手里握着的是谁的那一份数据。而对公开产品目录来说，屏蔽另外两类完全没有任何好处。

可直接复制粘贴的 robots.txt

方案 A：最大化代理可见度

对于产品目录公开、商业利益在于被发现并被准确引用的制造商或分销商，这是正确的默认选择。

# --- Answer engines and user-triggered fetchers ---
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Gemini-Deep-Research
User-agent: Amzn-SearchBot
Disallow: /account/
Disallow: /cart/
Disallow: /checkout/
Allow: /

# --- Training crawlers and permission tokens ---
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: CCBot
User-agent: Meta-ExternalAgent
User-agent: Amazonbot
User-agent: Google-Extended
User-agent: Applebot-Extended
Disallow: /account/
Disallow: /cart/
Disallow: /checkout/
Allow: /

# --- Everything else ---
User-agent: *
Disallow: /account/
Disallow: /cart/
Disallow: /checkout/

Sitemap: https://www.example.com/sitemap.xml
Sitemap: https://www.example.com/sitemap-products.xml

方案 B：允许检索，拒绝训练

适用于那些已经明确决定不为模型训练做贡献、但仍希望被发现和被引用的组织。请注意它的代价：对 Google-Extended 设置 Disallow，会让你的内容不仅退出训练，也退出 Gemini 回答的事实依据。

User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Gemini-Deep-Research
Allow: /

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: CCBot
User-agent: Bytespider
User-agent: Meta-ExternalAgent
User-agent: Amazonbot
User-agent: Google-Extended
User-agent: Applebot-Extended
Disallow: /

User-agent: *
Disallow: /account/

方案 C：目录开放，其余一律关闭

当产品目录和文档库才是你想被呈现出来的资产、而站点其余部分只是噪声时，这个方案很有用。

User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: ClaudeBot
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Gemini-Deep-Research
Disallow: /
Allow: /products/
Allow: /catalog/
Allow: /datasheets/
Allow: /documents/
Allow: /sitemap-products.xml

按照 RFC 9309，匹配路径最长的规则优先，所以对这些前缀而言，Allow 行会覆盖那条一刀切的 Disallow: /。不要想当然，务必去验证实际结果——各家解析器在边界情况下的行为仍然存在差异。

把“不”说得有分量：Content Signals

robots.txt 控制的是访问。一旦字节已经发出去，它对使用方式就无话可说了。Cloudflare 于 2025 年 9 月 24 日推出的 Content Signals Policy，在同一个文件中加入了机器可读的使用偏好，共有三个信号：search（构建搜索索引并提供搜索结果）、ai-input（把内容输入一个或多个 AI 模型）以及 ai-train（训练或微调 AI 模型）。

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Disallow: /account/

Cloudflare 已对超过 380 万个启用了其托管 robots.txt 的域名应用了 search=yes, ai-train=no，并刻意没有设置 ai-input，而不是替用户去猜。它是一种表明的偏好，不是强制执行机制——但它是一份清晰、有日期、机器可读的意图声明，值得拥有。

为什么“沉默”正在变成“不”

二十年来，robots.txt 里没有相关规则就意味着“可以”。这一默认正在基础设施层被收回，而那些从未碰过这个文件的制造商，正被自己的 CDN 替他们选择了退出。

• 2025 年 7 月 1 日 —— Cloudflare 成为第一家默认屏蔽 AI 爬虫的主要基础设施提供商（它大约挡在全网五分之一的流量前面），并会在每一个新接入的域名上先行询问是否允许它们。
• 2025 年 9 月 24 日 —— Content Signals Policy 上线，ai-train=no 被默认应用到 380 万个托管域名上。
• 2026 年 7 月 1 日 —— Cloudflare 宣布，自 2026 年 9 月 15 日起，在新域名、现有客户的新站点以及所有现有免费套餐客户上，展示广告的页面将默认屏蔽 Training 与 Agent 两类爬虫。Search 仍然放行。同时混合了 Search 与 Training 用途的多用途爬虫，将继承最严格的那条规则。

最后这一条要读准确，因为它被广泛误引。它的适用范围仅限于投放广告变现的页面，而大多数制造商的产品目录并不属于这一类。真正已经在影响你的是 2025 年那一条：如果你的站点是近期才接入某个现代 CDN 的，或者跑在免费套餐上，那么你可能在没有任何人做过决定的情况下，就已经在拒绝 AI 爬虫了。别想当然，先去查。

robots.txt 是请求，你的 WAF 才是执行

绝大多数出于好意的配置都栽在这一步。robots.txt 是一份自愿协议，只有守规矩的客户端才会去读它。你的机器人管理系统才是硬关卡，它按已验证的来源 IP 分类，而默认规则集通常会对任何不像浏览器的东西发起挑战或者直接拦下。一个读到 Allow: / 之后却收到 JavaScript 挑战的爬虫，就是被拦住了，不管文件里写了什么。

每一家主要运营方都会公布自己的 IP 段，方便你正确地做白名单放行：

要检查日志里的某个具体地址是不是真的属于 OpenAI：

python3 - <<'EOF'
import ipaddress, json, urllib.request
probe = ipaddress.ip_address("132.196.86.5")
data = json.load(urllib.request.urlopen("https://openai.com/gptbot.json"))
nets = [ipaddress.ip_network(p.get("ipv4Prefix") or p.get("ipv6Prefix"))
        for p in data["prefixes"]]
print(any(probe in n for n in nets if n.version == probe.version))
EOF

三条边缘规则就能覆盖其中的大部分情况：

1. 01在你的机器人评分规则触发之前，先放行已验证的 IP 段，并且只限定在公开的产品目录和文档路径上。
2. 02让这些路径免于 JavaScript 挑战和限流。 非浏览器客户端解不了挑战，而一个要索引 40,000 个 SKU 的爬虫，一定会撞上为人类调校的速率限制。
3. 03不要按 user-agent 字符串做白名单。 那是一个自由文本头部。先按 IP 匹配，再选择性地叠加 user-agent。

记住，每一个源都要单独配置。你的产品站点、文档子域名和 CDN 主机名，各自都需要自己的 robots.txt 和自己的 WAF 策略。

我如何从日志里验证它真的生效了？

没有在日志里验证过的配置，只是一个假设。下判断之前请留出几天：运营方会缓存 robots.txt，Meta 的文档提示变更最长可能需要 24 小时才会生效，而 Amazon 则表示其爬虫可能使用最近 30 天内缓存的副本。然后：

grep -aiE "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|Gemini-Deep-Research|Applebot|Amazonbot|Bytespider|CCBot|Meta-External" access.log | wc -l

然后按代理和状态码拆开看——这才是真正重要的数字：

awk '/GPTBot/ {print $9}' access.log | sort | uniq -c | sort -rn

你要找的是：

1. 01每个代理都有非零的访问量。 在一个公开产品目录上，72 小时内没有任何 AI 代理发来请求，说明你是在上游被拦住了，而不只是没人搭理。
2. 02以 2xx 为主的状态码分布。 满屏 403 意味着 WAF 正在压过 robots.txt。满屏 404 意味着你的 sitemap 或站内链接指向了已经不存在的 URL。
3. 03文档路径也要出现，而不只是产品路径。 如果 /datasheets/ 从来不出现，说明你的技术资料库是隐形的。
4. 04响应体积要说得通。 产品 URL 上反复出现 4–15 KB 的 200 响应，通常意味着爬虫收到的是一个空的客户端渲染外壳——技术上被允许，实际上毫无用处。
5. 05用户触发类代理到底有没有出现。 ChatGPT-User、Claude-User 和 Perplexity-User 的流量，是你能拿到的最接近实时买家意向的信号，值得单独做成报表。

常见错误

• 在一条针对训练爬虫的一刀切规则里，顺手误伤了用户触发抓取器。
• robots.txt 配对了，WAF 却原封不动。这是两个开关，必须都拨到位。
• 忘了文档子域名、DAM 和 CDN，而按 RFC 9309，它们各自都是独立的源。
• 不让爬虫访问 CSS 和 JavaScript 资源。这对纯文本爬虫无所谓，但 Googlebot 和 Applebot 都会渲染页面，断了它们的资源就会劣化它们看到的内容。
• 想当然地以为聚合平台准确地承载着你的数据。它承载的只是它抓到的那一版，以及它抓取时的那个时间点。
• 把 llms.txt 当成替代品。没有任何主要运营方承诺读取它，日志也普遍显示它从来没有被请求过。

2026 年 8 月，Partsgraph 审计了全球 984 个分销商与制造商域名，覆盖北美、欧洲和亚洲。其中只有 19% 发布了任何形式的明确 AI 爬虫政策——而在这些站点当中，屏蔽某个主要 AI 爬虫的数量，比主动邀请其抓取的多出一倍以上。没有一家对外提供 MCP 端点。AI 可见度得分的中位数是 100 分中的 50 分。这一差距目前还谈不上竞争激烈——而这恰恰说明，一份写得规范的 robots.txt，仍然是产品数据团队可以投入的、杠杆率最高的几小时工作之一。

用 Partsgraph 的免费评分工具在 [/audit](/audit) 上看看，AI 爬虫在你的域名上究竟能访问到什么。