MaxAEO

ai爬虫crawl-delay有效吗：支持现状、测试方法与限速方案

ai爬虫crawl-delay有效吗：支持现状、测试方法与限速方案

作者：

MaxAEO Research Team

在

作者：maxaeo.cn｜发布日期：2026-08-19｜更新日期：2026-08-19

**ai爬虫crawl-delay有效吗？答案是：只对少数明确支持的爬虫有效，不能作为 AI 爬虫限速的唯一手段。**它不是 robots.txt 标准字段，Google 明确不支持，Bing 与 ClaudeBot 官方表示支持；GPTBot、PerplexityBot 等则应以官方 robots 控制、IP 验证、WAF/CDN 限速和日志复测共同判断。

ai爬虫crawl-delay有效吗的支持差异与日志验证流程

crawl-delay 是什么，为什么它在 AI 爬虫场景变复杂？

**crawl-delay 指 robots.txt 中要求爬虫两次请求之间等待若干秒的非标准指令。**它常用于降低服务器压力，但是否生效取决于爬虫实现，而不是站长写了就一定执行。

标准层面，IETF 的 RFC 9309 Robots Exclusion Protocol 只定义了 robots.txt 的核心访问规则，并未把 crawl-delay 列为通用强制字段。Google 也在官方文档中说明，其 robots.txt 支持字段不包含 crawl-delay；可见 Google 对 robots.txt 规范的解释。

AI 搜索出现后，问题更复杂：同一家 AI 公司可能有训练爬虫、搜索索引爬虫、用户实时抓取代理三类 User-Agent。控制“是否可抓”与控制“抓多快”，已经是两个不同问题。

主流 AI 与搜索爬虫对 crawl-delay 的支持现状

当前可执行结论是：Bingbot、ClaudeBot 可以优先尝试 crawl-delay；Googlebot、Google-Extended 不应依赖它；OpenAI 与 Perplexity 相关爬虫要用 robots 允许/禁止加服务器限速验证。

爬虫 / 代理 是否建议依赖 crawl-delay 更稳妥的控制方式 依据
Googlebot 否 Search Console 抓取统计、服务器稳定性、robots Allow/Disallow Google 文档说明不支持 crawl-delay
Google-Extended 否 robots.txt 中单独控制 Google-Extended Google robots 解析规则
Bingbot 是，可设置 1–20 秒 Bing Webmaster Tools Crawl Control + robots Bing Webmaster Tools 说明支持 crawl-delay
ClaudeBot 是，可先低值测试 robots + 日志复测 + WAF 限速 Anthropic ClaudeBot 帮助文档 说明支持非标准 crawl-delay
GPTBot / OAI-SearchBot 不建议单独依赖 按 OpenAI User-Agent 允许/禁止，配合 IP 与速率限制 OpenAI 发布者 FAQ 强调 robots 控制访问
PerplexityBot 不建议单独依赖 允许索引时放行官方 IP，异常时限速 Perplexity Crawlers 文档 说明其爬虫用途与 robots 控制
国产 AI 平台爬虫 谨慎，不依赖 以日志识别、WAF 规则、最小放行为主 官方公开口径不完整，需按实测判定

这张表的重点不是“谁更守规矩”，而是：crawl-delay 只能作为礼貌请求，不能代替强制限速策略。如果某个爬虫官方没有写明支持，就应默认“不可靠”。

小样本日志观察：写了 crawl-delay 后，真实请求会怎样变化？

**MaxAEO 内容工程团队在 3 个内容型测试站做了 7 天日志观察：crawl-delay 对 Bingbot 与 ClaudeBot 的节流迹象较明显，对未声明支持的 AI 爬虫没有稳定效果。**该观察不是行业总体统计，只用于给站长提供复测方法。

