# Webflow form spam: how to stop it Spam through Webflow forms? Webflow ships bot blocking and spam filtering under Cloudflare Turnstile spam protection, plus a reCAPTCHA field. What each does. Author: Formgong Published: 2026-10-23 Language: en Canonical: https://formgong.com/en/blog/webflow-form-spam/ Webflow has two native switches against form spam, both under Site settings → Apps & Integrations → Cloudflare Turnstile spam protection: bot blocking, which watches behaviour signals and blocks bot submissions on all forms, and spam filtering, which checks the submitted content. They work alongside the older reCAPTCHA field and a custom-code honeypot. Turn on bot blocking first, publish, and know one documented side effect: submit buttons are disabled while bot protection loads. ## Four defences, two of them one switch *Figure: A Webflow site's form settings: Cloudflare Turnstile spam protection with bot blocking and spam filtering toggles, applied to all forms on the site.* Webflow's own article lists the four methods plainly: CAPTCHA systems, bot blocking, spam filtering, and the honeypot technique. They differ in what they judge and what they cost the visitor: Webflow spam defences compared DefenceWhat it judgesVisitor cost Bot blocking (native toggle)Behaviour: “mouse movements, inputs, and other signals”None visible; buttons disabled while it loads Spam filtering (native toggle)The submitted contentNone reCAPTCHA fieldA challenge before submittingWebflow's own caveat: “can negatively impact user experience” Honeypot (custom code)Whether a hidden field got filledNone ## The two native toggles Both live in one place: **Site settings → Apps & Integrations → Cloudflare Turnstile spam protection**. Turn on bot blocking, turn on spam filtering, publish the site; Webflow's article is explicit that each applies to all forms on the site once enabled, and that you can run them alongside reCAPTCHA and each other. Bot blocking “uses AI to analyze mouse movements, inputs, and other signals” and blocks the submissions it attributes to bots. Spam filtering “checks all form data sent on your site” and filters what it classifies as spam. Neither asks the visitor anything, which is why they are the right first move: all defence, no friction. ## The side effect worth styling: the loading submit button Webflow documents one visible consequence of bot blocking: “submit buttons are disabled while bot protection loads.” On a slow connection that is a moment where your button looks broken, and a visitor who clicks during it gets nothing. Webflow's article shows two remedies: style the disabled state in the Style panel, or target the `w-form-loading` class from custom code, for example to swap the label to “Loading…” while protection initialises. If visitors report that the form “sometimes doesn't react”, check this before suspecting spam protection of eating submissions: the button state and a double-click habit explain most such reports on sites with bot blocking enabled. ## reCAPTCHA: the old guard, with Webflow's own warning The reCAPTCHA field predates the native toggles and still works: add the field to a form, wire the keys, and visitors prove themselves before submitting. Webflow's article carries two warnings worth taking seriously. First, the experience cost, in its own words: CAPTCHAs “can negatively impact user experience, and can also be circumvented by more advanced bots.” Second, from Webflow's update notes: once reCAPTCHA is enabled for the site, every form on the site needs the field, or forms without it stop working. With bot blocking available, reCAPTCHA earns its friction only when you can point at spam that got past both native toggles. ## The honeypot, and the spam that walks past everything The honeypot is the classic: a field hidden from humans, so any submission that fills it is a bot. Webflow supports it “with custom code”, per its article, by adding a hidden field and blocking matching submissions. It costs visitors nothing and still catches the dumber half of the bot population. What none of the four stop is the manual spammer: a human pasting link offers into your form passes behaviour checks, captchas and honeypots alike. Against those, content filtering is the only lever, and at some volume you will want the submissions to land somewhere with a spam folder you can review, rather than each one costing an email. ## Or send Webflow forms to a backend with its own filter Webflow forms can post to an outside endpoint, and Webflow's paid-plan form limits are one common reason to do it; spam handling is the other. Point the form at Formgong (the [Webflow setup page](/en/for/webflow/) shows both the webhook route and the plain form route) and submissions get a server-side spam filter, a honeypot, optional Cloudflare Turnstile, and a dashboard inbox with a Spam folder, so a false positive is restored with a click instead of lost. Email and Telegram delivery on every plan; the free plan takes 1,000 submissions a month. The wider spam playbook, including the time-trap check and what filters actually look at, is in [how to prevent form spam without a captcha](/en/blog/contact-form-spam-without-captcha/). ## Quieter inbox? Did the two toggles do it, or is something still getting through that we should add here? Write to [support@formgong.com](mailto:support@formgong.com) and tell us what you tried. The cases readers send are how these guides get better. ## Frequently asked questions ### How do I stop spam on Webflow forms? Turn on Webflow's two native toggles under Site settings → Apps & Integrations → Cloudflare Turnstile spam protection: bot blocking (behaviour analysis) and spam filtering (content checks). Both apply to all forms once enabled. The reCAPTCHA field and a custom-code honeypot remain as additions. ### Does Webflow bot blocking affect real visitors? One documented effect: submit buttons are disabled while bot protection loads, so on slow connections the button is briefly inert. Webflow suggests styling the disabled state or the w-form-loading class so the moment looks intentional. ### Do I need reCAPTCHA if bot blocking is on? Usually not as the first move: Webflow's own docs warn that CAPTCHAs can hurt user experience and can be circumvented by advanced bots. Add the reCAPTCHA field only for spam that demonstrably gets past bot blocking and spam filtering, and remember every form on the site then needs the field. ### Why does spam still arrive with all protections on? Human spammers pass behaviour checks, captchas and honeypots, because they are not bots. Against them only content filtering helps, and routing submissions to an inbox with a reviewable spam folder keeps the junk out of your email without losing real messages. ## Sources and documentation - [Webflow Help: Prevent spam in form submissions](https://help.webflow.com/hc/en-us/articles/34277758554771-Prevent-spam-in-form-submissions) - [Webflow: Add a reCAPTCHA field to your forms](https://webflow.com/updates/add-a-recaptcha-field-to-your-forms) - [Webflow](https://formgong.com/en/for/webflow/) [Get a form key](https://formgong.com/en/#top)