Skip to content

Test protocol · published August 1, 2026

How to Test Your Website Contact Form in Ten Minutes

Most contact forms get tested once, on the day the site launches, by the person who built it, from their own laptop, using their own email address. It worked that day. That is usually the last time anyone checked.

By Christopher Buchner, founder of PruneQ

Here is the problem with that test. You were signed in, on your own network, sending to yourself, on a desktop browser, filling in every field correctly on the first try. A customer is none of those things. They are on a phone, on cellular, in a hurry, on an email provider that has never heard of your domain, and they will type something wrong.

This page is a test protocol, not a repair guide. It tells you how to find out whether the form works, how to read what you find, and where to go if one specific thing fails. It takes about ten minutes. You need a phone with the wifi turned off, an email address on a different provider than your business email, and ten minutes when you can watch an inbox rather than check it later.

What a real test covers

A form can fail in seven places, and only one of them is the part people think of as the form.

  • Delivery. The message leaves the site and arrives somewhere a person will look.
  • Spam filtering. It arrives in an inbox rather than a junk folder nobody opens.
  • Mobile. The form is usable with a thumb, on a phone, on cellular data.
  • Required fields. A visitor who misses one is told which one and how to fix it.
  • Error messages. A failure says what went wrong instead of reloading a blank page.
  • The confirmation. The sender can tell their message went through.
  • The inbox behind it. Somebody is reading that address this week, not last year.

Any one of them failing produces the same result, which is a message the customer believes they sent and you never see. From your side it looks like a quiet week.

The ten-minute protocol

Run these in order. The clock times are a guide, not a rule, and step three has a wait built into it on purpose.

Step 01 · 0:00

Send one real message from an outside address

Use an email address on a different provider than your business email, from a browser you are not signed into your site with. Write something a customer might write, and put the word TEST plus today's date in it so you can find it later.

Watch for: Note the time you pressed send. You will need it in step three.

Step 02 · 0:30

Read the confirmation as a stranger

Read whatever the page shows as if you had never seen the site. It should say the message was received and roughly when someone will get back to you. A spinner that stops, a page that reloads to the top, or a bare thank you all leave the sender guessing.

Watch for: If you cannot tell whether it worked, neither can a customer. Some will send it twice and some will give up.

Step 03 · 1:00

Wait, then check three places

Give it five minutes. Then check the inbox the form is supposed to reach, the spam or junk folder of that same account, and any shared or archived folder a rule might be filing it into. Search for the word TEST rather than scrolling.

Watch for: Nothing in any of the three is the loudest result on this list. It means the message never made it to you.

Step 04 · 6:00

Reply to the message you received

Hit reply on the notification and send it back to the address you submitted from. This checks something the first three steps do not, which is whether the reply address on the notification is the customer's address or a no-reply address from the form service.

Watch for: If your reply goes to a no-reply address, every reply you have ever sent from that notification may have gone nowhere.

Step 05 · 7:00

Run the whole thing again on a phone

Turn off wifi so you are on cellular, open the site fresh, and submit again. Watch whether the fields are big enough to tap, whether the keyboard covers the submit button, and whether the form appears at all. Forms loaded by a script or an embed can fail quietly on a slow connection while the rest of the page looks fine.

Watch for: Desktop and phone are two different tests. Passing one says nothing about the other.

Step 06 · 8:30

Break it on purpose

Submit with a required field empty. Then submit with an obviously invalid email address in the email field. A good form stops you, names the field, and keeps everything else you typed. A bad one clears the whole form, or accepts it and quietly discards the message.

Watch for: Losing what somebody typed is the kind of thing that makes a person give up rather than start over.

Step 07 · 9:30

Find out who is actually watching that inbox

Forms are often set up to deliver to an address somebody created once during a website project. Find out whose address it is, whether that person still works with you, and when they last opened it.

Watch for: If nobody can answer that, you have your answer.

Step 08 · 10:00

Write down what happened, with the date

One line per check, pass or fail, plus the date and the device. This takes a minute and it is the only reason you will be able to tell later whether something broke or was always broken.

Watch for: Repeat the whole protocol after any site update, plugin change, or email provider change.

The check almost nobody runs

Step one asks you to send from an address on a different provider, and that is the single most useful instruction on this page. It is also the one people skip, because sending from your own account is easier and it feels like the same test.

It is not the same test. Mail from your own domain to your own domain often never leaves the building, so it skips the part where a receiving provider has to decide whether to trust the message. Testing that way proves the form submitted and proves almost nothing about whether a stranger reaches you. If you only have time for one check on this page, make it that one.

How to read the results

Each of these is a pattern, not a diagnosis. The point is to narrow where to look next, and to stop you paying someone to fix the wrong layer.

Nothing arrived anywhere

The message is being lost between the form and your mailbox. Usual causes are a form set to store submissions on the platform instead of emailing them, a delivery service that stopped sending after a lapsed plan or a rotated key, or a notification address that no longer exists. Check the platform's own submission log first, because the message is often sitting right there.

It arrived in spam

The mail is being sent and the receiving provider does not trust it, usually because of how the sending domain is authenticated rather than anything about the form. Google publishes the rules its own systems apply, linked below. A message in spam is a message you answer three days late, if at all.

It arrived, but slowly

Queued or throttled delivery. Worth knowing, because a business that promises a same-day response and gets its inquiries in a nightly batch cannot keep that promise.

It arrived with fields missing or scrambled

The form and the notification template have drifted apart, which happens when someone adds a field and nobody updates the email. You end up with messages you cannot reply to.

It worked on the laptop and failed on the phone

A layout or script problem rather than a delivery one. The fix is on the page rather than in the mail settings, and it affects most of your visitors.

Everything passed

Good. Record the date and run it again in a few months. Forms rarely break on the day you are looking at them.

If a check fails, go read the right documentation

The companies that make forms and mail plugins have written better repair instructions than anyone else will, because their support teams answer these questions every day. Their documentation is free and more current than any article about it, including this one. Start with whichever matches how your site was built.

If you do not know which platform your site runs on, the person who built it does, and so does the invoice you pay every month for hosting.

What this test does not tell you

A passing test means the plumbing works today. It does not mean any of the following.

  • Whether the form design persuades anyone to fill it in.
  • Whether the messages you get are worth answering.
  • Whether a message that arrives today will still arrive next month, after a plugin update or a lapsed billing account.

Nobody can tell you how many customers a broken form has cost, and anyone offering you that number is guessing, because the people who gave up left no record. What can be established is whether the form works right now, on a phone, from outside your own network. That is a smaller claim, and it happens to be true.

The form is one link in a longer chain. A customer who cannot find the phone number, or taps one that does not dial, never reaches the form at all. The contact path checklist covers the rest of that route, from the first place someone looks for a way to reach you to the message landing somewhere a person reads.

Wider than that, the website cleanup checklist covers buyer clarity, crawlability, identity, and measurement alongside the contact path, and it includes the check that turns a successful inquiry into something you can count. If you would rather have someone else run all of it, that is what PruneQ does.