ChatGPT
Perplexity
Claude
Super Bot Fight Mode (SBFM) with default settings is too aggressive for any site with real customer traffic. Run it in challenge mode (not block) for at least two weeks while you watch the bot analytics, then tune by endpoint: definitely-automated traffic gets blocked on pricing and search APIs, likely-automated gets a managed challenge on login and checkout, and verified bots get explicitly allow-listed before anything else. The default global “block everything automated” setting catches scrapers but also catches your monitoring, your payment provider’s webhook retries, and occasionally Googlebot. Endpoint-specific rules are the difference between a working bot strategy and a stream of customer complaints.
This is the production guide most public documentation does not give you. The Cloudflare docs explain what SBFM does. They do not tell you the threshold profile that works for a booking platform, or how to triage the inevitable false positive when a real customer reports they got blocked.
What is Super Bot Fight Mode and how does it actually classify traffic?
SBFM is Cloudflare’s bot management product for Pro and Business plans, sitting one tier below the full Enterprise Bot Management product. It scores every request and bucket-classifies it into one of four categories: verified bot (Googlebot, Bingbot, monitoring services, etc., on Cloudflare’s curated list), likely automated (bot-like signals but not certain), definitely automated (high-confidence bot fingerprint), and likely human.
The configuration surface gives you one toggle per category: allow, managed challenge, JavaScript challenge, block. That is the limit of the UI. To get more granular than that, you write custom WAF rules that reference the bot score.
Two atomic facts worth bookmarking: SBFM lives on Pro and Business plans. Enterprise Bot Management exposes the raw cf.bot_management.score field (0-99, lower = more bot-like) in custom rules, which is what unlocks endpoint-specific tuning.
Why are the default settings too aggressive for production?
Because Cloudflare ships SBFM with “block definitely automated” on by default, and “definitely automated” includes more than just scrapers. The default rules also catch:
- Your own monitoring tools (Pingdom, UptimeRobot, Datadog Synthetics) unless they happen to be on the verified bot list
- Payment provider webhook retries during settlement windows
- Headless browsers used for legitimate testing or RSS aggregation
- Some mobile carrier proxies that compress traffic
- Search engine crawlers from smaller providers not on the verified list
- Internal automation hitting your own APIs
In the first 72 hours after a default-settings rollout, expect to find one or two of these in your block logs. The fix is not to turn SBFM off. The fix is to allow-list deliberately and tune by endpoint.
How should I tune SBFM for a production booking or e-commerce site?
The right pattern is not one global rule. It is a stacked set of rules in the WAF that read the bot score and apply different actions based on what the endpoint is doing.
Step 1: Allow-list verified bots first. Before any block rule, ship a custom WAF rule that allows verified bots through. Expression: cf.client.bot. Action: skip remaining rules. Without this you will lose search rankings within a week. Read the Cloudflare verified bot documentation for the current list.
Step 2: Block definitely-automated on read-only public endpoints. Pricing, search, listing, fleet availability, and any other endpoint that exposes data competitors might want gets the hard block. Expression: (http.request.uri.path in {"/api/pricing" "/api/search" "/api/listings"}) and cf.bot_management.verified_bot eq false and cf.bot_management.score lt 30. Action: block.
Step 3: Managed challenge on sensitive write endpoints. Login, OTP, password reset, booking creation, checkout. These need a challenge for likely-automated traffic, not an outright block, because false positives here cost conversions. Expression: (http.request.uri.path in {"/api/login" "/api/otp" "/api/booking"}) and cf.bot_management.verified_bot eq false and cf.bot_management.score lt 60. Action: managed challenge.
Step 4: Log everything else. Set a permissive logging rule for likely-automated traffic on the rest of the site so you can see the noise without blocking it.
This stacked pattern requires Enterprise Bot Management for the score field. On Pro and Business, you are limited to the category toggles, which means you have to choose between block and challenge globally rather than per endpoint. That is a real limitation. For high-pressure use cases, the upgrade pays for itself.
What is the right false-positive triage workflow?
When a real customer reports they were blocked, the triage path is:
- Open Cloudflare Security Events, filter by the customer’s IP address and the last 24 hours
- Identify the event that blocked them; note the rule and the bot score
- Decide whether the block was correct (they tripped a real signal) or a false positive (their behaviour was legitimate)
- If false positive: write a Skip rule scoped narrowly to the specific signal that caused the block. Position it above the block rule in the rule order
- Document the rule in the runbook with the reason
The mistake to avoid: do not loosen the global threshold to fix a single false positive. That dilutes the protection for every other endpoint. Always handle false positives with a narrow Skip rule, not a global tweak.
The Cloudflare docs on handling false positives in bot management cover the mechanics. The bot management production guide from Brixio is worth reading for endpoint-specific JA4 fingerprint analysis if you are on Enterprise.
What does SBFM actually catch in production?
On a typical consumer-facing site with no prior bot protection, expect 25-45% of incoming requests to be automated. Scrapers, vulnerability scanners, credential-stuffing botnets, content aggregators, AI training crawlers, and competitor price monitors all show up in that traffic.
After tuning SBFM with the stacked pattern above, the share of automated traffic reaching origin drops sharply. On the Saudi mobility platform we documented, automated traffic to origin fell from 38% of total requests to under 3% within two weeks of tuning. Origin CPU usage on the listing pages dropped accordingly. The pricing data competitors had been scraping in near real time degraded to a level where it stopped affecting their rate decisions.
A separate observation worth banking: most scrapers will reroute through residential proxy networks once they hit a block. Plain IP rate limits do not work against this. SBFM does, because it scores behaviour and fingerprint, not just IP reputation.
When should I upgrade from SBFM to Enterprise Bot Management?
Three signals:
- You need endpoint-specific scoring profiles (different thresholds for
/api/pricingvs/api/booking) - You need the raw bot score field in custom rules and not just the category toggles
- You need JA3 or JA4 fingerprint reputation analysis to catch advanced scrapers
If you are running a high-pressure consumer site (booking, e-commerce, fintech) with significant scraping or credential-stuffing exposure, Enterprise Bot Management is usually worth it. For most other sites, SBFM tuned correctly is enough.
Common mistakes to avoid
Turning SBFM straight to block mode on day one. You will block customers. Run challenge for two weeks, watch the bot analytics, then promote to block per-endpoint.
Skipping the verified bot allow-list. Lost search rankings within a month. Always allow cf.client.bot first.
Using one global rule for the whole site. Different endpoints have different abuse profiles and different tolerance for false positives. Per-endpoint rules.
Fixing false positives by loosening the global threshold. Use narrow Skip rules instead. Keep the protection strong everywhere else.
Forgetting about your own monitoring. Pingdom, UptimeRobot, Datadog Synthetics, and any in-house monitoring need explicit Skip rules. Otherwise you will start getting “site down” pages that are actually SBFM blocking your prober.
Not setting up Logpush. SBFM events are visible in Security Events for 24 hours by default. For incident investigation and trend analysis, push the logs to S3, BigQuery, or a SIEM. Without retention, you cannot prove what happened during last month’s attack.
Related reading
For the broader WAF and edge configuration that SBFM sits inside, see our Cloudflare WAF setup guide for booking and payment platforms. For a side-by-side decision on whether Cloudflare or AWS bot management fits your stack, see Cloudflare WAF vs AWS WAF in 2026. For an end-to-end production deployment with bot management as part of the stack, the Saudi mobility platform case study covers the controls and the numbers.
Need Help Tuning Super Bot Fight Mode for Your Production Site?
SBFM in default mode is a starting point, not a finished configuration. The endpoint-specific tuning, the verified bot allow-list, the false-positive triage workflow, and the decision on whether to upgrade to Enterprise Bot Management are all judgement calls that depend on your traffic, your threats, and your conversion sensitivity.
Tasrie IT Services provides comprehensive Cloudflare managed services to help you:
- Tune Super Bot Fight Mode or Enterprise Bot Management with endpoint-specific rules calibrated against your real traffic, not vendor defaults
- Stop scraping, credential stuffing, and OTP abuse without losing legitimate aggregator and search engine traffic
- Hand over a runbook so your team can triage false positives and adjust thresholds without our involvement
We have tuned bot management for booking, e-commerce, and fintech workloads across Saudi Arabia, the UAE, and the UK, including the deployments documented in our cybersecurity services practice.