控制 AI 爬虫抓取频率的正确姿势

控制 AI 爬虫抓取频率的正确做法是放行但不设上限：在后台按名单开关爬虫，在 Nginx 按 User-Agent 单独限速（单 IP 8 r/s、burst 20、超限返回 429），同时用 Redis 缓存和数据库读写分离降低数据库读取压力，再用爬虫访问监控和容量仪表盘验证效果。一刀切封掉爬虫，等于主动放弃被 AI 引擎引用的机会。

为什么不建议直接封掉 AI 爬虫

结论：封爬虫能降低服务器压力，但会同时关闭内容进入 AI 答案池的入口，这笔代价比带宽更昂贵。

Clara BBS 的 GEO 层已经按“被抓取 → 被理解 → 被引用”设计：robots.txt 默认显式放行豆包 DoubaoBot、DeepSeekBot、元宝 YuanbaoBot、Kimi MoonshotBot、智谱、360、神马、夸克、通义等 16+ 中国系爬虫，以及 GPTBot、ClaudeBot、PerplexityBot 等国际系，后台「系统设置 → GEO 优化」可逐个开关、也可追加自定义 UA；/llms.txt 提供站点结构说明，/llms-full.txt 提供全量内容索引，/answers.html 把悬赏问答成对输出并带 FAQPage 结构化数据。这些都是给爬虫读取的专用入口。如果你的真实困扰只是“抓得太猛”，正确做法是限制抓取频率，而不是封禁爬虫。

Crawl-delay 能控制 AI 爬虫吗

结论：不能依靠 Crawl-delay，它不是可靠的限速手段。

robots.txt 里的 Crawl-delay 字段只有少数爬虫（如 Yandex）明确支持，GPTBot、Googlebot、Bytespider 等主流爬虫的官方文档都不保证遵守该字段。也就是说，你写了 Crawl-delay: 10，对方仍然可能一秒请求 20 次。robots.txt 真正的作用是说明“哪些可以抓、哪些不要抓”，对频率只能作为建议，不能作为限制。想限制必须靠服务端限速，让不遵守规则的爬虫收到真实的 429（请求过多）或 503（服务不可用）响应。

Nginx 怎么按 UA 给 AI 爬虫单独限速

结论：用 map 提取 AI 爬虫 UA，生成限速 key，命中这些 UA 的请求走独立限速区间，人类访客不受影响。

在 nginx.conf 的 http 块内：

map $http_user_agent $ai_limit_key {
    default "";
    ~*(GPTBot|ClaudeBot|PerplexityBot|Bytespider|DoubaoBot|DeepSeekBot|MoonshotBot|YuanbaoBot)  $binary_remote_addr;
}

limit_req_zone $ai_limit_key zone=ai_bot:10m rate=8r/s;
limit_req_status 429;

在站点 server 块内：

limit_req zone=ai_bot burst=20 nodelay;

三个参数值得讲清楚：rate=8r/s 是单 IP 稳态速率，AI 爬虫通常单线程但会连续扫几百个 URL，8 r/s 已经够它跑；burst=20 允许瞬时超速 20 个请求；nodelay 表示突发的 20 个不必排队等待——若不加 nodelay，超出的请求会延迟，拖长单次抓取时间，反而更容易让爬虫反复重试。key 为空字符串时 Nginx 不对该请求计数，所以普通用户和登录用户完全不受这条规则影响。返回 429 而不是 403，是因为 429 是标准的退避信号，多数正规爬虫收到后会自行降速；返回 403 容易被判定为永久拒绝，直接减少收录。

限速之外，怎么让爬虫压力不落到数据库上

结论：限速只能挡住部分请求，真正把数据库压力降下来的是缓存和读写分离。

第一步，在后台「系统工具 → 缓存设置」里可视化开启 Redis，不需要改代码。榜单、热点数据、外部接口响应统一走 Cache::remember 一行式调用；Redis 异常会自动降级到文件驱动，站不会因此停止工作。AI 爬虫有个特点：反复抓同一批 URL，缓存命中率极高，开缓存后这类请求几乎不会访问 MySQL。键带表前缀命名空间，同一个 Redis 实例上运行多个站点也互不干扰。

第二步，配置从库。SELECT、SHOW、DESCRIBE、EXPLAIN 会自动走从库，写操作走主库；事务内查询、行锁查询、取自增 ID 这三种场景强制走主库，保证一致性。从库连接失败时静默回退主库并记日志，业务零感知。不配从库时与单库行为完全一致，可以先只加缓存，压力真的上来再加从库。

第三步，把懒触发改成精准触发。计划任务是 Cron::register 注册、前台访问懒触发；AI 爬虫高频请求会不断触发这个检查逻辑。流量大的站建议用系统级 crontab 每分钟调用一次 /cron 入口，并且因为文件锁会防止并发重跑，不会出现同一任务同时运行两份。

怎么确认限速生效、又没伤到收录

结论：看两个地方——后台的 AI 爬虫访问监控和每日 GEO 健康体检。

「系统设置 → GEO 优化」里的 AI 爬虫访问监控仪表盘会记录哪个爬虫来过、请求频率、最近抓取的页面。如果限速配置正确，你会看到访问节奏变得平稳，而不是一小时内几千次。计划任务每天跑一次 GEO 健康体检，检查 robots 是否可达、llms.txt 是否正常输出、结构化数据是否完整。另外，容量监控插件提供每日容量快照和 MySQL 慢查询 TOP 榜（依赖慢日志开启），能告诉你限速之后数据库压力是否真的降低：如果慢查询数量没有减少，说明瓶颈不在爬虫，在 SQL 或索引。

判断“限速是否伤害收录”的方法是观察结构化数据输出和问答池收录状态，单篇 GEO 体检插件可以逐帖查看它在 llms.txt、问答池、精华索引里的收录情况，以及 AI 爬虫是否到访、主动推送是否成功。只要限速没有造成大批量 4xx，收录通常不受影响。反之，如果用了 403 或频繁超时，收录质量会明显下降。

一次完整的配置流程

结论：先开缓存，再上调限速，最后用监控数据决定是否加从库，顺序不要颠倒。

1. 后台「系统设置 → GEO 优化」确认需要放行的爬虫处于开启状态，不要一次全关；
2. 「系统工具 → 缓存设置」开启 Redis（推荐环境 PHP 7.4-8.5 + MySQL 5.7+，可选 Redis）；
3. Nginx 加入上面的 map + limit_req_zone + limit_req 三段配置，nginx -t 通过后 reload；
4. 用系统级 crontab 每分钟调用 /cron，替代前台懒触发；
5. 观察 24 小时 AI 爬虫访问监控与慢查询 TOP 榜，若数据库负载仍然高，再启用读写分离；
6. 用后台「环境体检」一键诊断协议层、缓存层、安全层，未通过项会直接给出按当前域名填好的 Nginx 修复片段，复制即用。

整套动作的核心逻辑是：对爬虫要“给路径、限速度、减负载”，而不是“关门”。限速到 8 r/s 加 burst 20，配合 Redis 缓存，多数日活数千的站点已经足够支撑。