如何编写真正能阻止 AI 抓取器的 robots.txt

关于 robots.txt 的一个不太舒服的事实

robots.txt 文件不是一把锁。它只是门上的一块告示。

当团队问是否可以用一个小小的文本文件“阻止 AI 抓取器”时，这个区别很重要。对于遵循 Robots Exclusion Protocol 的可信爬虫，答案是可以：一个正确编写的 robots.txt 可以告诉它们不要抓取你的页面。对于未知抓取器、冒充者、浏览器自动化工具，以及那些根本不在乎规则的机器人，它本身不会起任何作用。

因此，实际目标不是“让抓取变得不可能”。而是：

• 告诉合规的 AI 爬虫不要使用你的网站。
• 避免意外阻止搜索引擎或有用的服务。
• 针对滥用行为加入更强的服务器端控制。
• 随着爬虫名称变化，让策略保持可维护。

这是更乏味的说法。但它也是真正有效的做法。

robots.txt 能做什么，不能做什么

robots.txt 文件位于网站根目录：

https://example.com/robots.txt

爬虫会在抓取前请求它。该文件包含多组规则。每组规则以一个或多个 User-agent 行开头，后面跟着 Allow 或 Disallow 指令。

一个简单的全站阻止规则如下：

User-agent: GPTBot
Disallow: /

它的意思是：如果你是 GPTBot，不要抓取本站的任何内容。

但 robots.txt 有明确的硬性限制：

1. 它是自愿遵守的。恶意行为者可以忽略它。
2. 它不能阻止普通浏览器或脚本请求某个 URL。
3. 它不能移除已经在其他地方被收集的内容。
4. 它本身不定义版权、许可或训练权利。
5. 它可能被错误配置，从而阻止了不该阻止的机器人。

如果你需要真正的访问控制，请使用身份验证、授权、速率限制、基于 IP 的控制、机器人管理或法律手段。Robots.txt 仍然有用，但它应当属于更广泛的内容保护策略的一部分。

这与其他 Web 治理问题类似：可见的控制很少就是全部控制。如果你的组织内部已经存在未受管理的 AI 使用，同样的原则也适用；快速做一次 shadow AI 审计 往往比假装一份政策文件就能解决问题更有用。

从你的策略决定开始

在编辑文件之前，先确定你真正想阻止的是什么。

人们说“AI 抓取器”时，至少可能指四种不同的东西：

• 用于收集训练数据的爬虫。
• AI 搜索或答案引擎爬虫。
• 用户触发的抓取器，例如有人要求某个 AI 产品总结一个 URL 时。
• 伪装成普通浏览器的通用抓取器。

你可能想阻止所有这些。也可能希望保留搜索发现能力，同时退出模型训练。这些不是同一项策略。

例如，OpenAI 为不同用途记录了不同的 user agent，包括 GPTBot、ChatGPT-User 和 OAI-SearchBot。Google 使用 Google-Extended 作为某些 Gemini 和 Vertex AI 用例的控制令牌，而普通 Google Search 抓取由其他 Googlebot user agent 处理。

这种区分很重要。如果你草率地阻止宽泛的 user agent，可能会在试图阻止 AI 训练的同时损害普通搜索可见性。

一个合理的 AI 阻止 robots.txt 模板

下面是一个保守的起点，用于阻止若干常见且有文档说明的 AI 相关爬虫，同时不影响通用搜索爬虫：

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

这不是一个神奇的通用列表。它是一种可维护的模式。

几点说明：

• Disallow: / 表示“不要抓取任何路径”。
• User-agent: * 适用于未被更具体规则匹配到的爬虫。
• 对默认组来说，Allow: / 并非严格必需，但它能让你的意图更清楚。
• 注释应保持简短。有些解析器很宽容，但 robots.txt 应该保持简单朴素。
• 不要在 robots.txt 中包含私有 URL。该文件是公开的，列出敏感路径可能是在主动暴露它们。

最后一点值得重复。Robots.txt 不是保密机制。如果 /client-contracts/ 不应该公开，请用身份验证保护它。不要只是 disallow 它。

谨慎对待 Google-Extended

Google-Extended 经常被误解。它并不等同于阻止 Google Search。

根据 Google 的文档，Google-Extended 是一个独立的产品令牌，发布者可以用它来管理网站内容是否可帮助改进某些 Gemini 和 Vertex AI 能力。阻止它本身不应阻止 Googlebot 为 Search 抓取网站。

也就是说，除非你确实想这样做，否则不要用如下宽泛阻止来替代所有 Google 指令：

User-agent: Googlebot
Disallow: /

这会告诉 Google Search 的主要爬虫不要抓取你的网站。对于大多数公开网站来说，这不是你想要的结果。

同样的区分也适用于其他地方。一些供应商会将训练爬虫与用户触发的浏览或 AI 搜索爬虫分开。另一些则不会。你需要阅读自己关注的机器人文档，并把 robots.txt 当作一个持续维护的文件，而不是一次性勾选项。

像测试生产代码一样测试这个文件

Robots.txt 看起来很简单，这也正是它容易出错的原因。

常见错误包括：

• 把它上传到错误位置，例如 /assets/robots.txt 而不是 /robots.txt。
• 使用从文档编辑器复制来的智能引号。
• 意外用 User-agent: * 和 Disallow: / 阻止所有爬虫。
• 假设某个域名的文件会适用于另一个子域名。
• 忘记 http://、https://、www 和非 www 主机可能会根据你的设置被不同处理。

对于多域名网站，请检查每一个规范主机。位于 https://www.example.com/robots.txt 的 robots 文件不会自动管辖 https://app.example.com/robots.txt。

