Kadence contact form not working: test the send

A contact form on WordPress can run a spam check before it accepts a message. The check is a separate script that has to load and then pass before Send goes through. If it does not load, the form can refuse the press and show a small line, or show nothing, depending on how the block was set up. A visitor who never sees a box to tick cannot know a check exists. The owner's own browser accepted the cookies months ago, so the check loads there without a prompt, and the fault never shows on the owner's screen.

• Open the contact page in a private window and press Send. Note whether a spam check box appears above the button.
• Decline the cookie banner, then press Send again. If the form stops, the check depends on consent.
• Open the browser console on Send and look for a script that was blocked or failed to load.
• At phone width, check that no banner, chat launcher or sticky bar sits over the Send button.
• Read the reply after a refused send. A generic line usually points at the check, not the mail step.

A spam check is a separate piece of code that runs in the visitor's browser and vouches for the person pressing Send. The form waits for that answer before it sends. When the check fails to load, the visitor's browser has nothing to vouch with, and the form can refuse the message. Depending on how the form was built, the refusal appears as a short line near the button, a line at the top of the form, or no line at all. Visitors read the last case as a broken button and leave, and the owner never sees an entry arrive.

Some sites treat a signed-in person differently, so the check can appear for one person and not another. The owner is often signed in, and a stranger is not, so the owner test takes a different path from the visitor test. Test the form as a stranger, in a window where nobody has signed in, and write down both replies. A difference between them is the clue you need.

Many sites hold third-party scripts until the visitor accepts cookies, and a spam check is one of those scripts on some sites. A visitor who declines the banner never gets the check at all. The form then waits for an answer that will not come, or refuses the press. A banner placed over the form can make things worse, because the visitor cannot reach the choice that would load the check. Decline the banner yourself in a private window and press Send, so you see the path a visitor who says no takes.

On a phone, the Send button can sit under a sticky bar, a chat launcher or a cookie notice that stays pinned to the bottom of the screen. The visitor taps the place where the button is drawn and reaches the overlay instead. The check may still load, and the message may be sent, while the visitor sees no change because the tap never reached the button. Look at the contact page at phone width and confirm that nothing is drawn over the button.

A simulated visitor fills in the form, presses Send, and records the reply it sees. A visitor stopped by bot protection is marked as blocked by the site. The run does not try to get past that protection. The report gives the step, a screenshot of the form at that moment, and any blocked or failed script the browser logged there. It cannot read your form's settings or your spam check configuration, so it cannot name the check that refused the send.

A new cookie banner, a chat widget added later, or a plugin update can change when the spam check loads. Each of these can move the check behind consent or cover the button on phones without any change to the form itself. After each of those changes, run one visitor who accepts the banner and one who declines it, both on a phone.