What do form spam bots look like in a store's traffic logs?
Form spam bots do not look like attack traffic. They are low-volume, patient, and polite to your rate limits, which is why they survive where scrapers get blocked. Their signature is in the form interactions: fields filled in milliseconds, submissions at inhuman hours in perfect patterns, and content that is almost but not quite human. Learn the signature and they become the easiest bots to catch.
Why form bots fly under the radar
Most bot defenses are tuned for volume: rate limits, request spikes, aggressive crawling. Form spam bots operate below all of it. A bot that submits three contact forms an hour from a residential IP looks exactly like a quiet human visitor in every volume-based metric. Stores that rely on rate limiting alone will never see them, and the spam keeps arriving: fake contact submissions, newsletter signups with garbage addresses, review forms filled with links.
The cost is not the traffic. It is the pollution. Fake signups degrade email list quality and sender reputation. Spam reviews erode trust. Contact form spam wastes support time. And every fake submission that reaches a human is a small tax on the team's attention. The bots are cheap to run, which means they never stop.
The millisecond fill signature
Humans type. Even fast typists take seconds to fill a multi-field form, with irregular pauses between fields. Bots fill forms programmatically: all fields populated in the same millisecond, or in a perfectly uniform sequence with identical intervals. If your forms log field-level timing, and they should, this is the clearest signal available. Sub-millisecond fills across five fields is not a fast human. It is a script.
The timing signal survives most bot sophistication. Operators randomize user-agents, rotate IPs, and solve CAPTCHAs, but few bother to simulate human typing cadence, because most defenses never check. Adding field-timing checks to form submissions catches the lazy majority with almost no false positives. Humans simply cannot fill forms that fast.
Honeypot hits do not lie
A honeypot field, invisible to humans, visible to bots that parse HTML, is the oldest trick and still one of the best. Humans never fill it. Bots fill it constantly, because they fill every field they find. A submission with the honeypot filled is a bot with near certainty, and the check costs nothing in user experience.
Rotate the honeypot's name and position periodically. Sophisticated operators learn to skip known honeypot names, so "honeypot" and "leave_this_blank" have a shelf life. Use plausible field names like "website2" or "company_name_confirm" and move the field around in the form markup. The arms race is slow here, and staying one step ahead is easy.
The content tells on them too
Read a month of spam submissions and the patterns emerge. Messages that are almost coherent but slightly off, links shoehorned into irrelevant text, names that do not match email handles, the same message submitted across dozens of stores. Modern spam content is often AI-generated, which makes it grammatically better and semantically stranger: fluent sentences about nothing, selling things unrelated to your store.
Content patterns are useful for classification but weak for blocking, because the content keeps evolving. Use content signals to confirm what the timing and honeypot signals already told you, not as the primary gate. The behavioral signals are stable. The content is fashion.
What they actually cost you
Quantify it, because "annoying" does not get budget. Count the fake newsletter signups and estimate the sender-reputation cost: every percentage point of list pollution raises the chance your real emails land in spam. Count the support hours spent triaging contact spam. Count the fake reviews caught and the ones that slipped through. For most mid-size stores the total is a few thousand dollars a year in direct cost and considerably more in degraded trust signals.
The number matters because the fix is cheap. Honeypot fields, field-timing checks, and submission throttling per session cost a day of development. When the cost of the problem is documented and the cost of the fix is one day, the decision makes itself.
Block the behavior, not the human
The right defenses are invisible to real users. Honeypots, timing analysis, and velocity checks per session all operate without challenging anyone. CAPTCHAs are the visible fallback, and they should be the last resort, not the first: every CAPTCHA costs you some real conversions, and the sophisticated operators solve them anyway. Invisible checks first, visible challenges only for traffic the invisible checks already flagged.
Review the form-spam logs monthly, not just the block counts. The logs show you what the bots are trying now: new field targets, new timing patterns, new content themes. Form bots evolve slowly, and a monthly glance keeps your defenses ahead of them with minimal effort. Quiet bots, quiet defenses, quiet logs. That is the whole posture.