← All products

Bot Management

Cloudflare Bot Management assigns a bot score to proxied HTTP requests and exposes that score and related classification fields to rules. This page documents the classification model, configuration objects, constraints and plan availability.

Document control

Dana
Technical writer, Integrity Czech Republic s.r.o.

Overview

Automated HTTP clients cover a wide range of purposes: search engine crawlers, uptime monitors, payment and platform webhooks, price and content scrapers, credential stuffing tools, inventory automation, card testing and crawlers that collect content for model training. Distinguishing among them is a classification problem, and acting on the classification is a policy problem. Cloudflare separates the two.

Bot Management computes a classification for proxied requests and exposes it as fields in the Cloudflare Rules language. It does not block traffic by itself. Enforcement is expressed in WAF custom rules or rate limiting rules that reference those fields.

Public figures for the proportion of internet traffic that is automated vary by source, measurement population and year. Measure the automated share of your own traffic during the observation phase described in the Deployment section.

Architecture

Classification runs at the Cloudflare data centre handling the request, before the request is forwarded to the origin. Several detection systems contribute:

• Machine learning. Supervised models trained on labelled traffic across the Cloudflare network produce the primary score.
• Heuristics. Deterministic checks that identify known automation frameworks and client characteristics.
• Behavioural analysis. Per-zone analysis of request patterns compared with the site's normal profile.
• JA3 and JA4 fingerprinting. TLS client fingerprints that characterise the client stack independently of the declared user agent.
• Verified bot detection. Identification of published crawlers and services through documented validation methods.