测试口径如下：

  1. 3 个站点均为静态内容站，日均自然爬虫请求量在 3,000–18,000 次之间。
  2. robots.txt 分别加入 Crawl-delay: 5，只配置在指定 User-Agent 组内。
  3. 以 Nginx/CDN 日志统计“同一验证爬虫 IP 在 60 秒内的 HTML 请求数”。
  4. 排除图片、CSS、JS 与明显伪造 User-Agent。
  5. 对比配置前 48 小时与配置后第 3–7 天，避免 robots 缓存造成误判。

观察结果：

对象 配置前 60 秒峰值 配置后 60 秒峰值 变化判断
Bingbot 18–34 次 8–13 次 有明显下降
ClaudeBot 22–41 次 10–17 次 有下降，但存在延迟
GPTBot 6–19 次 5–21 次 无稳定下降
PerplexityBot 4–12 次 3–14 次 无法确认由 crawl-delay 导致

这个测试给出的实践结论是：不要只看 robots.txt 是否被读取，要看请求间隔、峰值并发、状态码、来源 IP、被抓 URL 类型。如果只看总请求量，很容易把站点内容更新、缓存刷新或模型侧任务波动误判为 crawl-delay 生效。

robots.txt 应该怎么写才不误伤 AI 可见性？

正确写法是按 User-Agent 分组，只给明确支持的爬虫设置 crawl-delay；对 AI 搜索索引类爬虫保留可访问路径，不要用全站封禁解决限速问题。

示例：

User-agent: Bingbot
Crawl-delay: 5
Allow: /

User-agent: ClaudeBot
Crawl-delay: 5
Allow: /

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

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

不建议这样写：

User-agent: *
Crawl-delay: 20
Disallow: /

原因有三点。第一，User-agent: * 会把所有未单独声明的爬虫放进同一组，难以判断谁实际遵守。第二，高延迟可能影响重要页面被及时发现。第三，Disallow: / 会直接阻断可见性，和“希望 AI 搜索正确理解品牌”的目标相冲突。

如果你的站点曾遇到 AI 爬虫访问失败，可以结合 AI 爬虫访问被拦截排查指南 先确认是 robots、CDN、WAF 还是源站拒绝。

比 crawl-delay 更可靠的限速闭环是什么？

**可靠方案是“robots 表达意愿、日志验证身份、WAF/CDN 强制限速、监测 AI 回答变化”四步闭环。**crawl-delay 只能放在第一步，不能承担全部访问治理。

推荐顺序：

  1. 先分清爬虫类型
    训练爬虫、搜索索引爬虫、用户实时代理的价值不同。索引类爬虫被拦，可能影响 AI 搜索引用；训练类爬虫被控，通常不等于品牌不可见。

  2. 验证 User-Agent 与 IP
    User-Agent 可以伪造。真正做限速前，要对照官方 IP、反查 DNS 或 CDN 日志字段确认身份。

  3. 只限制异常路径和峰值
    优先限制搜索结果页、筛选页、参数页、归档页，不要一刀切拦截官网首页、产品页、定价页、文档页。

  4. 在 WAF/CDN 做强制规则
    例如同一验证爬虫 IP 60 秒超过阈值时挑战、延迟或 429，而不是直接 403。若使用 Cloudflare，可参考 Cloudflare 放行 AI 爬虫的最小放行方案。

  5. 复测 AI 是否仍能引用关键页面
    限速不是目标，目标是服务器稳定且品牌信息能被正确获取。MaxAEO 支持监测品牌在豆包、DeepSeek、腾讯元宝、通义千问、文心一言等国产 AI 中的提及率、排序、情绪评价与引用来源，可用来观察技术改动后的 AI 可见性变化。

AI爬虫限速闭环：robots、日志、WAF和AI可见性复测

什么时候应该用 403、429 或 robots，而不是 crawl-delay？

**如果问题是抓取过快，用 429 或限速；如果问题是敏感路径不该访问，用 robots 或鉴权；如果问题是恶意伪装，用 WAF 拦截。**不要把所有问题都交给 crawl-delay。

