Bot detection and access policy
Bot signals and access rules answer different questions: one classifies automation while the other applies an explicit network decision.
How Cloudflare identifies automated traffic
Cloudflare combines network reputation, protocol behaviour, browser signals, JavaScript detections and product-specific machine learning to classify automated requests. Bot Fight Mode provides a simple zone-wide response; Super Bot Fight Mode and Bot Management add more granular signals and controls according to plan.
Bot Fight Mode scope
Bot Fight Mode challenges patterns associated with known bad bots across the proxied zone. It is intentionally simple and cannot be scoped or skipped with ordinary WAF Custom Rules or Page Rules. That makes it useful for low-maintenance sites but risky for APIs, mobile clients and automated integrations that cannot complete a browser challenge.
- Review Security Events for Bot Fight Mode actions.
- Test payment callbacks, uptime checks, search crawlers and API clients before broad activation.
- Use a more granular bot product when stable exceptions are required.
Bot scores and verified bots
Bot Management can expose a score from 1 to 99, where lower values indicate more automated behaviour. Verified bots identify known good automated services. A score is a signal, not proof of intent: combine it with hostname, path, method, authentication state and application risk.
Actions, scope and exceptions
Challenges, blocks, allows and skips have different consequences for browsers, APIs, crawlers and integrations.
AI crawlers, content bots and robots policy
AI crawler and content-bot controls can block or manage categories of automated access. Managed robots.txt can publish or augment a policy for cooperative crawlers. A robots file is advisory and does not replace an enforced WAF or bot rule against clients that ignore it.
IP Access rules
An IP Access rule acts on an IP address, CIDR range, ASN or country and can allow, block or challenge traffic according to the supported mode. Because the scope is broad, use it only when the network identity is stable and the intended action applies across the zone.
- Do not allow an entire provider network because one integration uses one address.
- Prefer a WAF Custom Rule when hostname, path, method or another request property should narrow the match.
- Keep a trusted administrative path before blocking an administrator network.
Validation and policy review
A protection policy needs representative legitimate and unwanted traffic, event evidence and a defined review cycle.
User Agent Blocking and Zone Lockdown
User Agent Blocking matches the declared User-Agent header and is easy for a client to evade; use it for compatibility or noise reduction, not identity. Zone Lockdown restricts selected URLs to allowed IP ranges and is suitable only when every legitimate client has a stable source address.
Challenge, block, skip and allow
A Managed Challenge is appropriate when legitimate humans may share a suspicious signal. Block is appropriate when matching traffic must never reach the application. Skip and allow-style decisions bypass specified controls and therefore require the narrowest possible expression, an owner and a review date.
Failure modes and recovery
Recover from a false positive by narrowing the responsible control without removing unrelated protection.
False positives and incident response
Reproduce one legitimate matching request, inspect the exact Cloudflare product and rule that acted, and change only that scope. Do not disable the complete WAF or bot layer from an aggregate symptom. After an emergency exception, replace it with stable request properties and remove temporary IP or country allowances.
Origin and application controls still matter
Bot mitigation reduces unwanted edge traffic but does not authenticate an API, protect stolen credentials or make an expensive endpoint safe. Use application authentication, authorization, rate limits, idempotency and origin capacity controls alongside Cloudflare.
