Skip to main content
Bunny Shield maintains a catalog of well-known bots, from search engine crawlers and advertising verifiers to AI scrapers, uptime monitors, and social link-preview agents. Each bot is grouped into a category and, where the operator publishes the necessary data, its authenticity is verified before it is trusted. Allowing a bot lets its requests bypass Bunny Shield’s mitigation layers, such as DDoS challenges, bot detection and access lists, so legitimate automation reaches your site uninterrupted. Blocking a bot stops it at the edge.

How Bunny Shield handles bots

Every request is evaluated in the same order:
  1. Identify: The User-Agent is matched against the catalog of known bots.
  2. Categorize: The matched bot belongs to a category such as SEO, AI Scraper, or Social. Categories let you set policy for many bots at once.
  3. Verify: If the bot’s operator publishes verification data, Bunny Shield confirms the request genuinely comes from that operator before trusting it (see Verification process).
  4. Apply the action: Bunny Shield applies the action configured for that bot in the current Shield Zone (allow, block, or the zone default).

Verification process

Not all traffic claiming to be a known bot is genuine. Many malicious actors spoof user agents to bypass protections. To prevent this, Bunny Shield verifies authenticity before a bot is ever allowed through:
  • Reverse DNS (rDNS): The request IP is resolved to its PTR hostname, the hostname is checked against the operator’s trusted domains, and a forward DNS lookup confirms the hostname resolves back to the same IP.
  • Published IP ranges: For operators that publish official IP range lists the request IP is checked against them.
Only when verification passes is the bot treated as genuine and its configured Allow applied. A spoofed request that fails verification does not inherit the allow and continues through Bunny Shield’s normal protection layers.
Some bots have no verification method published by their operator. These are unverifiable: Bunny Shield can still recognize and categorize them, but it cannot confirm the request is genuine. Allowing an unverifiable bot trusts the User-Agent at face value, so apply those allows deliberately. If a method to validate becomes available, such as a published IP range, the validator will be updated to use it.

Bot actions

For each bot or category in a Shield Zone you can set one of the following actions:
  • Allow: Verified requests from the bot are treated as legitimate and skip the DDoS challenge, Bot Detection, and Access List mitigation layers. An allowed bot passes the DDoS/managed challenge automatically and is not blocked, challenged, or logged by your Access Lists (an Access List Bypass still applies).
  • Block: Requests matching the bot are rejected at the edge with a 403 response.
  • No action (default): Bunny Shield does not apply any bot-specific handling. The request continues through the standard protection layers and is treated like any other traffic.
Allowing a bot does not exempt it from the WAF or Rate Limiting. Those layers continue to evaluate allowed bots, so a genuine crawler that trips a WAF rule or exceeds a rate limit is still actioned. Allow only affects the DDoS challenge, Bot Detection, and Access List layers.

Action precedence

When more than one setting could apply to a request, Bunny Shield resolves the action in this order:
  1. Per-bot override: An action set on a specific bot always wins.
  2. Per-category override: If the bot has no per-bot override, the action set on its category applies.
  3. No override: If neither is set, Bunny Shield takes no bot-specific action. The request is neither specially allowed nor blocked, it is handled by whatever Shield layers are enabled for the zone (WAF, Rate Limiting, DDoS, Bot Detection, and Access Lists), exactly like ordinary traffic. You can still match the bot in the Rule Engine using the VERIFIED_BOT_CATEGORY variable (see Using verified bots in custom rules).

Bot categories

Supported bots are grouped into the following categories. Setting an action on a category applies it to every bot in that category, unless a specific bot has its own override.

Default configuration for new zones

New Shield Zones start with a curated default so that established, widely trusted bots are allowed while more aggressive or optional bots are left for you to opt into.
  • Allowed by default: Major search engine crawlers, Google advertising verifiers, Google’s performance tools, and the main social and link-preview bots.
  • Left at “No action” by default: AI scrapers, user-triggered AI tools, SEO analytics and backlink crawlers, secondary search crawlers, and uptime-monitoring tools. These are recognized and categorized, but not automatically allowed, so you can enable only the ones you want.

Why verification matters

  • Prevents abuse: Many malicious crawlers disguise themselves with fake user-agent strings. Verification means only genuine bots inherit an allow.
  • Preserves SEO and integrations: Verified crawlers and preview bots you allow skip Bot Detection and the DDoS challenge, so they can crawl uninterrupted, keeping your site discoverable and your shared links rich.
  • Improves security: Fake bots do not inherit an allow and remain subject to full protection, reducing scraping, spam, and credential-stuffing attempts.

Using verified bots in custom rules

When a bot passes verification, Bunny Shield exposes its category to the Rule Engine through the VERIFIED_BOT_CATEGORY variable. This lets you write custom WAF rules that key off verified-bot categories in addition to the allow/block actions above. The variable resolves to the bot’s category (for example SEO or Social) only when the request has been verified. It is empty for unverifiable bots, for requests that fail verification, and for traffic that is not a recognized bot, so a rule built on this variable acts only on genuinely verified bots. For example, you can use it to:
  • Act on an entire verified category at once, for example challenging or blocking every verified AI scraper on sensitive paths such as /search or your API, without naming each bot individually.
  • Exempt a verified category from a rule that would otherwise match, without allowing the bot outright.
  • Combine VERIFIED_BOT_CATEGORY with a User-Agent match to target a single bot within a category and give it its own rate limit. For example, match VERIFIED_BOT_CATEGORY equal to SEO and a User-Agent containing Googlebot to apply a crawl-rate limit that affects only genuine, verified Googlebot traffic, while leaving other SEO crawlers on their own limits. Because the category is set only after verification, a spoofed User-Agent won’t match, so the limit can’t be evaded or abused by impersonators.

Understanding the Rule Engine

Last modified on July 30, 2026