WordPress contact form not working: find why

A contact form is a set of fields plus a request. The visitor types into the fields, presses send, and the browser posts the values to your site, which then answers with a thank-you message or an error. Three things can break that chain without changing how the form looks: a validation rule that marks a hidden or off-screen field as required, a script error that stops the button's click from doing anything, or a stale page whose security token the server now refuses. In each case the form stays on the screen, and the visitor sees nothing that explains why.

• Press send with every field empty, then with a valid message. Does the response change?
• Look for a red message under a field you cannot see, such as a checkbox or a consent option.
• Open the console on the contact page and press send. Note any red error at that moment.
• Open the network list and check whether a request goes out, and what status comes back.
• Load the contact page in a private window, signed out, and send it once, since cached copies can differ.

A visitor opens the contact page on a phone, types a name, an address and a message, and presses send. Three outcomes are common. The button turns grey or spins and then stops, the form jumps back to the top with an error that is out of view, or the page reloads with the same fields still filled in and no thank-you message. Each outcome points at a different break, so the visitor's experience alone does not tell you which one you have.

The most common single cause is a required field the visitor cannot reach. A consent checkbox, a hidden field added by another plugin or a dropdown placed behind a banner can all block the send while showing their message out of view. Scripts that run on the page can also fail. If a script that handles the button errors out, the click does nothing at all, and the request never leaves the browser.

When you test the form yourself, you are usually signed in, and your browser may keep the values you typed last time. Caching setups usually skip signed-in users, so you see a fresh copy of the page while a stranger gets a stored one. The form then works for you and fails for them, because the stored copy carries a token the server no longer accepts. A test from a private window, signed out, is the only test that matches what a stranger sees.

A validation message is visible text near the field, so it points at the field. A script failure leaves no message at all, but the console shows an error on the press and no request appears in the network list. An expired token usually produces a message about a failed or expired security check, and the request does reach the server. Read which of the three you see before you change any setting, because each one is repaired in a different place.

Contact forms depend on the page the visitor loads, and both caching and plugin updates change that page between visits. After each update or cache change, send the form with the same simulated visitors and compare the step each one reached. A staging copy behind a site password needs that password in the run, which is part of paid credits. Keep the run saved, so the next break shows up as a difference rather than a surprise.