Divi contact form not working for visitors

A Divi form is a module inside a section, and each section can be shown or hidden at each screen size. On a phone, a cookie banner pinned to the bottom can cover the Send button, a sticky header can sit on top of the last field, and a section hidden at phone width takes the whole form with it. The visitor fills in every field, reaches for Send, and taps nothing. You see the form on a laptop, where the banner and the header stay out of the way, so the fault never shows from your own desk.

• Is Send visible on a phone, above any cookie banner and clear of a sticky header?
• Is the form section set to show on phones, or hidden at that screen width?
• Does an error appear under a field inside a collapsed tab or accordion?
• Does the page log a script error after Send, or show an error from the form itself?

Three layout faults cause many phone failures, and each one looks like a form that is working. A cookie banner pinned to the bottom covers the last part of the form. A sticky header covers the field above the button, so the visitor taps the header and not the field. A section set to hide on phones removes the form entirely at that width, leaving a contact page with a heading and nothing under it.

The page builder's visibility settings can hide a row or module at one screen width, with no warning in the view you use on your laptop. Open each section's settings and check every screen size, not only the desktop view you edit in. Then open the page on a phone, signed out, and tap through every field down to the button.

Why visitors leave

Some Divi forms sit inside a tab, an accordion or a toggle. A required field in a closed section still blocks the submit, and the error appears somewhere the visitor has to open before they can see it. The visitor sees Send do nothing, the same as with a hidden checkbox, but the cause is a collapsed panel. Test by submitting with every field empty, then opening every panel on the page, so you know which one holds the error.

Optimization plugins are a second cause on this kind of page. A plugin that defers or combines JavaScript can delay the form's script until after the visitor has tapped Send, or stop it from running at all. The form then posts the ordinary way, or does nothing, and the mail step is never reached. Check the page's errors after Send, and test with optimization turned off for this page to see whether the difference is the plugin.

A Divi form sends its message to the address set in the module's own settings, and that setting is easy to leave at a default or at an old mailbox. When the recipient is wrong, the visitor sees a thank you, because the form accepted the message, and the owner sees nothing. The mail can also be refused by the host, or land in spam because the sending domain lacks its mail records. None of these changes what the visitor sees, so the form looks healthy.

Separate the mail fault from the layout fault with the error text. If Send shows an error after a valid submit, read the message word for word and treat it as the form's own report. If Send shows a thank you and no mail arrives, the layout is fine and the recipient or the domain needs checking. The report keeps the text each visitor saw, so you can compare the two cases directly.

The Send button can move out of reach after a change that does not look like it touches the form: a Divi update, a new cookie banner, a sticky header, or a plugin that starts optimizing scripts. Rerun phone visitors through the form after each change, with the banner on screen. You catch the covered button before a customer writes in to say the form never worked for them.