Webflow gives you four ways to stop form spam, and most sites only need two of them switched on. This post covers where each setting lives, why some spam still arrives once they are on, and what changes if you point the form at an external endpoint such as ours instead. We sell that endpoint, so the honest version includes the cases where you should not use it. Webflow details below are from its help centre as of 24 October 2026.
Webflow's four built-in defences
Three of them are site-level settings under Site settings > Apps & Integrations, and each one applies to every form on the site once it is enabled. The fourth is something you build yourself.
- Spam filtering. Checks the data in each submission and routes anything it judges to be spam into a separate spam inbox in Site settings > Forms, where you can review it. It sits under Cloudflare Turnstile spam protection and is on by default for new sites, so on an older site check that it is actually switched on.
- Bot blocking. Also under Cloudflare Turnstile spam protection: turn it on, then republish. Webflow describes it as using AI to analyse mouse movements, inputs and other signals to tell bots from people. Submit buttons are disabled while it loads, so style the button's disabled state, or visitors briefly see a button that does nothing.
- reCAPTCHA. A Google reCAPTCHA v2 checkbox that you add to a form as an element, with your own site and secret keys pasted into Site settings > Apps & Integrations > reCAPTCHA validation. Turning validation on enforces it on every form on the site the moment you save, and any form without a reCAPTCHA element then fails to submit. Webflow's own guidance notes that captchas cost user experience and that more advanced bots get round them.
- Honeypot. A hidden input that people never see and simple bots fill in. Webflow's recipe is a Box holding an input hidden with a class, plus a script that disables the submit button when that input has a value. The script is custom code, and Webflow's Code Embed element needs a paid Workspace or an active Site plan.
Webflow's spam articles do not tie spam filtering, bot blocking or reCAPTCHA to a particular plan. The honeypot is the only one with a plan requirement, and only because of the script.
When the built-in settings are enough
Turn on spam filtering and bot blocking, republish, and give it a week. For a typical brochure site on a paid Site plan that is the right amount of protection: submissions are stored in Webflow, flagged spam goes to its own inbox instead of vanishing, and paid Site plans have no submission cap for a spam wave to use up. If the junk stops, stop there. Add reCAPTCHA only if bot traffic is still getting through bot blocking, because the checkbox sits in front of every real visitor too.
The free Starter plan is different. Webflow caps a Starter site at 50 form submissions in total, a limit that never resets, and its help pages do not say whether submissions caught by the spam filter count toward it. On a Starter site, a burst of bot submissions may cost you part of an allowance you cannot get back, and Webflow's documentation does not settle it either way.
Why spam still gets through
Each defence answers a narrower question than whether a submission is spam, and the spam that arrives is whatever falls outside all of them.
- Bot blocking and reCAPTCHA judge the visitor, not the message. A person pasting an SEO or redesign pitch into your form passes both, because a person is exactly what they are built to let through.
- The honeypot in Webflow's guide runs in the browser. It works by disabling the submit button, so it only stops bots that load the page, run its JavaScript and then click. A script that sends the form data straight to the form's endpoint never meets it.
- Spam filtering is the one layer that reads content, and it is a single switch. Webflow's help describes nothing to tune, such as a list of your own words or domains to block. A pitch it does not recognise goes to the main inbox, and there is nothing to adjust.
The hardest case for any filter, ours included, is a polite, link-free message from a real address offering to rebuild your site. It is grammatical and plausible, and the only thing wrong with it is what it is asking for.
Pointing the form elsewhere: what Webflow stops doing
To have submissions handled outside Webflow, use the Custom action option in the form's Send to settings. Select the form, open the Settings panel, remove Webflow and Email notifications from Send to (Webflow will not combine them with a custom action), add Custom action, enter the endpoint URL and choose POST. Webflow writes those into the form's action and method attributes.
Webflow's help is explicit about what that changes:
- Submissions are not sent to or stored in Webflow, so nothing from that form appears in Site settings > Forms.
- Webflow sends no notification emails for that form.
- Its native reCAPTCHA integration stops working: the form submits whether or not the box is ticked. Webflow's advice is to integrate reCAPTCHA yourself using Google's guide.
- Spam filtering has nothing to check, because the submission never reaches Webflow. Webflow does not say whether bot blocking still runs on a custom-action form, so do not count on it.
- For the same reason the Starter plan's 50-submission cap stops applying, and the form keeps working if you export the site, where Webflow's own form handling does not run at all.
A custom action is therefore a trade. You give up Webflow's whole form pipeline, spam handling included, and whatever receives the form has to do that job instead. If all you actually want is the data in another tool while Webflow keeps processing submissions, Webflow's Webhook and Apps destinations do that without removing anything.
What happens when the form posts to WebForms
This is the part we built, so here is what happens to a submission from a Webflow form, in order:
- Outright rejects first. The honeypot field is checked on our server, not in the visitor's browser, so it catches scripts that never load your page. If you add the optional time trap (a hidden field stamped by one line of script, so custom code on Webflow), a form completed implausibly fast is rejected too. A rejected submission gets the same success response as a real one, because telling a bot it was caught tells it what to change.
- Scored signals next: throwaway email domains, links packed into a message, and domains or keywords you choose to block on that form. If you lock the form to your own domains, a submission arriving from anywhere else adds to the score.
- Then an AI classifier reads the message itself, on every plan including the free one, and on submissions every other signal scored at zero. That is the layer aimed at the polite redesign pitch, because it judges what the message says rather than who sent it.
- Anything over the spam threshold is quarantined: stored and readable in the dashboard, never delivered to email or any other destination, and not counted toward your monthly submissions.
Quarantine is the decision that matters most for a site that cannot afford to lose a lead. Webflow makes a similar choice with its spam inbox. Ours sits behind a filter that reads content, which means it will sometimes be wrong, and when it is, the real enquiry is still stored for you to read and answer. It is just not delivered.
Send to Remove: Webflow, Email notifications Add: Custom action URL: https://send.webforms.to/wft_your_key Method: POST Field names (each input's Settings > Name) name, email, message Honeypot One more Input, inside a Box hidden with a class Name: _gotcha Thank-you page Set the form's redirect URL in the WebForms dashboard
Two Webflow details make this work on any plan. The honeypot needs no custom code: an ordinary Input inside a Box you hide with a class (Webflow's guide suggests position, opacity or display none) does the job, with tabindex set to -1 as a custom attribute so keyboard users never land in it. After publishing, view the page source and check that the input's name attribute reads exactly _gotcha. And Webflow's success message belongs to its own form handling, so plan for a thank-you page: set it as the form's redirect URL in the WebForms dashboard, which is free on every plan, or as a hidden _redirect field if you have Code Embed.
Which one to use
- Paid Site plan with occasional junk: turn on spam filtering and bot blocking and stay on Webflow's forms. That is enough for most sites, and you keep the spam inbox.
- Spam that reads like real enquiries keeps arriving with both on: that is the content problem, and it needs a filter that reads the message. Pointing the form at a backend with one is a settings change, and moving back is the same change in reverse.
- Starter site, or a site you plan to export: a custom action gets you past both the 50-submission cap and the export problem, but bring spam handling with it, because Webflow's goes away.
- Submissions need to reach Slack, Discord or a webhook with a record of every delivery attempt: that is what WebForms is for. Email delivery is on the free plan, at 300 submissions a month; Slack and the other destinations start at $5 a month.