The bots arrived before the customers

A public website has an audience you did not invite

Skyforge Dynamics had barely launched its public website when automated contact-form spam began arriving. We built the form to start conversations about useful technology; it quickly gave us something else to investigate. The volume was low, but the lesson was immediate: operating a public site starts before an audience is established.

The submissions showed that the site was reachable and that automation had found a way to send content. What they did not tell us was how the form had been discovered, whether anything had actually read the page, or whether a human had ever been involved.

That distinction matters when reading traffic figures. Automated activity is evidence of reachability and some form of discovery; it is not evidence of useful human reach, search rankings or SEO value. Enquiries from relevant people are a different signal from a rising request count.

The controls were already there

The form launched with several protections. Each does a different job; none catches all spam.

• Server-side validation checks submitted data before it is processed. Browser validation helps visitors, but a script can send requests without using the browser form. Even valid-looking text can still be spam.
• A honeypot provides a field that ordinary visitors should leave empty. It can catch automation that fills every field, although a bot can learn to skip it.
• Nginx rate limiting constrains request frequency. It helps contain bursts, but low-rate submissions can still pass through.
• A fixed mail recipient keeps delivery under server-side control. A visitor cannot choose an arbitrary destination and turn the contact form into an open mail relay.

The visitor's email address is used as Reply-To, rather than as the message sender. That lets us reply to a genuine enquiry while keeping the sending identity under our control.

Low volume still has a cost

The first cost is attention: someone has to separate enquiries from inbox noise. That becomes more expensive if genuine messages are buried or dismissed alongside repeated junk.

There are operational costs too. Requests consume resources, accepted submissions create mail-delivery work, and repetitive events add log noise. At higher volumes, those effects can make it harder to see failures or investigate unusual behaviour.

Mail reputation also matters. A fixed recipient limits abuse, but excessive sending or delivery failures would still need attention. Spam arriving in the inbox is not, by itself, evidence of damage to our sending reputation.

Automated probing is worth watching separately: requests may test forms or look for exposed functionality. Spam alone does not show a compromise, and automated traffic is not always an attack. The useful question is simpler: what did the request try to do, and did our controls handle it?

Why we did not immediately add a challenge

We considered CAPTCHA and Cloudflare Turnstile, then deferred them. The volume was low, existing protections were in place, and observing the traffic was useful. Adding a challenge would introduce another step for visitors and another integration to operate.

That decision fitted the conditions at launch. We would revisit it if spam began burying real enquiries, creating sustained delivery work or slowing the site.

Use the traffic to ask better questions

The next review starts with a few practical questions: how often do submissions arrive, how many reach the inbox, are rate limits being triggered, and is mail delivery failing? Request totals alone cannot answer them.

Existing request logs can help explain the patterns without collecting more data for every spam message. Public examples should leave out personal information and private operational details.

The bots gave us an early reason to review the boundary between a public form and the systems behind it. A reachable website is the starting point. Keeping it useful for the people we want to hear from is the ongoing work.

← Back to Insights