Webflow form spam: what the platform does about it

Where does a Webflow form submission go?

According to Webflow’s help, you choose, form by form, where the submission goes:

• to Webflow, which keeps it in the site settings, under “Forms”;
• into a notification email;
• to a webhook (an outside address) or a connected app;
• to a custom action: the form sends straight to an address you give, without going through Webflow.

With spam filtering on, Webflow sets aside the submissions it judges unwanted. A custom action cannot be combined with keeping submissions at Webflow or with notifications. This article says of Webflow only what its public help says; those pages and their menus change: check in your own account. The help also advises putting a way to reach you in the form’s error message, an email address for example.

What does Webflow offer against spam?

The help sorts the means into four methods:

• The reCAPTCHA field: a form element that asks the visitor to declare themselves human. The help admits that it can harm the visitors’ experience and be circumvented by more advanced bots.
• Bot blocking: a site setting, for all forms. According to the help, it analyses mouse movements, inputs and other signals to block the submissions of bots; the submit button stays disabled while the protection loads.
• Spam filtering: another site setting, which examines the data sent to filter out unwanted submissions.
• The trap field (honeypot): a hidden field, with code on your side to discard the submissions where it is filled in.

The two settings are in “Site settings”, under “Apps & Integrations”; the help gives the exact name of the entry. No page read gives a figure for effectiveness: the effect on your form is seen on your own submissions.

What does Webflow’s reCAPTCHA field require?

According to the help, the field is placed in a form; it describes the checkbox version. You register your site with the provider of the service, which gives you a site key and a secret key, to paste in the site settings. Before turning it on:

• turning it on applies to the whole site: a form without a reCAPTCHA field can no longer be submitted, from the moment the setting is saved, even without republishing. Add the field to every form first;
• with a custom action, or on an exported site, the native integration does not work as expected: you have to wire the check yourself, following the provider’s guide.

The field asks the visitor for a gesture: read the article on CAPTCHA accessibility before making it your main method.

See: CAPTCHA accessibility: what the WCAG and the W3C say · Replacing reCAPTCHA: what to check before you switch

How do you set up the trap field without bothering a screen reader?

The help describes the technique with an example of code. Its precautions:

• a class name without “hidden” and realistic field names;
• the field hidden by position, opacity or display:none: the help warns that some bots recognise these means, and that the structure may have to change as bots learn;
• tabindex="-1" on the field and aria-hidden="true" on its label, so that it cannot be reached by keyboard and a screen reader does not read it.

The example’s code disables the submit button as soon as the field receives an input. It runs in the page: a program that sends the form without loading it does not trigger it (reasoning on the example, not verified on a Webflow site).

See: Glossary: honeypot · Contact form spam: what to do, measure by measure

What does a native Webflow form not allow?

Defences such as checking the fields, limiting bursts and checking a token are on your server. With a native form, the submission goes to Webflow, not to you, and in the help pages read no setting has your server called before Webflow accepts it. The webhook and the connected app look like it:

• the webhook sends submissions to an outside address, with a secret key to verify the signature of the messages;
• the connected app sends them to a third-party service, in addition to Webflow.

The help does not say that they allow a submission to be refused before Webflow keeps it: not verified. On a native form, a token put in by a script in the page is therefore read by nobody on your side at submission; you can only sort afterwards.

And if you have a server of your own?

The help provides the other route: the custom action. In the form’s settings, you remove the Webflow and notifications destinations, choose “Custom action”, give the address of your server and the method, POST or GET. Your code then receives the submission: it can validate it, check a token, limit bursts and decide what to answer. What you lose, according to the help:

• the submission is no longer kept at Webflow: no more list under “Forms”, no more spam inbox;
• Webflow’s email notifications stop;
• the native reCAPTCHA integration no longer works as expected.

You then maintain that server, its keys and its secrets: a real cost for a showcase site. The measures to put there are those of the article on contact form spam.

See: Contact form spam: what to do, measure by measure

Where Antisy fits in

Antisy is an invisible bot check (sometimes called an “invisible CAPTCHA”), for forms. A tag in the page loads the script; at submission, it puts a short token in the hidden field antisy-token; your server sends this token to Antisy with its secret and reads the answer, allow or deny. There are only these two results, and the answer never gives the reason.

On a Webflow form: Antisy has no native integration with Webflow and no plugin, and the call is made from a server of yours. With a native form, whose submission goes to Webflow, no server of yours receives the submission: Antisy does not protect it. With a custom action, your server can make the call and refuse the submission on deny; you then give up what Webflow does with submissions. The script has not been tried on a Webflow page: not verified.

Access is by waiting list: do not wait for Antisy to act. Antisy does not tell apart solicitations typed by hand, announces no detection rate, and refuses a very slow device that does not finish its computation in time. It adds to the methods above, it does not replace them.

See: Use case: stopping contact form spam · Documentation: which forms the script covers · Glossary: invisible CAPTCHA · Frequently asked questions: what is the difference between Antisy and a CAPTCHA? · The integration guides

Where does Antisy stand?

Access is by waiting list. The API and the dashboard have been in service since 27 October 2026, hosted at Infomaniak in Geneva; no customer is in production yet. The pilot started on 9 November 2026 on our own forms.

See: The pilot · Join the waiting list

Frequently asked questions