Form spam protection: stop bot submissions automatically
Every public form is checked for automated submissions before anything is stored. It is on by default with nothing to turn on, it costs nothing on any plan, and almost every respondent goes through it without seeing a thing. What you choose is what respondents see — and, on a paid plan, whether a submission that fails the check is refused or kept for you to review.
What runs, and when
When someone presses Submit on a public form, Seagit asks Cloudflare Turnstile whether the submission looks automated. For an ordinary visitor this takes a fraction of a second and shows nothing at all. If it looks like a bot, the submission is refused before it is stored — before it reaches your responses, your CSV export, or any destination you have configured.
There is nothing to turn on. It applies to every public form, on every plan, including forms you published before this existed. What you can configure is which Cloudflare widget your respondents are checked against, and — on a paid plan — whether a submission that fails the check is refused or kept for you to review. See below.
Why it is free on the free plan
What your respondents see
In the great majority of cases, nothing. The check is invisible and runs as part of pressing Submit. With the default widget, when something about the request looks automated — an unusual browser, a stripped-down environment, traffic from an address with a poor reputation — a small Cloudflare widget appears and asks for a single click. There are no traffic lights and no fire hydrants.
If someone leaves a long form open for a while and then submits, the check is performed fresh at that moment, so nothing expires underneath them. The same applies to a form filled in twice in a row: each Submit is checked on its own.
Three options, under Settings → Advanced
A form is set to one of three things. Checkbox when needed is the default and the one described above: most people see nothing, and anyone Cloudflare is unsure about gets a single click to prove they are human before their submission goes through.
Invisible shows nothing to anybody, ever — no checkbox appears under any circumstance. The trade-off is real and worth stating plainly: a respondent Cloudflare misjudges has no click to fall back on, so they are refused with no way to prove otherwise. Choose it only if a form with zero visible friction matters more to you than never losing a genuine response.
The invisible widget also shows no Cloudflare branding and no terms of its own — nothing that would tell a respondent it ran at all. If you embed a form set to invisible on your own site, that processing happens on your page with no indication to your visitors, which is a thing you may need to disclose in your own privacy policy. See “Privacy” below for what Turnstile actually processes.
None — accept everything, flag suspicious for review is the paid third option, and it is the answer to the cost the invisible widget carries: nobody is refused at all. A submission that fails the check is kept instead of turned away, so a real person Cloudflare misjudged does not lose their answers. It always uses the invisible widget — there is nothing to challenge when nobody is being refused — so choosing it switches the widget for you.
Keeping suspected spam for review
With the third option set, a submission that fails the check is stored and set aside rather than refused. The person who sent it sees exactly what a clean submission sees, and is never told which happened — otherwise a bot could learn which of your forms quarantine and which refuse.
A response set aside this way:
- is kept out of your ordinary response list, behind a Suspected spam toggle on the form's responses screen that shows how many are waiting;
- does not use a response slot — it cannot push out real answers, which is the same reason the check is free on the free plan;
- is not sent anywhere: no webhook, no Slack, Discord, Teams, Google Chat, Telegram, Airtable, Notion or Google Sheets, no email notification. It is not a delivery that failed; it is one that was never attempted.
Each row in that list offers two ways out. Unflag only moves it into your responses and leaves it there. Unflag and send also delivers it to every destination you have configured, as though it had arrived cleanly. Nothing is re-checked — the original check is long over and cannot be repeated — so what unflagging records is your own judgement that the response is real. If you would rather not keep it, delete the row as you would any other.
Quarantine shares your response limit
Flagged responses use the same limit as ordinary ones rather than sitting beside it, so a form never stores more than the number you pay for. What keeps a flood of spam from crowding out real answers is that spam yields: once the form is full, storing anything new deletes the oldest suspected-spam response to make room. A real response is never deleted for one.
So suspected spam can occupy spare room, and gives it back the moment a real answer needs it. A form that is full of genuine responses is simply full, exactly as it would be without this feature turned on. The dropping happens quietly and on purpose: a notification about suspected spam nobody has read is the noise this feature exists to remove.
If your plan lapses, or you set the form back to refusing, no new responses are flagged and respondents are refused again exactly as before — your setting is not rewritten by a billing change, and nobody is turned away mid-subscription. What is already flagged stays visible and you can still unflag it, and nothing new joins it. It is not frozen, though: flagged responses are still the first thing dropped to make room, so if the form fills with real responses the oldest of them will go. Work through it rather than leaving it indefinitely.
If a submission is refused
This is what happens on the two blocking options — the default, and invisible. A form set to keep suspected spam for review never reaches it: nobody is refused there.
The respondent is told, and their answers stay on the screen. Nothing they typed is lost, and pressing Submit again runs a fresh check. That matters more than the protection itself: a security control that costs someone twenty minutes of writing is worse than the spam it prevents.
If the check cannot run on our side, your form still works
When our server cannot verify — Cloudflare is unreachable from it, the call is slow, or our secret is wrong — the submission is accepted rather than refused. A verification outage on our side must never become a collection outage for you. The trade is that some spam may get through while that lasts, which is the right way round.
That cover does not extend to the respondent’s own browser. If theirs cannot load Cloudflare at all — a privacy extension, an ad blocker, a corporate network filter — their submission arrives with nothing to verify, and we cannot tell it apart from a bot that sent nothing either, so it is refused. It is uncommon, and their answers stay on screen: pressing Submit again is the thing to try, since the script is often merely slow. A blocker left switched on will keep refusing, so allowing challenges.cloudflare.com is the fix.
Embedded forms are covered too
An embedded form runs inside a frame served from forms.seagit.com, so it carries the same protection onto whatever site it is embedded in. There is nothing to add to your page, no key to paste into your own HTML, and nothing that has to be kept in step when you move the form to a different site. See embedding a form for the two lines of markup that put it there.
What this does not do
Turnstile stops automated submission. It does not stop a person filling your form in by hand with nonsense, and Seagit still has no rate limit and no honeypot field. If you are getting junk that is clearly hand-typed, the tools that help are closing the form on a date, capping its responses, or protecting it with a password — all under Features. Keeping suspected spam for review does not help here either: it decides what happens to a submission the check already failed, and hand-typed junk passes the check.
It is also not a content filter. A real person can send you a real submission you would rather not have had, and nothing here reads what was written. Because every response lands in one place and exports to CSV, sorting that out is a spreadsheet task rather than an inbox one.
Privacy
To run the check, Turnstile processes the respondent's IP address, a TLS fingerprint and User-Agent, and the sitekey together with the origin it ran on. It sets no tracking cookies and does not profile your respondents for advertising. That is the main reason it was chosen over the alternatives: the people filling in your form never chose to use Seagit, and handing them to an ad network would be a poor way to repay that.
Our own privacy policy covers this processing and links to Cloudflare's Turnstile Privacy Policy. If you embed a form on your own site, particularly one set to the invisible widget, this same processing runs on your page — you may need to disclose it in your own privacy policy, since we cannot do that on your behalf.
Common questions
- Do I need to turn this on?
- No. Every public form is protected as soon as it is published, and the protection itself cannot be switched off — one an owner can forget to enable is one most forms will not have. What you do choose, under Settings → Advanced, is one of three options: a checkbox when Cloudflare is unsure, an invisible check, or — on a paid plan — an invisible check that keeps a suspected submission for review instead of refusing it.
- Will my respondents have to solve a puzzle?
- Almost never. The check runs in the background when Submit is pressed and passes silently for ordinary visitors. With the default checkbox widget, a challenge appears only when the submission looks automated, and it is a single click rather than a picture puzzle. The invisible widget never shows one at all.
- Does it cost anything, or need a plan?
- No. It is free on every plan, including the free tier. It protects your response cap as much as your inbox, so charging for it would make the wrong forms the unprotected ones.
- What happens to a submission that fails the check?
- The check itself is identical on every plan — free or paid, every public form is verified the same way. What differs is what happens next to a submission that fails it: on the free plan it is refused and nothing is stored. On a paid plan it can instead be kept for review rather than refused, so a respondent who was wrongly caught is not simply lost. That is a storage decision, not a stronger check — a flagged submission is a row we keep until you look at it, which is the thing being paid for. Either way the person who submitted it is never told which happened.
- Where do flagged responses go, and how do I keep one?
- They are on the form’s responses screen, behind a “Suspected spam” toggle that shows how many there are. They are kept out of your ordinary list, and they are not sent to any destination you have configured. Open the toggle, and each row offers “Unflag only”, which moves it into your responses, and “Unflag and send”, which also delivers it to your destinations as though it had arrived cleanly. There is no re-check involved: unflagging records your judgement that the response is real.
- Is the quarantine unlimited, and what if I stop paying?
- It is not unlimited, and it does not add to what you pay for. Quarantined responses share your plan’s response limit rather than sitting beside it, and they are the first thing dropped to make room: once the form is full, storing anything new deletes the oldest suspected-spam response, silently. A real response is never dropped for one, so spam can use up spare room but can never cost you a response you paid for. If you stop paying, the responses already flagged stay visible and you can still unflag them — what stops is new ones being kept, and those are refused instead.
- Does it work on embedded forms?
- Yes, with no extra configuration. An embedded form runs inside a frame served from forms.seagit.com, so the same protection applies on whatever site it is embedded in.
- What happens if Cloudflare has an outage?
- If the check cannot run on our side — our server cannot reach Cloudflare, or the verification call fails — the submission is accepted rather than refused, and your form keeps collecting. Some spam may get through for the duration. The one case that is not covered is a respondent whose own browser cannot load Cloudflare, usually a privacy extension or a corporate network filter: their submission arrives with nothing to verify, which is indistinguishable from a bot, so it is refused. Their answers stay on screen, and pressing Submit again is the thing to try — the script is often merely slow. If a blocker is switched on it will keep refusing until challenges.cloudflare.com is allowed.
- Does this stop all spam?
- No, and it is worth being precise. It stops automated submission, which is the overwhelming majority of form spam. It does not stop a person filling your form in by hand with nonsense, and there is still no rate limit and no honeypot. Keeping suspected spam for review does not change that: it decides what happens to a submission the check already failed, so hand-typed junk passes the check and lands in your ordinary responses either way.
- Does it track my respondents?
- No. Turnstile sets no tracking cookies and does not profile the people filling in your form for advertising. That is the main reason it was chosen over the alternatives.