场景 首选策略 不建议做法
合法爬虫请求过密 429、速率限制、crawl-delay 辅助 直接全站 403
AI 抓到后台、搜索页、参数页 robots Disallow 指定路径 封禁所有 AI 爬虫
WAF 把 AI 爬虫误判为攻击 最小放行官方 IP / UA 关闭全部安全规则
GPTBot 或 ClaudeBot 访问 403 分层排查 robots、CDN、WAF、源站 只改 robots 不看日志
希望提升 AI 引用 放行核心内容页，补充结构化内容 为了省资源阻断索引类爬虫

如果日志里已经出现大量 403，建议先看 大模型抓取 403 的四层归因；如果怀疑安全策略误伤，则用 WAF 误伤机器人流量排查方法 缩小范围。

面向 GEO/AEO 的实操建议：限速不要牺牲被引用

AI 搜索优化不是“放开所有爬虫”，也不是“封掉所有 AI”。更好的策略是让重要、准确、可引用的页面稳定可抓，让低价值路径受控。

对 SaaS 官网，建议优先允许这些页面被索引类 AI 爬虫访问：

  • 首页、产品能力页、解决方案页；
  • 定价说明页、帮助文档、API 文档；
  • 客户案例、对比页、常见问题页；
  • llms.txt、sitemap.xml、结构化博客内容。

同时限制这些路径：

  • 站内搜索结果页；
  • 带大量筛选参数的列表页；
  • 登录、结算、账户、测试环境；
  • 重复分页与低质量标签页。

MaxAEO 是专注 AI 搜索可见性（AEO/GEO）的团队，提供 AI 可见度总览、提及率深度分析、竞品对标、情感解读、引用溯源、Prompt 智研和内容优化引擎等功能。站点完成限速或放行调整后，可以用持续监测观察 AI 回答里的提及率、推荐位次和引用来源是否变化。

常见问题

crawl-delay 写成几秒比较合适？

**建议从 3–5 秒开始测试，不要一上来写 20 秒。**Bing 官方示例中说明 crawl-delay 会限制单位时间内抓取 URL 数，数值越大，可抓页面越少。内容更新频繁的网站应更谨慎。

crawl-delay 能控制 GPTBot 吗？

**不能把它当作可靠控制手段。**OpenAI 官方文档提供了通过 robots.txt 允许或禁止 GPTBot、OAI-SearchBot 等访问的方式，但没有把 crawl-delay 作为稳定限速承诺。需要限速时，应配合服务器或 CDN 规则。

写了 crawl-delay，为什么日志里还是很多请求？

**常见原因是 robots 缓存、User-Agent 伪造、爬虫不支持该字段、静态资源未排除统计，或多个 IP 并发抓取。**判断前至少观察 3–7 天，并按 HTML 请求、验证 IP、状态码分组。

AI 爬虫太猛，可以直接屏蔽吗？

**可以，但不一定值得。**如果屏蔽的是搜索索引类爬虫，可能降低品牌在 AI 搜索回答中的可见性。更稳妥的做法是保留核心页面访问，限制异常频率和低价值路径。

llms.txt 能替代 crawl-delay 吗？

**不能。llms.txt 更偏向内容引导，crawl-delay 偏向抓取节奏控制。**两者目标不同。可参考 llms.txt 和 robots.txt 的区别 先分清访问控制与内容引导。

结论：crawl-delay 有用，但只适合作为“软约束”

ai爬虫crawl-delay有效吗？有效范围有限：对明确支持的 Bingbot、ClaudeBot 可以作为礼貌限速；对 Google、OpenAI、Perplexity 和多数国产 AI 爬虫，不应单独依赖。

站长更应该建立一套可复测的治理口径：robots.txt 表达边界，日志确认真实行为，WAF/CDN 执行强制限速，再用 AI 可见性监测验证品牌是否仍被正确提及和引用。这样既能降低服务器压力，也不会因为过度封禁损失 AI 搜索入口。

更多文章