The ten minute contact form test.

Most business websites exist to do one thing: turn a visitor into an enquiry. Which makes the contact form the single most important component on the site. It is also the one most likely to be broken without anyone noticing, because a broken form usually fails silently. The visitor sees a thank you message. The business sees nothing. Nobody complains, because the one person who knows it failed thinks it worked.

How a form fails without telling you

We learned this the hard way, on our own work. A form on a site we manage was wired to a popular free form service. The page submitted, the response came back with status 200, and the visitor saw the success state. But the service had not actually been activated for that exact domain, and it treats www and the bare domain as two separate activations. Inside the body of that healthy looking 200 response, the service was quietly saying no.

The lesson stuck: a form is not working because the network tab looks green. A form is working when the email lands in the inbox and the analytics event fires. Nothing less counts.

The test, start to finish

This takes about ten minutes on a typical business site, and we run it on every build before launch and after any change that touches a form.

1. List every form shape on the site. Contact page, quote form, footer signup, callback widget. Each one is a separate row in the test. If two forms share a backend, they still get tested separately.
2. Submit each one with a real message. Use a phone on mobile data, not your own development browser. Desktop browsers with ad blockers can block the analytics script and hide half the picture.
3. Check the inbox, then check spam. The message should arrive within a minute or two. If it is in spam, that is a fail: your customers will not go looking for it, and neither will you at nine on a Tuesday.
4. Check the analytics event in realtime. Open GA4's realtime view and confirm the submission event actually fired, and that it is marked as a key event. If enquiries are not measured, you cannot know whether the site earns its keep.
5. Read the response, not just the status code. If the form posts to a third party service, look at what the response body says. A 200 can carry a refusal. The success state on screen should only ever be shown when the service says success.
6. Reply to the test email. Hit reply and check it goes to the address the visitor typed, not to the form service or to yourself. The first thing a business does with an enquiry is answer it.

What a pass looks like

Every form on the site has a row, and every row reads the same: message arrived in the inbox, not spam. Analytics event fired and counted as a key event. Response body says success. Reply goes to the visitor. When all rows pass, the form is working. Until then it is decoration.

When a row fails

The usual suspects, in the order we check them. The form service is not activated for the exact domain in the address bar, including the www or non www variant. The success state is shown on any 200, including a refusal, so the front end needs to read the body before celebrating. The email arrives but lands in spam, which points at the sending domain's authentication records. Or the message arrives fine but the analytics event was never wired up, so the business is flying blind on how many enquiries the site produces.

None of these are exotic. All of them have the same symptom: a site that looks finished and quietly loses work.

Why we publish this

This checklist is part of how we do web design in Nottingham: every site we ship gets its forms tested this way, verified in the inbox and in the analytics, before we call it done. If you have a site live right now and you are not certain the form works, run the ten minutes yourself today. It is the cheapest insurance a business website can buy.