Why WordPress and Wix Contact Forms Lose Leads Silently

Start with two questions:

1. Was the submission saved?
2. Was the responsible person notified?

Those are different events. WordPress plugins and Wix Forms handle them differently, so the answer tells you whether to inspect capture, storage, or notification.

First: identify the form you actually have

“It is a WordPress site” is not enough information. WordPress sites use plugins such as Contact Form 7, WPForms, Gravity Forms, and others, each with different entry-storage and notification settings.

Wix Forms is more standardized, but its submission table and notification automations are still separate places to inspect.

Before changing anything, write down:

• the platform;
• the form product or plugin;
• the page where the form appears;
• where submissions are supposed to be saved;
• and who is supposed to receive the notification.

That small inventory prevents the classic repair strategy of changing five settings and learning nothing.

The platform differences that matter

The useful diagnosis starts with the specific configuration: does it preserve a record, and does its notification path work?

If the record exists but the email does not

That is a notification problem until the evidence says otherwise.

On WordPress, the official wp_mail() documentation is unusually clear: a true return value means the selected mail method processed the request without an error. It does not prove that the person received the email.

On Wix, the submissions table and notification automation are separate. A saved submission can exist even when the expected inbox alert is missing. Wix's own notification guidance tells owners to check spam, the configured automation, and its recipients.

For email notifications, verify:

• the current recipient;
• spam or filtered folders;
• the sending domain and From address;
• SPF or DKIM authentication where the provider requires it;
• forwarding rules;
• provider logs or delivery status, if available;
• and a fresh low-volume test.

Google's current Gmail guidance requires SPF or DKIM for senders to personal Gmail accounts and warns that unauthenticated mail may be rejected or placed in spam. Authentication strengthens the path without guaranteeing inbox placement.

If no saved record exists

Now the problem is earlier in the path.

Possible causes include validation, spam controls, a broken form action, a plugin or integration error, or a configuration that never stored entries in the first place.

The fix depends on the product:

• configure a supported source record;
• repair the form handler;
• correct the validation or spam rule;
• or replace the failing component when the existing setup cannot provide an inspectable record.

An SMTP plugin can change the mail path while leaving submission storage untouched.

What a useful lead-form standard makes observable

A practical standard is less about platform choice than an observable order of operations:

1. Accept and validate the submission.
2. Preserve an inspectable source record.
3. Notify the responsible person.
4. Keep enough status to reconcile failures.

“Inspectable” means an authorized person can find the submission by time, distinguish it from spam, export it when necessary, and understand the retention policy. A website database can satisfy that. So can a properly configured platform submissions table. The right choice depends on ownership, privacy, portability, and the rest of the website stack.

The value of the record is observability: it turns a silent failure into something you can investigate.

The smallest-fix decision tree

You can run the complete test in How to Test Whether Your Contact Form Is Actually Losing Leads.

Once you know which stage failed, you can repair the right stage instead of rebuilding on suspicion.