Spam bots: what the usual defences actually cost

In moderation. Every submission that reaches a person costs attention, and the ones that reach visitors before removal cost more.

In your mail reputation. This is the consequence most sites discover late. A contact form that sends mail on submission becomes a way to send mail through your domain, and where that mail is unwanted, the receiving side attributes it to you. Delivery problems then appear on messages that matter, disconnected in time from the form that caused them.

In your published content. Comment sections and reviews filled with links describe your site to every visitor and to anything that reads it.

Three, in order of reliability.

Interaction, not just submission. A person who filled a form touched its fields: focus moved, keys were pressed, corrections happened. A submission arriving with no evidence of any of that was assembled rather than filled. This is the strongest available signal because it describes the process rather than the result.

Content patterns across submissions. Identical structure with rotated details, links in fields that have no reason to contain them, and the same text arriving at many unrelated sites. Any single one is weak; together they are strong.

Rate and breadth per source. Several submissions to different forms from one place, or a submission to a form nobody links to any more, which is a form that a person would not have found.

The standard technique adds a field a person will never fill and treats anything that fills it as automation.

The mechanism is sound and its limits are specific.

Browser autofill fills it. A field that looks like a name or an email to software gets completed by the same software your customers rely on, and they receive a rejection with no explanation.

Assistive technology can reach it. A field hidden visually may still be announced to someone using a screen reader, who will fill it in because they were asked to. Rejecting that submission excludes the visitors least able to work around it, which makes implementation an accessibility question and not only a technical one.

It only catches automation that fills everything. Anything targeting your site specifically will submit the fields your form uses.

None of this makes honeypots useless. It means the field must be built so that neither autofill nor assistive technology treats it as real, and that failing it should lower a score rather than refuse a submission outright.

The other standard technique measures how long a form took to fill and rejects anything faster than a person could manage.

Two populations break it. Password managers and autofill complete a form instantly, which is the behaviour being penalised. And people who prepared their text elsewhere and pasted it in look identical to a script.

If you use timing at all, treat it as one weight among several rather than as a gate, and never as the sole reason to refuse.

Following the ladder on blocking, applied to submissions.

Accept and hold rather than refuse. A submission that goes to review instead of publication removes the damage without telling a legitimate sender that your site is broken.

Limit per source and per form. Especially on forms that send mail, where the cost of each submission extends beyond your site.

Challenge on the paths that matter, which usually means the form that produces outbound mail rather than every form you have.

Require an account for anything published. The most effective measure where it fits the product, and the least acceptable where it does not.

Never fail silently. Whatever you do, a rejected human should see that something happened and how to reach you another way. A form that appears to submit and quietly discards the message is the worst outcome available, and it is what most naive implementations produce.

The obligatory section, and here it decides the design.

Anyone using autofill or a password manager, which is a large share of your visitors and includes most people on phones.

People using assistive technology, as described above.

Anyone who wrote their message elsewhere and pasted it, which correlates with people writing carefully or in a second language.

Your own testing. Internal submissions from a script or a monitoring check look exactly like the traffic you are filtering.

The failure mode is quiet in every one of these cases: the visitor believes they contacted you, and you never learn that they tried. That asymmetry is why the recommendations above prefer holding over refusing.

The assumption behind the question leads people to skip defences entirely.

Submissions are not sent because your site was chosen. Forms are found the way any page is found, in bulk, and the cost of submitting to one more is close to nothing. Being small changes how much spam you receive and not whether you receive it.

The second reason is that many submissions are not aimed at your visitors at all. A form that sends mail is useful to a sender regardless of whether anyone reads the comment, and a registration form that creates accounts is useful regardless of whether the site has traffic.

That is the practical argument for handling this on forms that produce outbound effects first, whatever the size of the audience.

Bridge WAF inspects requests before they reach your application: submissions matching the spam-bot rules are recorded in monitor mode and refused in block, and rate limiting per domain bounds how hard a form can be hammered. Requests that never arrive cost nothing to moderate. What the platform cannot decide is your form's own design: whether a rejected sender is told, whether a suspect submission is held rather than dropped, and whether a hidden field is reachable by assistive technology are choices in your markup. See what the platform offers at Bridge CDN.