放行 AI 爬虫：robots.txt、GPTBot，以及真正能证明放行的检查

简答：答案引擎无法引用它抓不到的页面，所以 AI 爬虫访问是 GEO 里唯一一个「前提」而不是「优化项」的部分。要分开做两个决定，一个关于训练，一个关于回答：你完全可以封锁训练爬虫，同时放行那些让你出现在回答里的搜索代理和用户触发代理。然后用各代理的真实 User-Agent 去请求真实页面来证明访问通畅，因为 robots.txt 写着放行，并不说明真的有东西能进来。

本指南依次讲：哪些代理干哪种活，一份把两个决定都写进去的 robots.txt，这个文件在 Shopify、WordPress、Webflow、HubSpot 上分别在哪里改，为什么读文件证明不了任何事，真正能证明访问的探测怎么做，以及怎样防止访问在一个月后又悄悄坏掉。

AI 爬虫访问是两个决定，不是一个

AI 公司运行的各个代理职责不同，厂商也是分开写文档的。有的收集可能用于训练模型的内容；有的构建助手回答时要检索的索引；有的只在有人刚问到某个页面时才去抓取它。还有几个根本不是爬虫，而是一种控制项，管的是别的爬虫抓到的内容可以怎样使用。

多数站点只做了一个决定，然后套用到每一行上，通常还是无意的，因为这些代理在同一个文件里挨着排。很多站点本想拒绝训练，误封的却是 OAI-SearchBot。把「训练」和「回答」两个决定交叉起来，会得到四种立场，而一家想被 AI 推荐的企业真正想要的，通常只有其中一种：

右上那一格值得多看一眼，因为没人审过的 robots.txt 最常落在这里。典型的经过是：有人觉得 OAI-SearchBot 这个名字听起来像采集器，就把它封了；而真正的训练爬虫 GPTBot 文件里一个字都没提，于是按 * 分组继续放行。结果和所有人的本意正好相反：内容照样可以拿去训练，网站却从 ChatGPT 的搜索回答里消失了。要发现这种问题，办法只有一个：一个分组一个分组地读文件，并在每一行旁边写清楚这个代理干的是哪种活。

要有意识地逐行做决定，动文件之前先写下你选的是哪一格。完整名单、各厂商的用途说明和封锁代价，见我们的 AI 爬虫名单。

把两个决定都写进 robots.txt

下面这个文件，对 OpenAI 和 Anthropic 这两家有独立训练爬虫的厂商退出训练，同时保留出现在它们回答里的资格。按你自己的立场调整；关键在于每个代理都有一个明确的决定。

# 训练：退出
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

# 可选：退出 Gemini 训练，但也会从 grounded 的 Gemini 回答中消失
# User-agent: Google-Extended
# Disallow: /

# 搜索与回答：放行
User-agent: OAI-SearchBot
Allow: /
Disallow: /admin/

User-agent: Claude-SearchBot
Allow: /
Disallow: /admin/

User-agent: PerplexityBot
Allow: /
Disallow: /admin/

# 用户触发抓取：放行
User-agent: ChatGPT-User
User-agent: Claude-User
Allow: /
Disallow: /admin/

User-agent: *
Disallow: /admin/

注意 /admin/ 在每个具名分组里都重复写了一遍。爬虫一旦找到点了自己名字的分组，就只遵守那个分组，完全忽略 * 分组；只写在 * 下面的私有路径，对你点名放行的每个代理都是敞开的。「放行 AI 搜索」的改动意外打开后台目录，最常见就是这么来的。

Google-Extended 是特意注释掉的。取消注释，表示你的内容退出 Gemini 训练，Google 搜索不受影响，但你也会从 grounded 的 Gemini 回答里消失。只有当训练问题对你比出现在 Gemini 回答里更重要时，才启用它。这些取舍在怎样封锁 GPTBot 又不从回答里消失里有详细讨论。

有两个引擎没法按名字处理。xAI 没有公开文档化的爬虫 User-Agent，所以无法按名字放行或封锁 Grok；我们也没能在微软公开的站长文档里核实到 Copilot 专属的爬虫。对这两者，你能控制的只是页面对通用抓取是否可读。

各平台上，这个文件在哪里改

