How to Check Your Contact Form Is Working Before Enquiries Go Missing

A contact form is not working simply because a customer can press Submit and see a green success message.

A real enquiry has several stages. The form must load, accept valid data, reject invalid data clearly, store or process the submission, send the right notification, trigger any CRM or automation, reach the correct person and leave the business with enough information to respond.

Any one of those stages can fail while the public page still looks completely normal.

The seven checkpoints of a working contact form

1. Test the form from the public website, not the WordPress editor

Open the same live page a customer sees.

Do not use only the form-builder preview because that can bypass caching, consent tools, page-builder interactions and other front-end behaviour.

If practical, test in a private/incognito browser session so your logged-in admin state does not hide a problem.

2. Use a traceable test submission

Create a test that is easy to recognise everywhere it appears.

For example:

• Name: FORM TEST 30 SEPT 14:00
• Email: an external Gmail, Outlook or other address
• Message: Routine website form test — no action required

Record the exact time.

If something fails, that timestamp makes it much easier to match WordPress entries, mail logs, SMTP records and CRM activity.

3. Use an external email address

Testing from the same domain as the website can hide mail-routing quirks.

Use a real external address so you can see the customer side of the process as well as the business side.

4. Test every required field

Submit a valid form first.

Then deliberately leave required fields empty.

Check that:

• the correct fields are flagged;
• the error message is understandable;
• the fields the visitor completed remain populated;
• focus moves somewhere sensible;
• the error is visible on mobile.

5. Test invalid data

Try:

• an invalid email address;
• letters in a number-only field where relevant;
• an oversized file;
• the wrong file type;
• an unchecked required consent box.

The form should reject the data clearly without appearing broken.

6. Test on a real phone

Many local-service enquiries arrive from mobile devices.

Check:

• field size;
• keyboard type;
• date pickers;
• file upload;
• consent controls;
• CAPTCHA;
• sticky call or WhatsApp bars;
• cookie banner overlap;
• submit-button visibility;
• validation errors after the keyboard opens.

A responsive desktop preview cannot reproduce every real mobile-browser behaviour.

7. Check the confirmation state

After a successful submission, the visitor should know what happened.

A good confirmation can explain:

• that the message was received;
• when the business normally replies;
• what to do if the matter is urgent;
• whether a confirmation email has been sent.

A form that silently clears itself leaves customers wondering whether they should submit again.

8. Check whether the submission is stored

If your form plugin or CRM stores submissions, confirm the test record exists.

This single check separates two very different faults:

• No stored entry: the form may not have processed correctly.
• Stored entry, no email: the form processed, but notification or email delivery failed.

That distinction can save a great deal of troubleshooting time.

9. Check the business notification email

Confirm the email:

• arrives;
• arrives in the right inbox;
• does not land in spam;
• contains every important field;
• shows the right subject;
• uses sensible From and Reply-To headers;
• does not expose technical placeholder text.

10. Test Reply-To behaviour

Click Reply on the business notification.

It should reply to the customer address where appropriate, not to an unusable server address or the website’s own mailbox unless that is intentional.

11. Check the customer confirmation email

If the website sends an autoresponder, test it separately.

Confirm:

• delivery;
• sender name;
• branding;
• reply address;
• expected response time;
• links inside the email.

12. Check CRM and automation actions

If a form should create or update something elsewhere, verify it.

Examples include:

• HubSpot contact;
• Salesforce lead;
• helpdesk ticket;
• Google Sheet row;
• Mailchimp subscriber;
• Slack notification;
• Zapier/Make workflow;
• calendar booking;
• SMS alert.

A form is not fully working if the website email arrives but the sales team depends on a CRM entry that never appears.

13. Check who owns the lead

This is an operational failure many technical checks miss.

The enquiry may reach a shared inbox perfectly and still go unanswered because nobody owns it.

For important lead forms, define:

• which inbox receives it;
• which person or team is responsible;
• what the expected response time is;
• what happens outside working hours.

14. Check conversion tracking separately

Analytics cannot prove the form delivered.

Likewise, a successful delivery does not prove your conversion tracking is correct.

Confirm the form event:

