Webflow form spam: what the settings do, and what they miss

Four defences, two of them one switch

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:

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

Quieter inbox?

Did the two toggles do it, or is something still getting through that we should add here? Write to support@formgong.com and tell us what you tried. The cases readers send are how these guides get better.