How to set up a contact form's backend for a business website

This is one of the most common things to go wrong with a small business website, and one of the least obvious. The page looks finished. The form has a name box, an email box, a message box and a Send button. Someone fills it in, presses Send — and nothing happens, or the page reloads with the boxes empty, and it looks like it worked. Enquiries have been vanishing for weeks before anyone notices.

Nothing is broken. There is simply no backend behind the form yet, and this guide is about supplying one.

Why a form with no backend does nothing

HTML can draw a form. It cannot receive one. The markup describes the fields and the button; what happens when the button is pressed is decided by the form's action attribute — the address the browser sends the filled-in fields to.

With no action, the browser sends the fields back to the page they came from. That page is a static file, so it has no way to read them, and it just reloads. The visitor sees a blank form and reasonably assumes it went somewhere.

This is worth checking on any site you did not wire up yourself, whether it was built by a freelancer, from a template, or by an AI tool. Open the page source, find the <form> tag, and look for an action. If it is missing, or it points at #, the form does not send.

Three realistic ways to fix it

These are in order of effort. All three genuinely work; which is right depends on how much you want to own.

1. A hosted form service

Formspree, Web3Forms and Getform all do the same job: you sign up, they give you an endpoint URL, you paste it into your form's action, and submissions arrive in your inbox and in a dashboard. No server, no code beyond that one attribute.

• Effort: minutes. No developer needed.
• Cost: every one of them has a free tier, capped at a modest number of submissions a month, with paid tiers above it. The exact limits move — read the current pricing page rather than trusting any number you find written down elsewhere, including here.
• Trade-off: your enquiries pass through a third party, and if they change their pricing or shut down, you re-wire the form. For a local business getting a handful of enquiries a week, this is usually the right answer anyway.

2. Your own serverless function plus an email API

Hosts like Vercel and Netlify let you deploy a small piece of server code alongside a static site — a single file that receives the form's submission and does something with it. The usual something is calling an email API such as Resend to send the contents to the business owner. (That is what this site itself uses, which is why we are naming it rather than a service we have never touched.)

• Effort: an hour or two if you have written any code before; a developer's job if not.
• Cost: the function runs inside your host's free tier at this volume, and email APIs have free tiers of their own, so realistically nothing at a local-business scale.
• Trade-off: you own it, which cuts both ways — nobody can change the terms on you, and nobody else will notice if it stops working. You also have to handle spam yourself.

Netlify is worth a specific mention here: if the site is hosted there, adding a single data-netlify="true" attribute to the form gets you a working backend with no function to write at all. It is the shortest path of the three if you are already on that host.

3. An automation tool

Zapier and Make can both accept a form submission at a webhook URL and then do several things with it — email it, add a row to a spreadsheet, create a task, message a phone.

• Effort: more than a form service, less than writing code.
• Cost: free tiers exist but are tighter, and this is the option most likely to need a paid plan as volume grows.
• Trade-off: overkill if all you want is an email. Genuinely useful if the enquiry needs to land somewhere other than an inbox.

Walking through option 1, end to end

The hosted-service route, because it is the one anybody can finish today. The other two follow the same shape: get an endpoint, point the form at it, test it, then stop the spam.

1. Sign up and create a form. Whichever service you pick, you will end up on a page giving you an endpoint URL — something like https://formspree.io/f/abc123 or an access key to put in a hidden field. Copy it.
2. Point the form at it. Find the <form> tag in your HTML and give it that URL and a method:
   <form action="https://formspree.io/f/abc123" method="POST">
3. Check every field has a name. This is the step people miss, and it fails quietly. A field with no name attribute is not sent at all, so the email arrives with that field simply absent — which usually means the one you actually needed, the message.
   <input type="email" name="email" required>
4. Upload the changed file to wherever the site is hosted, the same way you would any other edit, and load the live page — not the copy on your own machine.
5. Confirm the address the service sends to. Most require you to verify the destination email once before anything is delivered, so the very first submission may be held until you click a link in a confirmation message.

Test it like a stranger would

Send yourself a real message through the live form, filling in every field the way a customer would, and then check that:

• the email actually arrives, and not only in spam — check that folder before deciding it failed;
• the message body contains every field, not just some of them (that is the missing name attribute above);
• the person filling it in sees something happen — a thank-you page or a confirmation message. A form that silently succeeds gets filled in twice.

Then check it again a month later. Free tiers expire, verification links go stale, and the failure mode of a contact form is silence, which looks identical to nobody getting in touch.

Keeping the spam out

A public form on a public page gets found by bots quickly. Two things stop most of it without making the form harder for real people:

• A honeypot field. Add a text input that is hidden from humans with CSS and left empty; bots fill in every field they find, so any submission arriving with that box filled in can be discarded. Most hosted services support this natively — you name the field and they do the discarding. It costs a real visitor nothing, which is its advantage over the alternative.
• A CAPTCHA, only if you need one. Effective, and a real cost to every honest visitor. Reach for it if the honeypot stops being enough, not before.

Whatever you use, do not put the destination email address in the page as plain text next to the form — that is scraped far more reliably than the form itself is abused.

One last thing worth knowing

If the site was generated by an AI tool, the form is very often the one part that was never finished — the markup is written, the backend is not, and nothing in the output says so. It is not a fault in the design; it is that there was nowhere for a generator to send to. If you have just had a site built and are working through what is left before it goes live, from a folder of code to a live website covers the hosting and domain half of the same job.