robots.txt 如何管理 AI 爬虫:屏蔽训练、放行搜索

AI 爬虫按训练、搜索、用户触发三类拆分,可分别放行或屏蔽,本文给出对照表与 robots.txt 模板。
AI 爬虫并非单一行为,而是按用途分为训练(GPTBot、ClaudeBot、CCBot)、搜索(OAI-SearchBot、Claude-SearchBot、PerplexityBot)和用户触发(ChatGPT-User、Claude-User)三类,各自拥有独立 User-agent,可在 robots.txt 中单独放行或屏蔽。文章梳理了 OpenAI、Anthropic、Google 等厂商的爬虫对照关系,指出 Google-Extended 只是训练令牌、不影响 Google 搜索收录。作者建议多数站点屏蔽训练类、放行搜索类,并提醒 robots.txt 只控制抓取而非索引、不提供隐私保护。文末提供可直接套用的模板、验证方法与五个常见错误。
AI 爬虫已经不再是单一的"抓取"行为。同一家公司可能同时派出训练采集器、搜索索引器和用户触发的实时抓取器,它们在 robots.txt 里对应不同的 User-agent 名称。这意味着站点所有者可以做出比"全允许"或"全屏蔽"更精细的选择。本文基于开发者 Amrendra 在 Dev.to 上发布的配置指南,梳理 AI 爬虫的分类逻辑、各主流厂商的 User-agent 对照关系,以及一份可直接套用的 robots.txt 模板。
AI 爬虫分为三类:训练、搜索与用户触发
理解 AI 爬虫的第一步是放弃"AI 爬虫"这个笼统标签。按用途划分,它们至少有三类:
- 训练爬虫:为 LLM 收集训练语料,代表有
GPTBot(OpenAI)、ClaudeBot(Anthropic)、CCBot(Common Crawl)。 - 搜索爬虫:为 AI 搜索产品提供索引,让 AI 在回答中展示并引用你的链接,代表有
OAI-SearchBot、Claude-SearchBot、PerplexityBot。 - 用户触发抓取:当真实用户在聊天窗口里询问某个网址时,AI 才会去抓那一页。OpenAI 的
ChatGPT-User和 Anthropic 的Claude-User属于这一类。
三类爬虫的 User-agent 名称彼此独立,因此可以单独放行或屏蔽。这也是全文的核心前提:不要按"AI"这个类别做决定,要按 bot 逐个决定。
robots.txt 与 User-agent 机制
robots.txt 是放置在网站根目录(如 https://example.com/robots.txt)的纯文本文件,遵循 1994 年提出的 Robots 排除协议(REP)。它通过 User-agent 字段声明规则适用于哪个爬虫,通过 Allow 与 Disallow 指定允许或禁止抓取的路径,并可用 Sitemap 指向站点地图。
理解全文的关键在于:User-agent 匹配是逐条独立的。当爬虫访问站点时,会先找到 robots.txt,再寻找与自己 UA 名称完全匹配的规则组;没有匹配时才回退到 User-agent: * 通配规则。因此 GPTBot、OAI-SearchBot、ChatGPT-User 虽然是同一家公司派出,却可以被分开处理。
需要强调的是,robots.txt 是自愿遵守的约定,没有法律或技术强制力。Google、OpenAI 等主流厂商会遵守,但恶意爬虫可以完全无视。此外,它只控制“是否抓取”,不控制“是否索引”——被禁止抓取的 URL 若被其他站点链接,仍可能出现在搜索结果中(通常只显示链接而无摘要)。
该不该屏蔽 AI 爬虫?
作者的建议是:只在有明确理由时才屏蔽。他列出了三种常见情形——不希望自己的内容被用于模型训练、爬虫流量造成服务器负担或产生无法承受的带宽成本、内容属于付费或授权内容。
但屏蔽有代价。如果你希望出现在 ChatGPT 等 AI 搜索的回答里,就必须放行搜索类爬虫。一刀切地 Disallow: / 会把搜索可见性一起关掉。
这里有一个容易被混淆的概念:robots.txt 控制的是抓取,不是索引,也不是隐私保护。它本质上是一份"礼貌请求",恶意爬虫完全可以无视。想阻止页面出现在搜索结果中,应该用 noindex(前提是页面可被抓取,否则 Google 看不到这个标签)或登录墙。

GPTBot 与 OAI-SearchBot:训练和搜索能分开吗?
能。OpenAI 官方文档明确说明各个设置相互独立:OAI-SearchBot 负责让站点出现在 ChatGPT 搜索中,选择退出的站点不会出现在 ChatGPT 搜索的回答里。
据 OpenAI 文档整理,各主流厂商的 AI 爬虫对照关系如下:
| Bot | 厂商 | 用途 | 屏蔽它意味着 |
|---|---|---|---|
GPTBot | OpenAI | 训练 | 拒绝训练使用 |
OAI-SearchBot | OpenAI | 搜索结果 | 放弃 ChatGPT 搜索曝光 |
ChatGPT-User | OpenAI | 用户触发抓取 | OpenAI 指出 robots.txt 可能不适用于此 |
ClaudeBot | Anthropic | 训练 | 拒绝训练使用 |
Claude-SearchBot | Anthropic | 搜索 | 放弃 Claude 搜索曝光 |
Claude-User | Anthropic | 用户触发抓取 | 拒绝用户请求的实时抓取 |
Google-Extended | Gemini 使用 | 退出 Gemini 训练与 grounding |
这张表最有价值的信息是最后一行:Google-Extended 是一个 robots.txt 令牌,而不是一个独立爬虫。它控制的是内容是否参与 Gemini 模型训练与 grounding,不影响 Google 搜索的收录和排名。屏蔽它不会让你在 Google 搜索中消失。
Anthropic 的拆分逻辑与 OpenAI 一致:ClaudeBot 采集可能用于训练的内容,Claude-SearchBot 用于提升搜索结果质量,Claude-User 只在用户主动询问时抓取页面。这种设计让你可以退出训练、同时保留搜索曝光。
Google-Extended 的特殊性
Google-Extended 是 Google 在 2023 年 9 月引入的 robots.txt 产品令牌(product token),用于控制 Google 的 Gemini 模型训练和 grounding(即让模型引用网页内容来增强回答)。它与 Googlebot 是两个完全独立的令牌:Googlebot 负责 Google 搜索的常规抓取和收录,Google-Extended 只影响生成式 AI 用途。
这意味着屏蔽 Google-Extended 不会影响站点在 Google 搜索中的收录、排名或展示,也不需要重新提交 sitemap。对希望保住搜索流量、又不愿内容被用于 Gemini 训练的站长来说,这是一个成本极低的选项。
类似的“产品令牌”概念也出现在其他厂商:Applebot-Extended 控制 Apple Intelligence 训练,Bytespider(字节跳动)则同时承担搜索与训练用途。理解令牌与爬虫的区别,才能避免误伤搜索可见性。
哪些 AI 爬虫应该放行?
作者的取向很清晰——希望获得流量和引用的话,放行 AI 搜索爬虫。对多数博客和商业站点来说这是划算的。
- 建议放行:
OAI-SearchBot、Claude-SearchBot、PerplexityBot - 通常屏蔽:
GPTBot、ClaudeBot、CCBot、Google-Extended(如果你反对训练用途) - 交给平台决定:
ChatGPT-User、Claude-User(用户触发型)
还有一个常被忽略的技术细节:想让 AI 搜索友好地抓取你的内容,页面本身要能被机器人读全。作者提到页面应保持快速、服务端渲染、便于阅读——看不到文本的爬虫无法引用它。对重度依赖客户端 JavaScript 渲染的站点来说,这一点可能比 robots.txt 本身更影响 AI 搜索可见性。
服务端渲染(SSR)与 AI 可抓取性
AI 搜索爬虫普遍不执行 JavaScript,或只执行非常有限的脚本。它们看到的是服务器返回的初始 HTML。如果站点用 React、Vue 等框架做客户端渲染(CSR),页面正文可能在爬虫眼中是空的,无论 robots.txt 是否放行,都无法被引用。
服务端渲染(SSR)或静态站点生成(SSG)则能让完整 HTML 在首次响应中就返回,爬虫可直接读取文本、标题和结构化数据。对多数内容站来说,这是提升 AI 搜索可见性最有效的一步,优先级高于调整 robots.txt。
实践上可用 curl 或“查看网页源代码”对比:若源代码里找不到正文文本,AI 爬虫多半也看不到。次优方案是预渲染(prerender)或对爬虫 UA 返回降级页面,但维护成本较高,且需警惕被判定为 cloaking(对爬虫展示不同内容),可能招致搜索惩罚。
实践:一份可直接套用的 robots.txt 模板
在站点根目录的 https://yourdomain.com/robots.txt 中写入以下配置,即可实现"屏蔽训练、放行搜索":
**如何验证 AI 爬虫身份**
UA 字符串可以被任意伪造,因此仅凭日志里的 `GPTBot` 字样不能确认对方身份。主流厂商都公布了官方 IP 段:OpenAI 在 `https://openai.com/gptbot.json` 和 `https://openai.com/searchbot.json` 提供 JSON 格式的 CIDR 列表;Google 在 `https://developers.google.com/search/apis/ipranges/googlebot.json` 公布 Googlebot 段;Anthropic 与 Perplexity 也有类似文档。
验证流程通常为:从服务器日志提取访问 IP,做反向 DNS 查询,确认域名归属(如 `*.openai.com`、`*.googlebot.com`),再正向解析回该 IP 进行双向匹配,最后与官方 CIDR 列表比对。反向 DNS 加正向验证能防止伪造 PTR 记录。
更省事的做法是接入 Cloudflare 的 Verified Bots 或使用厂商提供的 API。验证的意义在于:只有确认对方是真正的 GPTBot,日志分析才有意义;否则优化策略可能建立在虚假流量之上。
# Block AI training crawlers
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Google-Extended
Disallow: /
# Allow AI search crawlers
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /
# Everyone else (including Googlebot)
User-agent: *
Allow: /
Sitemap: https://yourdomain.com/sitemap.xml
想屏蔽所有 AI 机器人,只需把搜索类爬虫的 Allow: / 换成 Disallow: /。OpenAI 表示搜索相关的变更大约需要 24 小时生效。
配置完成后需要验证:先在浏览器中打开 /robots.txt 确认规则,再检查服务器日志中是否出现 GPTBot、OAI-SearchBot 等 UA 名称,最后用厂商公布的 IP 列表核对真实爬虫身份(例如 OpenAI 的 gptbot.json)。如果你使用 Cloudflare 或其他 CDN,还要确认防火墙没有拦截你已放行的爬虫——CDN 和防火墙层面的 bot 拦截经常会覆盖 robots.txt 的效果。
五个常见错误
作者整理的踩坑清单值得逐条对照:
- 把 robots.txt 当安全机制。它只是礼貌请求,恶意爬虫可以直接忽略。
- 在
User-agent: *下写Disallow: /。这会连 Googlebot 一起屏蔽。 - 误屏蔽搜索爬虫,然后困惑于 AI 工具从不引用自己。
- 用 robots.txt 代替
noindex。被屏蔽的页面如果被其他站点链接,仍可能出现在搜索结果里。 - 从不检查日志。无法度量就无法管理。
常见问题
robots.txt 会影响 ChatGPT 搜索吗?
会。放行或屏蔽 OAI-SearchBot 决定了你的站点能否出现在 ChatGPT 搜索的回答中。
能屏蔽 GPTBot 但保留 ChatGPT 搜索吗?
能。屏蔽 GPTBot、放行 OAI-SearchBot 即可,两者相互独立。
屏蔽 Google-Extended 会影响 Google 排名吗? 不会。Google 表示它不影响搜索收录或排名。
robots.txt 能把页面藏起来不让 Google 看到吗?
不能。它只控制抓取。要让页面不出现在结果中,请用 noindex 或身份验证。
如何被 ChatGPT 引用?
放行 OAI-SearchBot,发布清晰准确的内容,并确保页面不依赖重型 JavaScript 也能加载。
小结
AI 爬虫管理的关键不是"屏蔽 AI"或"拥抱 AI"的立场选择,而是承认训练、搜索、用户触发是三种不同用途,因而可以有三套不同的策略。对大多数内容站点来说,合理的起点是屏蔽训练类爬虫、放行搜索类爬虫,再用服务器日志和厂商 IP 列表验证配置是否真正生效。最后别忘了回到那句基础认知:robots.txt 是爬虫指令,不是安全边界。
相关推荐

uGAP:统一100+非洲地理数据集的AI平台
uGAP是开普敦大学团队开发的非洲地理空间AI平台,统一120余个非洲数据集并提供Python SDK,支持数据发现、处理与模型训练一站式工作流,已用于气旋洪水制图等实战场景。

Cursor能控制你的电脑了:AI代理可驱动桌面应用测试
Cursor 新增桌面控制能力,AI 代理可驱动 iOS 模拟器等桌面应用测试自己构建的功能。本文分析这一更新对开发工作流的影响、技术实现可能路径及可靠性考量。

Vibecoding自研推理引擎:理想丰满,现实骨感
Reddit开发者分享Vibecoding自研推理引擎的真实经历:用WebGL2和GLSL在浏览器跑GGUF Q4模型,却陷入tokenizer调试地狱。本文分析浏览器端LLM推理的工程难点,以及为何直接clone llama.cpp是更理性的选择。