Skip to main content
Bots submit forms at scale — scraping fake leads into your database, padding your conversion numbers, or harvesting whatever confirmation page a submission unlocks. Bot protection screens these out before they reach allGood, using a check called Cloudflare Turnstile that runs quietly in the visitor’s browser, usually without them noticing.

​
Prerequisites

  • Access to the Form Processing and Web Edge Sessions settings pages
  • A subdomain already registered and active on Web Edge Sessions — bot protection can’t provision until a domain reaches this stage

​
How it decides who’s a bot

When a form requires a bot check, the script running on your page asks the visitor’s browser to prove it’s a real browser, not automated. Most visitors never see or do anything — the check runs silently in the background. A missing or invalid result gets the submission refused before it’s stored.

​
Two switches, and both have to agree

Turning bot protection on for a form takes two settings, on two different pages:
  • Form Processing → Bot protection — the account-wide switch. Set to None, it cancels the check for every form, no matter what an individual form asks for.
  • The form’s own settings — each form opts in separately. This is off by default.
A check only runs when both are on. If a form isn’t asking visitors to prove they’re human and you expected it to, check the account-wide setting first — it overrides every form’s individual choice.
The Bot protection card, showing how many hosts the widget covers and the public sitekey

The Bot protection card, showing how many hosts the widget covers and the public sitekey.

​
Turn it on

1

Confirm your domain is active

On Web Edge Sessions, confirm the subdomain hosting your form shows State: active, with all four progress steps complete. Bot protection can’t provision on a domain that hasn’t finished this.
2

Sync to provision protection

Still on Web Edge Sessions, click Sync. This is also what extends bot protection to cover a newly added domain — it isn’t provisioned automatically the moment a domain goes active.
3

Turn on the account-wide switch

Open Form Processing, and set Bot protection to on.
4

Opt in the specific form

Open the form’s own settings and turn on its bot-check option.
A bot check only works on a subdomain that’s finished provisioning. If a form requiring a bot check sits on a subdomain that hasn’t, every submission from that page is silently refused. Nothing in the form’s own configuration will look wrong. If a form that requires a bot check refuses all submissions, check this first — before assuming the form itself is broken.
Once both switches are on and the domain has synced, the form should now show as accepting submissions, and a real visitor can submit it without doing anything differently.

​
If a submission is refused

  • Every submission from the form is refused, and nothing else looks wrong. Confirm the form’s subdomain is active and synced — see the warning above.
  • Some submissions succeed and others don’t. This is closer to the check working as intended; an occasional refusal from a slow connection or an older browser is expected, not a sign of misconfiguration.
  • A developer manages your site’s security headers. If your site sets a Content Security Policy, it needs to allow Cloudflare’s challenge domain. Otherwise the bot-check widget never loads, and every submission is refused the same silent way. Loop in whoever manages your CSP; the exact directive is on the developer reference.
If the issue doesn’t resolve, see the Web Edge FAQ.