Website Forms That Actually Work
When did someone last send a message through your contact form? If the honest answer’s a shrug, have a look. A form can sit on a page looking perfectly healthy while the messages go nowhere. Picture a physio clinic wondering why online booking requests tailed off over the summer, or a joinery firm whose quote requests have been landing in a spam folder nobody opens. Nothing on the website looks broken. Enquiries just dry up, sometimes for weeks before anyone twigs.
In brief
- A ‘thank you’ message on screen doesn’t prove the email arrived.
- Use the least annoying spam protection that does the job, and only go heavier if the bots force you to.
- Checks in the browser are a convenience. The real checking happens on the server.
- Every enquiry is personal data, so know where it ends up and how long it stays there.
Why a form can look fine and still fail
Most contact forms do two jobs. They collect what someone types, then they email it to you. You can watch the first half happen. The second half goes on somewhere you’ll never see unless it breaks.
On WordPress, that email usually goes out through a built-in function called wp_mail. WordPress’s own developer docs for wp_mail are frank about what it can and can’t tell you. A ‘success’ result only means the request was processed without errors. It doesn’t mean anyone received the message. So the visitor gets a cheerful confirmation while the email bounces, vanishes or lands in junk.
Gmail, for one, has got a lot stricter. Since February 2024 its email sender guidelines have required everyone who sends to its accounts to set up SPF or DKIM, which are records on your domain that prove a message really comes from you. A form sending straight from a web server that hasn’t been set up that way doesn’t meet those rules. Where its messages end up is anyone’s guess.
The usual fix is to route form emails through a proper email sending service that’s authenticated for your domain. Many form plugins can also keep a copy of every entry inside the website. That’s your safety net if an email ever goes missing.
Keeping spam out without blocking real people
Leave a form unprotected and the bots will find it. Nobody’s sat in a dark room picking out your business. Automated scripts crawl the web filling in every box they come across. Your inbox fills with junk, and the real enquiry from a charity trustee gets buried under forty offers of cheap backlinks.
The old answer was a CAPTCHA, the squiggly letters or the ‘click every bus’ puzzles. They come at a price. A W3C accessibility group’s draft note on CAPTCHA explains that these tests shut out many people with disabilities, and that a CAPTCHA with no accessible alternative can stop some users getting through at all. That’s a lot to ask of someone who only wants a price for a kitchen refit.
So start lighter. A honeypot is a hidden field that people never see but bots happily fill in. If it comes back with something in it, the submission gets binned. The W3C’s advice is to stick with a honeypot while it does the job and only move to something stronger when there’s evidence the bots are getting past it.
Invisible scoring tools sit a step up. Google’s reCAPTCHA v3 gives each submission a score between 0.0 and 1.0 without asking the visitor to do anything, and the response should be checked on your server. They’re not free of drawbacks. The W3C notes that non-interactive approaches like this can expose people’s personal data. Each one is another third-party script on the page as well, and those all cost something, as our guide to what slows a business website down explains.
Validation that helps rather than nags
Validation just means the form checking what’s been typed. Done well, it saves people from silly mistakes before they press send. Get it wrong and a two-minute job turns into an argument with a text box.
There are two layers. Checks in the browser are about speed and convenience, like flagging a missing email address straight away. They’re no use as security. MDN’s guide to client-side form validation warns that browser checks are too easy to bypass and that everything should be validated on the server as well. Anyone determined can skip the friendly checks and send whatever they like.
Field types matter more than people think. Set a phone field up as a ‘tel’ input and mobile browsers can show a number keypad. Browsers don’t check phone numbers automatically, because formats vary so much from country to country. So don’t bolt on a fussy rule that rejects spaces or a +44. A dental patient typing their number at a bus stop won’t try three times.
Error messages need words. A red border on its own tells nobody what’s wrong, and plenty of people can’t see it. Our post on WCAG 2.2 and website accessibility covers labels and errors, and our guide to getting more enquiries looks at how many fields a form should ask for.
What happens to the data afterwards
A name and an email address are personal data. Often people send far more. A solicitors’ practice might get the bones of a family dispute typed into a message box. A clinic might get symptoms. Treat what follows as general information. It isn’t legal advice. The ICO’s guidance on all of this is under review following the Data (Use and Access) Act, so check the current versions before you rework anything.
People should be told what you’ll do with their details at the point you collect them. That comes from the right to be informed under UK GDPR. On a contact form, a common approach is a short line by the send button linking to your full privacy notice. The ICO’s guidance talks about layering information like this.
Then there’s how long you hang on to it. The ICO’s guidance on storage limitation says you mustn’t keep personal data longer than you need it, and that you should review what you hold and delete or anonymise what’s no longer needed. Entries stored in the website count. So do copies sitting in three people’s inboxes, and that spreadsheet export from years ago. Decide how long you’ll keep enquiries, and delete them when that time’s up.
Security comes into it as well. The law expects appropriate technical and organisational measures, and the ICO recommends encryption where it’s appropriate. As a practical minimum, the form should sit on an HTTPS page, and the website’s admin login shouldn’t be one shared password the whole office knows.
Adding a newsletter sign-up box? Leave it unticked. The ICO is clear that pre-ticked boxes don’t count as consent.
Test it the way a customer would
The only real proof is sending a message yourself. Do it on a phone, on mobile data, the way a customer would. Then see whether it turns up. If it doesn’t, look in spam before you panic. Any automatic reply should read properly and carry the right phone number. While you’re at it, check the test turns up in Google Analytics too. If it doesn’t, your enquiry tracking with GA4 key events needs a look.
Repeat the test after plugin or theme updates, and any time the address the form sends to changes. A member of staff leaving is a classic way for enquiries to end up in a dead inbox. An online shop should check its order emails too, since they often rely on the same email setup.
A monthly test takes two minutes, and it’s the sort of check that belongs in a website care plan. It sits alongside the other common website problems worth fixing that are easy to miss until they cost you work. Where the form sits matters too. A working form at the very bottom of a long page still won’t do much, which is why service pages built to win enquiries put a way to get in touch wherever people are likely to be ready.
Getting your forms sorted
Not sure yours is delivering? Send yourself a test today. If nothing arrives, or you’d rather not wrestle with mail settings and DNS records, it’s normally a quick job for a developer. Forms that send reliably, keep spam out and handle personal data sensibly are part of how we approach website design and development. Get in touch and we’ll check yours over.
Keep reading
- Website Speed and Performance Explained for Business Owners
- WordPress or a Website Builder like Wix and Squarespace
- 7 UX Considerations For Your Website in 2026
Sources
- WordPress Developer Resources, wp_mail()
- Gmail Help, Email sender guidelines
- W3C, Inaccessibility of CAPTCHA (Group Draft Note)
- Google for Developers, reCAPTCHA v3
- MDN Web Docs, Client-side form validation
- MDN Web Docs, input type tel
- ICO, The right to be informed
- ICO, Principle (e) Storage limitation
- ICO, A guide to data security
- ICO, What is valid consent?
