Contact Form 7 not submitting: check the send

Contact Form 7 sends the message in the background, so a press on Send starts a request that the page's script must catch. If that script is blocked, merged into a broken file or loaded after the press, the browser takes over and posts the form like an old web page. The page reloads, the fields clear, and the visitor sees the same contact page with no word about the message. Other failures stop earlier. A required field the visitor cannot see can hold the send, with its message placed off screen. The owner who tests once on a laptop, with every field filled, will not hit either one.

• Press Send with every field empty. If the page reloads with no message, the background send never started.
• Look for a red message under a field the visitor cannot see, such as one inside a closed tab or a hidden column.
• Open the browser console and press Send again. A script error at that moment means the form never handed over the message.
• Open the page in a private window with caching off, then send. If it works there, a cached copy is the cause.
• Read the exact words after Send. A message that names a field points at validation, and a generic line points at the server.

The first point is the press itself. Contact Form 7 reads the form, checks it, and posts it without leaving the page, so the page script has to be loaded and running when the visitor presses Send. Caching and optimization plugins can delay or merge that script, and a theme update can rename a file it needs. When the script is missing, the browser performs an ordinary form post, the page reloads, and the fields clear. The visitor sees the same contact page again with no message at all.

The second point is validation. A required field that the visitor cannot see, because it sits in a closed tab, a collapsed column or a layout that hides it on phones, still blocks the send. Contact Form 7 places its message beside the field, so the visitor sees nothing near the button and assumes the form broke. The third point is the server. A spam check, on the site or the host, can refuse a message and return a generic line, and it does so before the mail step runs.

The words that appear after Send tell you which point failed. A message that names a field points at validation. A generic line about a failed send points at the server or the mail step. No message and a reloaded page point at the script or at a cached copy of the page. Compare what you see with the console at the moment of the press, because a script error there often settles the question in one check.

A simulated visitor fills each field it can see, presses Send, and records what the page shows next. If the form reloads, stays still or refuses the message, the report gives the step, a screenshot of the form at that moment, and any script error logged at the press. The run cannot read your host's spam settings or your plugin files, so it cannot say which point failed. It shows how far the visitor got, and that narrows where to look first.

Contact Form 7 depends on the page loading its script in the right order, and an update to a theme, a cache or an optimization setting can change that order. A form that sent yesterday can stop after a release without any change to the form itself. After each update, run one visitor through the contact page with the form filled, then with it empty, so you see both the send and the error path.