[Blog]()Website forms # Website forms: filtering spam without losing customer inquiries Blocking bots and receiving useful inquiries are separate outcomes. Test both, including when a customer loses connection. **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 7 min read **Short answer** A form needs server validation, abuse controls and confirmation matching the inquiry's actual state. Test legitimate submissions and retries that do not create another request. Distinguish received inquiries from delivered email notifications; an empty inbox may hide a notification failure. ## Test worksheet: Website forms: control spam and retain inquiries Blocking bots and receiving useful inquiries are separate outcomes. Test both, including when a customer loses connection. Record inputs, expected outcome, evidence, owner and observed result. [Download CSV worksheet]() In this guide - [Define when an inquiry counts as received]() - [Fictional example: L-017 without a visible response]() - [Test the customer you want to serve]() - [Distinguish rejection, pending and confirmed receipt]() - [Measure whether the team can handle received work]() ## Define when an inquiry counts as received A carrier may need origin, destination and date; a factory may receive quote requests with a description and contact. Ask only for information needed to handle the initial inquiry. Define whether receipt means storing a record or passing it to an agreed inbox. Success must match that boundary rather than appearing as soon as someone clicks. [Cloudflare Turnstile]() requires server verification: the widget alone does not protect the form. [reCAPTCHA]() also documents backend verification and expiring single-use tokens. These provider controls differ from saving an inquiry and delivering its notice. Test each step in your implementation. ## Fictional example: L-017 without a visible response Test customer Ana O'Neill uses accented text, provides a valid email and requests a quote. The server saves L-017, but the connection drops before confirmation appears. On return, the page offers lookup or resumption without another record. This synthetic case is neither measured inquiry data nor a declared capability of Nightly's website. The rehearsal also uses an expired verification token. The form explains how to renew verification while preserving entered fields. It does not call this an invalid email or erase the customer's inquiry. When a message needs review, use a clear state rather than claiming a representative has already replied. | Layer |What it checks |What it does not establish | | --- | --- | --- | | Field validation |Format, size and necessary rules |That everyone is a real customer | | Abuse control |Verification and frequency rule |That the inquiry was saved | | Receipt |Durable record or agreed destination |Delivery of notification email | | Follow-up |Owner finds and handles inquiry |Confirmed sale or appointment | ## Test the customer you want to serve [OWASP]() recommends field-specific rules and warns that blocking characters such as apostrophes can reject legitimate names. Allow necessary text, limit length and validate structured data by meaning. A link alone is insufficient evidence of spam: a valid inquiry may include a product reference. | Case |Expected result |Evidence | | --- | --- | --- | | Ana O'Neill uses accents and punctuation |Valid inquiry accepted without changed meaning |Fields and L-017 record | | Verification token expires |Clear renewal with fields preserved |State and new attempt | | Request lacks server validation |Rejected under the control, without a false inquiry |Server result | | Response lost after saving |Recover confirmation or state without duplicating L-017 |Reference and attempts | | Notification email fails |Inquiry remains queryable; notice pending |Record and notification state | | Request exceeds field limit |Specific explanation without erasing other data |Field and error message | ## Distinguish rejection, pending and confirmed receipt Agree what happens when the verification service does not respond: do not claim success with an unknown outcome. Preserve entered text and offer an appropriate alternative channel where relevant. Test keyboard, screen reader, mobile and slow connections; an abuse control blocking legitimate inquiries also needs correction. The inquiry retry identifier belongs to your operation and is different from a CAPTCHA token. A token may expire or permit one use while an inquiry still needs confirmation recovery. Review that separation and reference lifetimes. Controls and limits depend on provider, abuse patterns and risk; they do not promise to eliminate all spam. ## Measure whether the team can handle received work Have someone find L-017 and check its state without reading extensive technical logs. Connect this rehearsal with [qualified inquiry measurement](), [making buying easier]() and [website performance](). A fast page can still lose inquiries through false success messages. The worksheet has ten tests with empty outcomes. Bring current fields, anonymized spam examples and a valid inquiry to a [free consultation]() about [websites](). We can review where work is lost and a useful test before adding more submission obstacles. ## Review a valid inquiry and incoming spam A valid inquiry and spam examples help review rules without blocking blindly. In a free consultation, follow the fields, confirmation message and receipt destination through to the person who must respond. - Current form fields and messages - One valid inquiry and anonymized spam examples - Receipt destination, notices and response owner [Book a free consultation]()[Ask on WhatsApp]() Related - [Websites and online stores]() - [Software consulting]() ## Frequently asked questions ### Does every form need CAPTCHA? The choice depends on risk and existing controls. Identify abuse and test legitimate customer experience first. If you use a verification provider, implement and test its server validation; a visible widget is insufficient. ### Can I reject names or messages containing symbols? Define necessary field rules rather than a generic suspicious-character list. Apostrophes, accents and references can be legitimate. Validation does not replace other defenses when storing or displaying data; test that meaning is preserved. ### Why is there an Analytics contact but nothing in the inbox? A click, attempt or inquiry with a failed notice may have been counted. Compare the event with the received record and delivery status. An analytics event does not establish that the team has an inquiry to handle. ### How can we test retries without sending real spam? Use fictional inputs and an authorized rehearsal destination. Simulate lost response after saving and verify one reference. Do not use customer addresses or a real campaign to test that behavior. ## Sources 1. [Validate the token]()Cloudflare 2. [Verifying the user's response]()Google 3. [Input Validation Cheat Sheet]()OWASP Last updated: October 8, 2026 ## Keep reading [Inquiry measurementOct 8, 2026 ### Measuring website inquiries: useful contacts, appointments and verified sales]()[Website performanceOct 8, 2026 ### A slow website: what to measure and fix before redesigning]()[SecurityOct 2, 2026 ### Who holds the digital keys to your business? How to check your access]() --- Canonical: https://nightlysoftware.com/en/blog/website-form-spam-controls Updated: 2026-10-08 Description: Test valid inputs, spam controls and saved inquiries after response failures. Includes a practical acceptance worksheet for your website form.