Wix form not submitting: what blocks Send

A press on Submit has three outcomes: the form sends and shows a message, the form refuses and marks a field, or the form waits. The first should be easy to see, but a refusal often marks a field the visitor cannot find. A required field can sit under a cookie bar, below a collapsed section, or at the bottom of a page the phone has already scrolled past. The third outcome is a sending state that never clears, often because the form hands the entry to a connected service that is slow or switched off. From the visitor's side, all three look like a button that did nothing.

• Fill every field with a normal value, then press Submit once. Does anything change on screen?
• Look for red text under any field, including fields above the one you pressed from.
• Check that no cookie banner, chat bubble or bar covers the Submit button.
• Watch the button for a sending state. Does it stop, or does it spin without ending?
• Open the form's connection settings and confirm the service it sends to is still switched on.

A working send shows a confirmation, usually in place of the form or just beneath the button. A refused send keeps the typed text and puts a short error under the field that broke the rule. A waiting send keeps the button in a sending state until something answers. Only the first is obviously a success, and the other two look like a press that did nothing, so a visitor is likely to press Submit again or leave.

Your job is to find which outcome the visitor hits. Press Submit with a full set of normal values and look at the screen before you look anywhere else. A changed button or a new message means the press was received. No change at all points at a refusal you cannot see, or a wait that never ends, and those are checked in different places.

Long forms hide refusals best. A phone number field may reject spaces, a postcode field may expect a pattern, and a required consent box may sit inside a collapsed section. In each case the error is real and placed correctly, but the visitor never sees it, because the field is above the fold or behind the bar. The fix is to make the error visible where the visitor is looking, not to add a note at the top that says the form has errors.

The right version lets a phone number include spaces and a leading plus sign, and shows the consent box at phone width. The wrong version adds more required fields to a form that was already refusing entries, because each new one is another place a visitor can be stopped without a message. Remove any required field the business does not need before the next test.

Give Mimiq the contact page and one task a visitor would have: ask for a price for a kitchen repair through the form. Each simulated visitor fills in every field it is asked for and presses Submit. The result shows the form's state after each press, the red text under any field, the state of the button, and any request that was slow or never returned, with a screenshot of the form at the moment of the press.

The test cannot see your connected tool, so a request that returned an answer but landed in the wrong place will look like a success. It also cannot read the message that arrived in your inbox. Use the test to find a refusal or a stuck wait, then send one real message through the live form to confirm the last step.

Rerun the same task after every change to form fields, required rules, cookie or chat tools, and any service the form connects to. A new required question added for a campaign can refuse every entry without showing a message, and a connection that is switched off stops the send quietly. The same task and the same fields show the change the day it happens.