手工搭的网站，robots.txt 就是 Web 根目录里的一个文件。托管平台上，它要么是自动生成的，要么是后台里的一个设置项，而且每家的起点都不一样：

不管用哪个平台，都要审计你线上自定义域名实际返回的那份文件，而不是编辑器里的、或预览地址上的那份。

为什么读 robots.txt 证明不了 AI 爬虫能否访问

robots.txt 是守规矩的爬虫会遵守的一份声明。它既不是强制手段，也不是代理与你页面之间唯一的关卡。有三件事让它成了不可靠的证人：

1. 文件之下的封锁。robots.txt 写着放行，前面却有 CDN 规则、机器人管理产品或防火墙对这些代理返回 403，实际上就是封锁，而这个文件会一直宣称相反的事。
2. 空响应。多数 AI 爬虫不执行 JavaScript。页面返回 200，但内容靠客户端渲染，代理拿到的就是空壳。所以返回 200 但正文为空要算失败，不能算通过。修法见JavaScript 渲染与 AI 爬虫。
3. 用户触发的代理。OpenAI、Anthropic、Perplexity 和 Meta 都说明过，它们的用户触发代理可能不像爬虫那样遵守 robots.txt，因为请求来自真人。robots.txt 表达的是你的意向，管不住访问。

真正能证明 AI 爬虫访问通畅的检查

用你在意的每一个 User-Agent 去请求一个真实的内容页，记录状态码和响应大小，并在正文里搜一句你确定在页面上的话：

URL="https://example.com/guides/returns-policy/"
PHRASE="refund"
for UA in "OAI-SearchBot" "ChatGPT-User" "PerplexityBot" \
          "Claude-SearchBot" "Claude-User" "Mozilla"; do
  BODY=$(curl -s -A "$UA" -w "\n%{http_code}" "$URL")
  CODE=$(echo "$BODY" | tail -n1)
  HIT=$(echo "$BODY" | grep -ci "$PHRASE")
  echo "$UA  status=$CODE  phrase_hits=$HIT  bytes=${#BODY}"
done

输出的每一行，都按同样的三个问题、同样的顺序去读：

循环里最后那个浏览器风格的普通 User-Agent 是对照组，所以它排在第一问。没有它，一个单纯宕机的站点和一个封锁 AI 代理的站点看起来一模一样。「没抓到」只能记为未知，绝不能记成「不存在」。要拿内容页去测，不要只测首页，因为真正回答买家问题的页面，往往才是跑在框架后面的那些。

伪造 User-Agent 测的是你自己的规则，不是厂商的真实流量。边缘层还可能按连接来源识别已知代理，所以你的探测结果和真实爬虫的遭遇对不上时，应该当成去 CDN 日志里追查的线索，而不是最终结论。要确认一个自称是 OpenAI 代理的请求是否真的来自 OpenAI，就把它的来源地址和厂商公布的 IP 列表对照，例如 OAI-SearchBot 的 IP 列表。

别让 AI 爬虫访问悄悄坏掉

在造成封锁的那一层修复它，而那一层往往不是 robots.txt。然后定期复查，因为代理和你的内容之间的每一层，通常归不同的团队管，而且会因为跟 AI 毫不相干的理由发生变化：

归属这么分散，正是访问会悄悄坏掉的原因。安全团队在一次不相关的事件之后收紧了机器人规则；前端重构把商品文案挪进了客户端组件；某家厂商又记载了一个新代理。参与其中的人没有一个在想答案引擎，你的分析工具也不会对这些变化报警。每一个结果旁边都写上检查日期：爬虫访问不是一次达成就一劳永逸的状态。代理名单本身也会变；本文依据的名单在 2026-09-09 对照各厂商文档核对过。如果你希望这套带浏览器对照组的探测能自动跑，我们的 AI 可抓取性检查做的就是这件事。

资料来源

• OpenAI：爬虫总览，IP 列表如 searchbot.json
• Perplexity：爬虫说明
• Anthropic：站长如何封锁爬虫
• Google：常见爬虫
• Meta：网页爬虫
• Shopify：robots.txt.liquid、WordPress：do_robots()、Webflow：设置 robots.txt 规则、HubSpot：自定义 robots.txt