• fires on a genuine success state;
• does not fire on page load;
• fires once rather than several times;
• appears in the correct analytics property;
• feeds Google Ads where required.

15. Test CAPTCHA and anti-spam protection

Security controls can block genuine customers.

Check the form after:

• CAPTCHA changes;
• Cloudflare changes;
• security-plugin changes;
• country/IP blocking;
• new spam rules.

16. Test file uploads

If the form accepts documents or photos, verify:

• allowed file types;
• file-size limits;
• upload completes on mobile;
• the business can actually access the file;
• sensitive files are stored appropriately.

17. Test multiple forms, not just one

A website may have:

• main contact form;
• quote form;
• popup form;
• footer form;
• download form;
• job application form.

Different forms can use different actions, recipients or plugins. Test every business-critical configuration.

18. Check conditional logic

If the form shows different fields depending on earlier answers, test each major branch.

Conditional forms can fail in ways a basic submission never reveals.

19. Check hidden fields and attribution

If you capture:

• page URL;
• UTM parameters;
• campaign source;
• service interest;
• referrer;

verify those values are still passing correctly.

20. Retest after changes that can break forms

A fresh end-to-end test should follow changes to:

• form plugin;
• WordPress;
• Elementor or other page builder;
• SMTP;
• DNS;
• hosting;
• CDN;
• cache;
• security;
• cookie consent;
• CRM integrations.

How often should contact forms be tested?

The more the business depends on forms, the more often they deserve checking.

Keep evidence of the last successful test

Record:

• date;
• form URL;
• test identity;
• recipient inbox;
• stored-entry result;
• CRM result;
• tracking result;
• tester.

When somebody later says, “I submitted the form last Tuesday and nobody replied,” this history helps determine when the route last worked.

What if the form stores the enquiry but no email arrives?

That usually points away from the form itself and toward email generation or delivery.

The separate WordPress contact form email troubleshooting guide covers SMTP, headers, DNS authentication and mail-delivery diagnosis in more depth.

What if neither the email nor stored entry appears?

Investigate:

• browser console errors;
• form validation;
• AJAX/REST requests;
• security or firewall rules;
• JavaScript conflicts;
• plugin conflicts;
• server/PHP logs.

What if only mobile submissions fail?

Look at:

• overlay or sticky widgets;
• CAPTCHA;
• mobile-specific field logic;
• keyboard behaviour;
• consent popup;
• browser console/network errors;
• file uploads.

Do not judge form health from enquiry volume

A quiet week may mean demand is quiet.

It may also mean the form broke after an update.

Only a controlled test tells you which.

How Core Web UK handles form monitoring

Our website maintenance and support service treats lead-generation functions as part of website health rather than checking only plugin versions.

If a live form is already failing, our emergency website fixes service is intended for urgent faults.

Frequently asked questions

Can analytics prove a contact form is working?

No. Analytics can show an event fired, but it cannot prove the notification reached the inbox or CRM.

Should I test every form?

Test every business-critical form and every materially different configuration or destination.

Why test with an external email address?

It better represents a real visitor and can expose routing or spam behaviour that an internal test misses.

Should contact forms store submissions?

Where privacy and operational requirements allow, stored entries can provide a valuable backup when email delivery fails.

How often should I test a business contact form?

For lead-generating websites, weekly or automated monitoring plus post-change testing is sensible. Lower-volume sites may use monthly checks.

Add a recurring synthetic test for high-value lead forms

Manual testing is essential after changes, but high-value forms can fail between maintenance windows. A synthetic monitor can submit controlled test data on a schedule and confirm the expected success state, webhook or stored entry.

Do not point automated tests at live CRM workflows without planning for them. Mark test submissions clearly and exclude them from sales reporting where possible.

Test after consent, cache and CDN changes

Forms can fail when the form plugin itself did not change. Re-test after cookie-banner changes, JavaScript optimisation, Cloudflare rules, caching changes, CDN changes and security hardening because those layers can block scripts, AJAX requests or CAPTCHA.

Keep a known-good test route

For business-critical forms, document one standard test: the page URL, the expected success message, the recipient inbox, the CRM destination and the person responsible. That turns future checks into a repeatable control rather than an improvised test.