The output is a bot score in the range 1 to 99. Cloudflare describes the score as a likelihood: lower values indicate traffic more likely to be automated, and Cloudflare notes that scores below 30 are commonly associated with bot traffic (https://developers.cloudflare.com/bots/concepts/bot-score/, retrieved 2026-08-28). The score is a probabilistic signal, not a determination that a specific client is or is not a human.

Where a challenge action is chosen, Cloudflare's Managed Challenge selects a challenge appropriate to the client, which may complete without user interaction or may require an interaction.

Capabilities

Configuration model

With Bot Management, policy is expressed in the ruleset engine. A typical configuration uses several rules with distinct scopes rather than one global threshold:

• A strict rule on authentication and checkout paths, acting on low scores.
• A moderate rule on content paths, using a challenge rather than a block.
• An allow or skip rule ahead of the enforcement rules for verified bots and for named partner automation identified by a shared secret, client certificate or source ASN.
• Rate limiting rules that reference the bot score as a counting characteristic or as part of the matching expression, where the plan permits.

Rule order matters. Exemptions must be evaluated before enforcement rules, because a terminating action stops evaluation of later rules in the phase.

Super Bot Fight Mode uses a different model: fixed categories with a selectable action per category, plus an option to exclude static resources. It does not expose numeric scores, so thresholds cannot be tuned per path. Bot Fight Mode exposes no configuration at all.

Limits and constraints

• The numeric bot score and the fingerprint fields require Bot Management, which is an Enterprise add-on. Rules written against those fields cannot be deployed on Free, Pro or Business zones.
• Classification applies to proxied HTTP traffic only. Requests that reach the origin directly are not classified.
• Requests served from cache and requests classified as static resources may not carry a usable score. Do not assume a score is present on every request when writing rules; test for field presence.
• Bot Fight Mode has no exclusions and can challenge legitimate automation, including monitoring probes, RSS readers and API clients. It is not appropriate for zones that serve APIs.
• Challenge actions cannot be completed by non-browser clients. Applying a challenge to an API path will fail those clients rather than filter them.
• Classification is probabilistic. Attackers using residential proxy networks and instrumented real browsers reduce the value of address reputation and fingerprinting signals. Expect a residual false negative rate and design detection of downstream effects, such as unusual account creation or checkout abandonment, rather than relying on classification alone.
• Analytics retention differs by plan, which limits how far back a tuning question can be investigated.
• Crawler directives for model training operated by third parties, such as directives honoured by individual AI vendors, are separate from Cloudflare controls and are configured in your own robots policy. Cloudflare controls affect requests that reach Cloudflare; they do not change a third party's stated crawling policy.

Plan availability

Deployment

Prerequisites.

• Identify the abuse that is actually occurring and the evidence for it: scraping volume, failed login rates, checkout abandonment, inventory holds, card testing patterns or model-training crawler traffic in logs.
• Inventory the automation that must continue to work: search crawlers, uptime monitors, payment webhooks, partner integrations, mobile applications and internal jobs.
• Record the paths that matter most: authentication, password reset, checkout, search, pricing and public APIs.
• Record baseline business metrics that enforcement could affect, such as conversion rate, login success rate and support ticket volume.

Staged validation. Enable classification without enforcement. Deploy rules that match the intended traffic but take no terminating action, or observe bot analytics only, for an observation window that covers a full business cycle including a peak period. Record the score distribution per path group and identify the score bands occupied by known-good automation.

Configuration.

1. Write exemption rules first, covering verified bots and named partner automation, and place them ahead of enforcement rules.
2. Add enforcement rules per path group, with thresholds derived from the observed distribution rather than from a default value.
3. Use a challenge action before a block action on user-facing paths, and use a block or rate limit rather than a challenge on API paths.
4. Set an explicit policy for crawlers that collect content for model training, separate from the policy for search crawlers.
5. Add rate limiting rules for endpoints where volume rather than classification is the constraint.

Cutover. Enable enforcement one path group at a time, starting with the path with the clearest abuse signal and the lowest business risk. Allow at least one business cycle between path groups.

Verification.

• Confirm that the baseline business metrics recorded during prerequisites have not moved outside their normal range after each step.
• Confirm that search crawlers still retrieve the pages intended to be indexable, using the crawler diagnostics provided by the search engine rather than Cloudflare analytics alone.
• Confirm that monitoring, webhooks and partner integrations still succeed, checked in their own logs.
• Confirm that the abuse metric identified during prerequisites has changed in the expected direction.

Rollback. Set the enforcement rules to disabled, or change the action from block to log or challenge, and confirm recovery of the affected metric. Keep the rule definitions rather than deleting them so that tuning can resume from the same baseline.

Operational considerations

Review score distributions and rule match counts on a fixed schedule. Automated traffic changes composition over time, and a threshold that was appropriate at deployment can become either permissive or aggressive without any configuration change.

Give support staff a documented path for a suspected false positive: capture the Ray ID, locate the event, read the matched rule and the score, and decide whether to add a scoped exemption or adjust the threshold.

Correlate bot policy changes with business metrics rather than with bot analytics alone. A drop in blocked requests can mean the policy worked or that the traffic moved to an unprotected endpoint.

Monitor for displacement. When a widget-protected or rule-protected path becomes expensive for an attacker, activity commonly moves to an adjacent endpoint, such as a mobile API or a legacy path. Include those in the review.

Where Logpush is available, export bot fields with request logs so that analysis is possible outside dashboard retention windows.

Known caveats

• Verified bot status does not create an automatic exemption. Without an explicit allow or skip rule ordered before enforcement rules, a verified crawler can be blocked by your own configuration.
• The bot score is a likelihood, not a verdict. Treating a score of 1 as a proven bot and 99 as a proven human will produce policy that is wrong at the margins.
• Bot Fight Mode on Free plans challenges automation indiscriminately and commonly breaks monitoring and API clients on mixed-purpose zones.
• Challenge actions on API endpoints fail non-browser clients rather than filtering them.
• Scores may be absent on cached or static resources; rules must handle field absence.
• Enterprise entitlement is required for the score fields. A configuration exported from an Enterprise zone will not deploy unchanged to a lower plan.
• Controls that block crawlers used for model training do not alter what a third party publishes about its crawling behaviour, and they do not retroactively affect content already collected.

Interoperability

Bot fields are consumed by WAF custom rules and rate limiting rules in the ruleset engine, which is the supported enforcement path for Bot Management.

Turnstile can be placed on specific forms to verify a session, and on proxied zones can issue pre-clearance so that a verified session is not challenged again by bot rules.

Transform rules can add a header carrying the bot score to origin requests, allowing the application to apply its own logic, for example holding an order for review rather than rejecting it.

Where a request is blocked by a bot rule, it does not reach a Worker, because the security phases execute earlier in the request pipeline.

Bot analytics and WAF Security Events are separate views over the same request stream; a request challenged by a bot rule appears in both.

FAQ

How is a verified crawler allowed through an otherwise strict policy? Add a rule matching cf.bot_management.verified_bot with a skip or allow action and order it before the enforcement rules. Verified status alone does not exempt the request.

Can search crawlers and crawlers used for model training be treated differently? Yes. They are classified separately, so distinct policies can be written for each category.

Does classification work against attackers using residential proxies and real browsers? Address reputation contributes less against such clients, while behavioural, fingerprint and model-derived signals continue to contribute. Expect a residual false negative rate and monitor downstream effects rather than relying on classification alone.

References

• https://developers.cloudflare.com/bots/, retrieved 2026-08-28.
• https://developers.cloudflare.com/bots/concepts/bot-score/, retrieved 2026-08-28.
• https://developers.cloudflare.com/bots/concepts/bot/, retrieved 2026-08-28.
• https://developers.cloudflare.com/bots/plans/, retrieved 2026-08-28.
• https://developers.cloudflare.com/bots/bot-analytics/, retrieved 2026-08-28.
• https://developers.cloudflare.com/waf/custom-rules/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-challenges/, retrieved 2026-08-28.

Content snapshot: 2026-08-28.

Changelog