AI 爬虫怎么管：robots.txt、训练抓取与搜索边界（2026）
AI 爬虫治理不是一句全开或全关。关键是把 Google 搜索抓取、AI 训练抓取和 AI 搜索类抓取分开，再按 bot、目录和业务价值决定 robots.txt 与技术控制策略。
// 相关文章
AI 爬虫治理不是一句全开或全关。关键是把 Google 搜索抓取、AI 训练抓取和 AI 搜索类抓取分开，再按 bot、目录和业务价值决定 robots.txt 与技术控制策略。
这两年，很多网站后台都会出现一类新问题：抓取日志里不只有 Googlebot、Bingbot 这些老面孔了，还开始出现 GPTBot、ClaudeBot、CCBot、PerplexityBot、Bytespider 之类的新爬虫。很多人第一反应是统一封掉。也有人反过来，觉得只要能带一点 AI 曝光，就应该全部放开。
这两种做法，都太快。因为今天讨论的已经不只是“要不要抓取”，而是三件事混在一起：
这三类抓取的目的不同，能不能通过 robots.txt 控制、控制后会不会影响搜索可见性、以及对企业站有没有实际业务价值，也都不一样。你如果把它们混成一件事，就很容易出现两种极端：该放的不敢放，该控的不知道怎么控。
这篇文章不站队。只做一件事：把边界讲清楚。什么是搜索抓取，什么是 AI 抓取；robots.txt 到底能管什么，不能管什么；企业站该怎么判断是全放、全挡，还是按目录和 bot 类型分层管理。
如果只压成一句话，我会这么说：现在的网站抓取治理，不该再是一个总开关，而该是分 bot、分目的、分目录的策略。
原因很简单。Google 的常规搜索抓取，本质上是在帮你进入搜索索引；而很多 AI crawler 的目标，可能是模型训练、RAG 检索、摘要回答、内容理解，甚至只是做自己的索引。它们对你站点的价值，不是同一类价值。
Google 官方在 Google crawlers overview 和 common crawlers 文档里，对自家抓取器分类说得很清楚：常规 crawler、特殊 crawler、用户触发 fetcher，不是一回事。放到更广义的爬虫治理里，其实也一样。先分清抓取目的，再谈策略。
| 抓取类型 | 典型代表 | 主要目的 | 企业站最该关心什么 |
|---|---|---|---|
| 搜索引擎抓取 | Googlebot、Bingbot | 索引与搜索展示 | 搜索可见性、抓取稳定性、索引效率 |
| AI 训练抓取 | GPTBot、ClaudeBot、CCBot 等 | 训练或语料收集 | 内容使用边界、服务器资源、内容授权 |
| AI 搜索 / 摘要抓取 | 部分 AI 搜索产品抓取器 | 回答生成、摘要、检索增强 | 曝光与引流是否值得、是否影响内容控制 |
很多站长现在最容易混淆的，就是 Google 搜索抓取和 Google 的 AI 相关控制。Google 官方在关于抓取器和控制的文档里，已经把这件事拆得比较清楚了。
先说最核心的一点：控制 Google Search 的抓取，和控制部分 AI 使用场景，并不是同一个开关。
你在 Google 搜索层看到的 Googlebot，主要关系到 Search、Discover、图片、视频等搜索产品索引。Google 关于 common crawlers 的文档明确写到，`Googlebot` 的 crawl preferences 会影响 Google Search 及其相关搜索产品。另一方面，AI 语境里大家常提到的 `Google-Extended`，更多是和某些生成式 AI 数据使用边界相关，而不是让你“退出 Google 搜索”。这两者如果混成一个，就很容易把该保留的搜索可见性也一起误伤。
所以第一步不是“我要不要屏蔽 Google”。第一步是：你到底在控制哪一层使用权限。搜索索引？AI 训练？还是某种生成式展示？层级不同，动作也不同。
谈 AI 爬虫治理，绕不过 robots.txt。可 robots.txt 经常被想得太万能。Google 的 robots.txt 入门文档 和 robots 规范解释 其实讲得很直白：它主要是抓取访问控制，不是索引和保密的万能工具。
这意味着：
对 AI crawler 也是一样。前提是，这个 bot 得愿意遵守 robots.txt。如果它遵守，你可以通过 `User-agent` 和 `Disallow` 做基本流量控制；如果它不遵守，robots.txt 只能算礼貌声明，不能算技术封锁。
所以企业站在做 AI bot 治理时，至少要分两层：
这不是因为突然冒出几个新 bot 名字，而是因为网站面对的抓取目的变多了。过去你大多只用想搜索引擎、SEO 工具、少量采集爬虫。现在多了生成式 AI、AI 搜索、训练语料抓取、代理型访问，内容被请求的方式变复杂了。
国外技术 SEO 圈在这件事上讨论很密。Patrick Stox 在 Ahrefs 发过两类很有代表性的文章，一类是 AI bot block rates，一类是常规 SEO bot 的封锁情况。Cloudflare 这边则连续发布了关于 一键屏蔽 AI bots、robots 策略执行 的官方文章。你能很明显看到，行业讨论已经从“有没有 AI bot”转向“该怎么管”。
这背后的现实很简单：
对企业站来说，这不是媒体行业才会遇到的问题。只要你的网站有高质量方法论文章、产品文档、案例页、知识库，就可能被不同目的的 crawler 访问。差别只在于你有没有看见、有没有分类、有没有控制。
一谈 AI crawler，很多人会陷入立场判断。可企业站更现实，最该先问的是投入产出。
也就是说，你至少要回答这几个问题：
如果这几个问题都没想清楚，就直接“全放”或“全挡”，基本都不够成熟。企业站和纯媒体站不一样。前者更看咨询、线索、品牌信任和主题权威，不是单纯追求被谁都抓一遍。
| 页面类型 | 对 AI 抓取的态度更适合是什么 | 原因 |
|---|---|---|
| 服务页 | 谨慎放开 | 希望被理解，但更看精准引流和品牌表达 |
| 深度方法论文章 | 按 bot 分层 | 有曝光价值，也有内容资产被过度消费的风险 |
| 案例页 / 报价相关页 | 更偏保护 | 更敏感，更希望控制使用边界 |
| 公开帮助文档 | 视业务模式而定 | 有时开放能扩大认知，有时会稀释直接访问 |
如果你今天还只写一个 `User-agent: *`，那大概率已经不够细了。至少从治理角度，你应该开始单独识别几类常见 bot。
国外圈子现在常单独讨论的，通常包括：
原因不是这些名字更“潮”，而是它们背后的使用目的可能不同。有的偏搜索索引，有的偏训练语料，有的偏摘要与问答，有的还可能同时覆盖多种场景。Cloudflare 关于 2025 年爬虫流量的文章里，就明确指出 AI bots 和搜索 bots 已经是网站日志里越来越值得分开的两大类。
对企业站来说，这意味着 robots.txt 至少不该再只是一组笼统规则。它更像一份 bot policy。谁能抓，抓哪些目录，哪些先不开，哪些只对搜索开放，应该有明确判断。
这是很常见的误用。Google 在 noindex 文档 里写得很清楚：`noindex` 是索引控制，不是 robots.txt 的替代，也不是对所有 crawler 的通用抓取控制。
更关键的是，如果一个页面被 robots.txt 挡住，Google 甚至可能看不到你写在页面里的 noindex。也就是说，很多站点想当然地把“不给抓”和“不进索引”混成一个动作，结果经常互相打架。
放到 AI crawler 治理里，更要分清：
三件事不是同一个杠杆。你如果拿错工具，最后很可能不是控住 AI crawler，而是把正常搜索表现也一起搞乱。
这个错误的后果通常比想象中大。因为很多团队在听到“AI 用你的内容训练”后，会本能想把所有 bot 收紧。但如果连 `Googlebot`、`Googlebot-Image` 这类搜索相关抓取也一起收紧，最先受影响的通常是搜索可见性，而不是 AI 产品。
Google 关于 common crawlers 的文档已经给出很明确的 user-agent token 用法。也就是说，至少在 Google 这边，你本来就应该更精细地写规则，而不是一把切。
更稳的原则是：
你要守住的是搜索基础盘，而不是为了一个还没想清楚的 AI 策略，把现有自然搜索一起误伤。
如果没有日志，你很容易被几个 bot 名字吓到。可到底是不是问题，得看量、频次、目录分布和服务器影响。
这也是为什么这篇话题和 服务器日志分析、抓取预算、SEO 审计 是连在一起的。
更实用的判断方式，是先在日志里看：
如果没有这层证据，很多“政策”最后只是情绪化配置。对企业站来说，抓取治理最怕的，不是没有立场，而是没有证据。
| 判断项 | 先看什么 | 为什么重要 |
|---|---|---|
| 是否真的有 AI bot 压力 | 日志中的 bot 名称、请求量、时段 | 先区分感知风险和真实流量 |
| 是否影响服务器 | 响应时间、请求峰值、目录集中度 | 决定是否要技术级拦截 |
| 是否影响搜索抓取 | Googlebot 抓取稳定性、Crawl Stats | 防止误伤搜索基础盘 |
如果一定要给建议，我更倾向第三种：按目录分层。原因很现实。企业站很少所有页面价值都一样，也很少所有页面都值得同一种 bot 使用。
更接近实操的策略通常是：
这样做的好处是，你不用在“全部开放”和“全部封锁”里二选一，而是把内容资产按商业价值、可替代性、可见性诉求分层。对 B2B 企业站和服务型网站，这种策略通常比单一开关更稳。
下面这个判断，不一定适合所有站，但对企业站和咨询型站点很实用。
更适合先放开的情况：
更适合先挡住或收紧的情况：
注意，这不是价值判断，而是业务判断。企业站最重要的从来不是跟风，而是让抓取策略服务业务模型。
很多团队写 robots.txt 最危险的地方，不是写得太少，而是写得太急。尤其是看到 AI crawler 之后，容易连目录层级、资源文件、图片路径一起拦住。
Google 在 robots 文档里明确提醒过，不要随便挡住会影响页面理解的重要资源。也就是说，如果你的规则粗糙到把搜索引擎理解页面所需的资源一起封掉，那不叫治理，叫自伤。
更稳的顺序通常是：
这类控制尤其适合结合测试窗口做。先 7 天，后 30 天，看请求和索引有没有异常，再决定是否扩大范围。
如果某类 crawler 不遵守协议，或者确实已经带来明显资源压力，robots.txt 本身就不够了。这时你要补的是技术治理层，而不是继续在文本规则里较劲。
更常见的补法包括：
Cloudflare 在官方文章里反复强调的一件事，其实就是：robots.txt 是声明，执行要靠边缘层和 bot management。对技术基础比较成熟的站点，这一步比继续争论“应不应该发 robots 规则”更有现实意义。
如果你现在谈 OpenAI crawler 还只提 `GPTBot`，那已经有点落后了。OpenAI 的官方 bots 文档现在把相关访问至少拆成了几类：OAI-SearchBot、GPTBot、以及用户触发型的 `ChatGPT-User`。
这件事为什么重要？因为它直接说明，OpenAI 自己也不再把“训练抓取”和“搜索结果展示”混成一个动作。文档里写得很清楚：
这意味着，企业站今天完全可以做更细的判断：你可以不开放训练 bot，但保留某些搜索型 bot 的可见性；也可以只开放公开知识目录，而不是把所有内容一刀切。OpenAI 这套拆分，本身就说明行业已经进入更细颗粒度治理阶段。
对企业站尤其值得注意的一点是：OpenAI 官方文档还提到，搜索相关调整在 robots.txt 更新后通常需要大约 24 小时左右系统才会调整。这类时间延迟，也提醒你不要今天改规则、明天就急着下结论。
Anthropic 这边的变化也很重要，而且更接近你刚才说的“要看国外大神和最新技术”。因为这不是泛泛讨论，而是官方策略本身在变。
Anthropic 帮助中心在最近更新的页面里，已经明确把抓取机器人拆成至少三类：ClaudeBot、`Claude-SearchBot`、`Claude-User`。Search Engine Journal 在 2026 年 2 月的报道里，也单独提到 Anthropic 把搜索、训练和用户触发抓取拆开了，这件事会直接影响“你挡了哪个 bot，就失去哪种可见性”的判断。
这个变化的意义非常直接：
如果 OpenAI 和 Anthropic 都在把 bot policy 拆细，那企业站继续用一套粗暴的“全开 / 全关”逻辑，就越来越不够用了。因为平台本身都在提示你：这些访问不是同一种事。
| 平台 | 训练相关 bot | 搜索相关 bot | 用户触发访问 |
|---|---|---|---|
| OpenAI | GPTBot | OAI-SearchBot | ChatGPT-User |
| Anthropic | ClaudeBot | Claude-SearchBot | Claude-User |
这件事很少有人愿意做，但以后会越来越重要。因为你在日志里看到 `GPTBot`、`ClaudeBot`、`Googlebot`，不等于它就一定是真的。尤其在 AI crawler 争议越来越多之后，伪装和混淆只会更多，不会更少。
Google 在 crawler 文档里长期强调过验证机制。OpenAI 的 bots 文档里则直接公布了 IP 地址列表 JSON。也就是说，至少对一部分主流 bot，你不该只靠 user-agent 字符串判断，而该结合：
如果没有这一层，你很容易出现两种误判：
对企业站来说，这不只是技术细节，而是治理前提。因为你最终做的不是写一份好看的 robots.txt，而是决定哪些流量值得保留，哪些值得限制。身份没确认，后面的治理都不稳。
很多团队一改 robots，就会开始看一个指标：访问量是不是掉了，或者是不是没什么变化。这个看法太粗。
更值得看的是四类指标：
如果你只看总请求量，根本看不出变化到底是好是坏。举个很简单的例子：总请求少了，但少掉的是无价值 AI bot 流量，Googlebot 和核心搜索抓取都还稳定，这通常是好事。反过来，如果少掉的是搜索抓取，AI bot 还在跑，那就是坏事。
更适合的观察窗口通常是：
抓取治理不是改完就结束，它本质上是一个策略调优过程。尤其在 AI crawler 还在持续演化的环境里，规则很少一次就写到最优。
这点也很重要。不是所有站都该立刻开始大规模封控。尤其是下面几类站点，更不适合因为行业情绪就立刻全关：
原因很简单。你真正更该先解决的，也许不是 AI crawler，而是 抓取与索引排查、内链发现路径、旧内容治理。如果这些基础都没做好，先急着写一堆 AI crawler 规则，很多时候是把次要矛盾当主要矛盾。
这也是为什么我更反对“AI bot 一律封掉”这种口号。不是因为不该防，而是因为企业站的优先级从来不该由口号决定。先看业务，先看日志，先看搜索基础盘。这个顺序不能反。
很多团队知道不能一刀切，但还是不知道具体怎么分。更实用的办法，是先按业务形态套三种模板，再结合日志微调。
第一种，品牌教育型网站。特点是公开文章、教程、基础知识内容很多，目标是扩大认知、承接搜索、培养潜在客户。这类站更适合：
第二种，强内容资产型网站。比如知识库、研究报告、深度案例、付费前教育内容很多，且单篇内容生产成本高。这类站更适合：
第三种，标准 B2B 企业站。像天问这一类，内容的目标是服务品牌、服务能力表达、询盘转化和主题权威建设，不是做纯媒体流量。这类站更适合：
| 网站类型 | 更适合的 AI crawler 策略 | 首要目标 |
|---|---|---|
| 品牌教育型 | 开放中带保护 | 认知扩散与搜索增长 |
| 强内容资产型 | 更偏收紧 | 保护高成本内容资产 |
| B2B 企业站 | 按目录分层 | 保搜索、控风险、服务转化 |
很多网站一改策略，就先从全站首页级规则下手。这个动作太重。更稳的办法，是先从几个最容易看出效果、又不容易误伤的目录试。
通常更适合作为第一批试点的，是这些目录：
不太适合作为第一批试点的，往往是：
原因很简单。你需要的是一个可观察、可回滚、可比较的测试窗口，而不是一次性改掉整站抓取路径。抓取治理如果没有回滚余地，风险会很高。
AI crawler policy 还有一个很容易被忽略的问题：很多团队改了 robots.txt、改了 CDN 规则、改了某些目录的访问策略，过几周后就分不清到底改了什么，也分不清变化是不是这些动作造成的。
更适合企业站的做法是，每次变更至少留这几项：
这一步看起来很行政，其实非常重要。因为抓取问题本来就不是当天立刻出结果的。你如果没有变更记录，很快就会陷入“是不是上周改过什么”的混乱。对技术 SEO 来说，最怕的从来不是改得少，而是改了但无法复盘。
很多团队谈抓取治理时，只盯 HTML 页面。可对一些企业站来说，真正被高频访问、也最容易被拿来做再利用的，可能是 PDF、白皮书附件、案例下载页、图片资源或文档型文件。
Google 在 crawler 和资源访问相关文档里一直提醒，不要随便阻断影响搜索理解的重要资源；而放到 AI crawler 语境下，这又多了一层问题：某些高价值附件也许并不适合完全开放给所有 bot 使用。
所以企业站最好额外回答这些问题：
这点在做外贸站、工业站、B2B 服务站时尤其常见。很多真正有价值的内容，不在普通文章正文里，而在附件、手册、案例资料里。你如果只治理 HTML，很容易漏掉真正敏感的内容资产。
这又是一个很容易被误解的点。有人会说，既然 AI 搜索会引用网页，那就应该尽量开放更多抓取。这个推论未必成立。
因为对企业站来说，更关键的问题不是“有没有被引用”，而是：
这也是为什么 AI crawler 治理本质上不只是技术题，也是渠道价值题。它不像传统 SEO 那样，至少还有 Search Console、排名、点击这些相对稳定的指标。AI 引用现在很多时候仍然不够透明。所以你越需要克制，越需要用小范围试验，而不是一开始就押注一个大方向。
有些站现在最该做的，真的不是立刻屏蔽，而是先把 bot 观测体系补起来。通常如果你符合下面几种情况，就更该先观察：
这时最稳的动作，通常是：
等这几项齐了，再决定 robots 和 WAF 层怎么写，通常会比现在直接动刀更稳。因为很多团队现在最大的短板，不是没有政策，而是根本没有可执行的观测面板。
反过来，如果你已经看到以下信号，就说明不只是该观察，而是真的该动规则了：
这时就不是“先看看再说”的阶段了，而是要开始把观测结果转成规则，分层处理，必要时做技术级拦截。很多企业站会卡在这个转换点上，明明看到了问题，却迟迟不写规则。结果就是日志年年看，策略年年空白。
最后给一个更现实的执行节奏。很多团队一听到 AI crawler 治理，就想一步到位写完最终版规则。可这件事更适合三段走。
这样做的好处很现实：
抓取治理这件事，最终不是“写对一份文件”，而是建立一套长期有效的机制。今天是 AI crawler，明天也许还会有新的 bot 类型。只有机制稳了，后面新问题才不会每次都重头来过。
很多企业站最后卡住，不是技术做不了，而是团队意见不一致。品牌想开放，内容怕被白拿，运维担心资源，SEO 又怕误伤搜索。这时最需要的，不是继续争论，而是先把判断条件摆在桌面上。
一个够用的决策矩阵可以只看四项：
如果搜索基础盘还不稳，就先别大动。先保搜索。如果内容资产很高价值、资源压力也明显，而收益又看不清，那就更偏向收紧。如果品牌扩张优先、资源压力不大、且内容本来就公开教育导向，那么就可以更开放一点。
| 判断组合 | 更适合的动作 | 原因 |
|---|---|---|
| 搜索未稳 + 团队无监控 | 先观测，不急着改 | 先保基础盘，避免误伤 |
| 资源压力明显 + 价值不清 | 优先收紧 | 先止损，再评估 |
| 品牌扩张优先 + 压力不大 | 有限开放 | 保留认知扩散机会 |
| 高价值内容资产 + 可精细治理 | 按目录分层 | 兼顾搜索、保护和试验 |
最后再补一个很实操的点。你如果准备改 robots、改 WAF、改 bot policy，就不要只写“上线时间”，也要先写“什么情况下回滚”。
更常见的回滚条件包括：
把回滚条件提前写出来，最大的好处不是保守，而是让试验更敢做。因为你知道，一旦误伤了搜索基础盘，可以按既定条件快速撤回。没有回滚条件的治理，通常不是更勇敢，而是更容易失控。
如果把整篇文章压缩成一句执行结论，那就是：先分 bot，再分目录，再分目标。先保搜索，再谈 AI；先看日志，再写规则；先小范围试，再扩大。把这个顺序守住，AI crawler 治理就不会变成一场情绪化封控，而会变成一套真正服务业务的技术策略。
对企业站来说，抓取治理最后拼的也不是谁更激进，而是谁更清楚自己在保护什么、开放什么、为什么这样做。边界一清楚，很多争论自然就会少很多。
这也是为什么真正成熟的策略，看起来往往不极端。它不靠一句口号，不靠一次全站封控，而是靠持续观测、分层判断和可回滚的规则迭代。这样的策略，才更适合长期跑。
先把边界理顺，再谈开放和封控，通常就不会走偏。
很多团队的问题不是没有规则，而是还没把搜索抓取、训练抓取和 AI 搜索类抓取分清。边界没分清，后面的 robots、WAF 和目录策略就很容易越做越乱。
有，而且不只是一点关系。
首先，很多团队会误伤正常搜索抓取。其次，AI crawler 流量如果占用服务器资源，可能影响 Googlebot 抓取稳定性。再次，目录级控制、资源控制、日志分析、canonical、noindex 这些动作，本来就是技术 SEO 的一部分。
所以这不是一个“独立于 SEO 的法务或运维小话题”。它更像技术 SEO 在 AI 环境下的延伸治理题。你如果做得好，搜索基础盘会更稳；做得乱，最先被搞坏的通常还是搜索索引和抓取效率。
这也是为什么它值得和 技术 SEO 指南、内容治理、主题权威 这几条线一起看。它不是孤立动作。
如果回到天问这样的企业站，我更倾向这样的思路：
这样做的原因很现实。企业站不是新闻站，也不是单纯内容平台。它最终要服务的是品牌信任、询盘、服务能力展示和主题权威建设。你不需要把所有内容都让渡给所有 crawler，也不必因为焦虑把能带来认知价值的抓取全部挡死。
如果你连“哪些 bot 真来过、抓了哪些目录”都还不知道，那先别写一堆规则。先看日志。先分类。先把搜索和 AI 抓取分开。很多站点的问题，不是规则写得不够多，而是问题还没分清。
如果你们准备把 AI crawler 治理真正落到执行层，最好顺着再看 服务器日志分析、抓取预算、SEO 审计、技术 SEO 和 Google SEO 优化服务。这件事最终不是单条 robots 规则，而是一整套抓取分类、资源控制和业务边界判断。
不一定，关键看你屏蔽的是谁。如果误把 Google 搜索相关 crawler 一起挡了，当然可能影响搜索可见性；如果你控制的是特定 AI bot 或特定 AI 使用边界，则不能简单等同于“退出 Google 搜索”。
不能这样理解。robots.txt 更像协议和声明。前提是对方愿意遵守。如果你遇到不守规则或明显影响资源的 crawler，往往还需要配合 WAF、Bot 管理和速率限制。
多数情况下都不建议。更现实的是按 bot、按目录、按内容价值分层。先保搜索抓取，再判断 AI 抓取是否值得开放。
先看日志，先分类。先知道谁来了、抓了哪里、有没有真实资源压力，再写规则。没有这一步，很多治理最后都只是情绪化配置。
如果你今天要开始做 AI crawler 治理，最重要的不是选边站，而是把边界分清楚。搜索抓取是搜索抓取，AI 训练是 AI 训练，AI 搜索摘要又是另一层。先把这三件事拆开，很多决策自然就没那么乱了。
