The spam trap that silently deleted our own leads

Almost every contact form carries a hidden field that humans never see. Bots fill in every input they find; a real visitor cannot fill in something that is not rendered. So if that field arrives with a value, the submission is treated as spam. It is a good technique, it costs nothing, and it avoids inflicting a CAPTCHA on genuine buyers.

The danger is in the failure mode. When a honeypot misfires it does not throw an error — it does exactly what it was built to do, silently, to the wrong person. The visitor sees the same success message as everyone else and goes away believing they have contacted you.

Ours was named website_hp, with the id f-website. That naming is the whole problem, and we chose it ourselves.

Browser autofill does not read your intentions; it pattern-matches on names, ids, labels and autocomplete hints. A hidden field called website looks exactly like the website field a browser has helpfully completed on a hundred other forms. Chrome filled it in. The autocomplete="off" attribute we had set is a request, not a guarantee, and browsers have ignored it for years.

So for an affected visitor the sequence was: fill in the form, press send, see the success panel, leave. On the server, our handler saw a populated trap field, returned {ok:true}, and discarded the submission without writing it anywhere. No error log, no copy, no trace. The analytics event fired too, because the front end could not tell the difference between a real success and a screened one.

That last detail is what made it invisible. Every dashboard said the form was working.

On 22 September we were reading GA4 alongside the server. GA4 reported three generate_lead events from three users. The enquiry log on the server held two records, both of them our own tests (16 and 18 September).

Three lead events, two known tests, zero real enquiries recorded. The gap was not a rounding artefact or an attribution quirk. Either two lead events were bots that had somehow reached a success state, or two people had tried to contact us and vanished. There is no way to recover which, and that is the part worth sitting with.

The general lesson is not about honeypots. It is that a conversion count is only trustworthy when something outside the analytics tool can confirm it. If the only evidence that a form works is the form's own success message and an event fired by the same code path, you have one witness telling you it is reliable.

1. Rename the trap so no browser recognises it. The field is now sx_trap with the id sx-trap — a name that matches nothing in any autofill heuristic — plus the ignore attributes password managers respect. A honeypot should be named after nothing a human ever types.

2. Never discard anything. A tripped submission is now written to a separate log with every field it carried, so a false positive can be read and answered rather than guessed at. The log is blocked from the web and returns 403. Deleting a message because a heuristic disliked it is a decision no form should make on its own.

3. Keep the analytics honest. The response now carries a screened:true flag, and the front end fires generate_lead only when it is absent. Screened submissions are recorded but not counted as leads, so the number in GA4 means one thing again.

All three were tested against the live form on the same day: the trap path returns {ok:true, screened:true}, the submission appears in the spam log, and no lead event fires. The normal path still logs the enquiry and still fires the event.

Reconcile the two sides. Take your lead-event count in analytics for the last ninety days and compare it with the number of enquiries that actually reached a human — inbox, CRM, server log, whatever is authoritative. If the analytics number is higher, something between the button and the inbox is eating submissions.

Inspect the hidden fields. Open the page source and find every input your visitor cannot see. If any of them is named after something a browser knows how to fill — website, url, company, phone, address, name — treat it as a live defect.

Submit the form yourself, with autofill switched on. Not with a clean profile, not in an incognito window. Use a browser that has your real details saved, because that is the condition your buyers arrive in.

Make sure a failure is loud. Whatever your handler does when it rejects a submission, it should leave a record. Silence is the one behaviour you can never audit.

And check what the visitor is told. A success message that appears before the server has confirmed anything is a promise your site cannot keep.

Because it happened on our own site, and because an agency that only publishes its wins is telling you very little about how it works.

Two enquiries — if they were enquiries — were lost while every instrument on the site reported green. The fix was an hour of work. Finding it took a reconciliation that nobody schedules, because the failure was designed to look like success. We now check that reconciliation on every site we take on, before anything else, because a broken form makes every other piece of search work worthless.