调试时，请检查真实的 HTTP 响应，而不只是 CMS 预览显示的内容。你希望看到 200 OK 响应、尽可能是 text/plain 内容类型，以及与你预期完全一致的文件。如果涉及重定向、缓存或 CDN 规则，检查原始 header 会很有帮助。在生产环境中调试重定向和 HTTP header 的工作流在这里可以直接套用。

为忽略规则的机器人添加服务器端控制

如果爬虫是合规的，robots.txt 是最清晰的信号。如果爬虫是滥用性的，你就需要执行控制。

实用控制包括：

速率限制

为异常请求模式设置阈值：每分钟请求页面过多、深度翻页遍历、重复 404，或来自少量 IP 的高请求量。速率限制应足够宽松，以免惩罚真实用户；也应足够严格，让批量提取变得昂贵。

User-agent 过滤

你可以在 Web 服务器、反向代理、CDN 或应用层阻止有文档说明的 AI 爬虫 user agent。这比 robots.txt 更强，因为它会返回实际的拒绝响应。

例如，Nginx 可以阻止某个 user agent 模式，不过生产规则应经过仔细测试：

if ($http_user_agent ~* "GPTBot|CCBot|ClaudeBot|Bytespider") {
    return 403;
}

这并非万无一失。User-agent 字符串很容易伪造。但它能阻止诚实或懒惰的流量，并降低负载。

IP 和 ASN 控制

有些运营方会发布 IP 范围，但许多抓取器生态并不会。基于 IP 的阻止可以处理明显滥用，尤其是来自没有正常用户流量的云托管网段的滥用，但它也可能造成误伤。先看日志，再写规则。

身份验证和付费墙

如果内容不能被大规模复制，就不要把完整内容放在公开 URL 上。Robots.txt 不适合用于机密材料、授权数据库、私有社区或付费档案。

内容最小化

有时最好的保护是架构层面的。不要暴露不必要的 API、大型 JSON payload、隐藏元数据、草稿端点或完整归档，尤其是在公开页面只需要一小部分内容时。以图片为主的网站也应考虑自己发布了哪些元数据；在线分享照片前剥离 EXIF 元数据 中的隐私逻辑同样适用于内容运营。

使用 robots meta 标签进行页面级规则控制

Robots.txt 控制抓取。Robots meta 标签和 X-Robots-Tag header 控制合规搜索引擎和爬虫的索引及摘要行为。

例如：

<meta name="robots" content="noindex, noarchive">

或者作为 HTTP header：

X-Robots-Tag: noindex, noarchive

这些不是针对 AI 的专用护盾。当你希望页面可访问但不被索引时，它们很有用。不过，如果你在 robots.txt 中禁止某个爬虫抓取页面，它可能永远看不到页面级 meta 标签。不要依赖一个位于爬虫被禁止抓取的 URL 上的 noindex 标签。

大致规则是：

• 使用 robots.txt 来减少或阻止抓取。
• 使用 meta robots 或 X-Robots-Tag 来控制索引行为。
• 使用服务器端控制来执行访问限制。

发布后监控日志

发布文件只是第一步。之后，请检查你的日志。

关注以下内容：

• 你指定的 user agent 对 /robots.txt 的请求。
• 在提供 disallow 规则后仍然继续抓取的情况。
• 高请求量的可疑 user agent。
• 像浏览器一样的 user agent 按顺序请求数千个页面。
• 对 feed、sitemap、搜索页面和分页的重复访问。

如果某个机器人请求 robots.txt，看到全站 disallow 后停止，说明 robots.txt 完成了它的工作。如果它继续抓取，请把该机器人纳入执行控制：速率限制、阻止或身份验证。

也要审查你的 sitemap 暴露情况。Sitemap 对搜索引擎很有用，但它们对抓取器来说也是方便的地图。这并不意味着你应该从普通网站移除它们。它意味着你不应该包含那些不希望公共系统发现的 URL。

保持文件精简并定期审查

Robots.txt 很容易腐化。营销团队添加了一个活动微站。开发者添加了一个 staging 路径。供应商更改了爬虫名称。两年后，没人知道一半规则为什么存在。

把它当作配置来对待：

• 尽可能将它存入版本控制。
• 为每个 AI 爬虫组添加简短注释。
• 每季度审查一次。
• 添加宽泛规则前先检查供应商文档。
• 在 CDN、CMS 或托管变更后进行测试。

如果你的网站发布 AI 辅助内容，也要把爬虫策略与编辑透明度分开。阻止 AI 抓取器关乎访问和复用。披露关乎读者信任。它们在伦理上有重叠，但不是同一种控制。小型网站上诚实的 AI 披露应是什么样 中介绍了一种实用的披露方式。

<!-- tool-cta:start -->

💡 试试这个： 为 AI 抓取工具添加规则后，请使用 Robots.txt Tester 确认语法，以免也意外屏蔽合法机器人。

<!-- tool-cta:end -->

结论

一个好的 robots.txt 文件会阻止合规的 AI 爬虫。它无法阻止有决心的抓取、复制的 user-agent 字符串、被入侵的浏览器，或人们手动把你的内容粘贴进 AI 系统。

这并不意味着它没用。它意味着它只是其中一层。

为有文档说明的 AI 爬虫编写明确规则。避免使用会损害搜索可见性的宽泛阻止。测试实际提供的文件，而不是草稿。观察日志。在行为从不受欢迎变成滥用时，使用服务器端控制来执行。

Web 一直运行在协议、规范和执行的混合之上。Robots.txt 是规范层。使用它，但不要把它误认为一堵墙。