> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allgoodhq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Turn on bot protection for a form

> Stop automated submissions from reaching a form, using the bot check built into Web Edge.

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](/mk/settings/web-edge/sessions-setup) — 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.

<Frame caption="The Bot protection card, showing how many hosts the widget covers and the public sitekey.">
  <img src="https://mintcdn.com/allgoodtechnologyinc/bf1LRHwyriZvgDxT/images/mk/web-edge/setup-bot-protection-card.png?fit=max&auto=format&n=bf1LRHwyriZvgDxT&q=85&s=b4a1f3de92e2c754d3fd3061b17afcd6" alt="The Bot protection card, showing how many hosts the widget covers and the public sitekey" width="1105" height="163" data-path="images/mk/web-edge/setup-bot-protection-card.png" />
</Frame>

## Turn it on

<Steps>
  <Step id="confirm-domain-active" title="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.
  </Step>

  <Step id="sync-web-edge-sessions" title="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.
  </Step>

  <Step id="turn-on-account-wide" title="Turn on the account-wide switch">
    Open **Form Processing**, and set **Bot protection** to on.
  </Step>

  <Step id="opt-in-the-form" title="Opt in the specific form">
    Open the form's own settings and turn on its bot-check option.
  </Step>
</Steps>

<Warning>
  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.
</Warning>

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](/mk/developer/web-edge/bot-protection).

If the issue doesn't resolve, see the [Web Edge FAQ](/mk/settings/web-edge/faq).

## Related articles

* [Set up Web Edge Sessions for your site](/mk/settings/web-edge/sessions-setup)
* [Web Edge FAQ](/mk/settings/web-edge/faq)
* Need the exact mechanics — sitekey behavior, CSP directives, building the request yourself? See the [developer reference](/mk/developer/web-edge/bot-protection).