GoDaddy contact form not working: three stops

When a visitor presses Send, the form checks the fields and then posts the message to the address set for it. On a slow connection the button can spin for a long time, and the visitor, unsure whether anything happened, presses again or leaves. If the post fails, the visitor may get a vague error, or the form may close without one. If the post succeeds but the mail to you is held back, the visitor sees a thank-you line and you see nothing. From the visitor's side, a stuck button, a failed post and a delivered message look close enough to be the same.

• Fill the form on a phone using mobile data, and note whether the send button returns to normal.
• Press Send twice in a row and check whether the form blocks the second press or sends two messages.
• Leave one required field empty, and confirm the form names that field before it tries to send.
• Send a test message from an address you do not use for the site, then check your inbox and your spam folder.
• Find the setting that names the address the form sends to, and confirm you can open that inbox.

The first stop is the fields. The form checks each required field before it sends anything, so a field that is empty, or one that refuses what the visitor typed, stops the send right there. The second stop is the send itself. The form posts the message to its address, and a dropped connection or a blocked request fails here, often with a message that tells the visitor nothing useful. The third stop is delivery. The form has accepted the message, but the mail to your inbox can still be held, filtered or sent to the wrong address. Each stop needs a different check, and only the first two show up on the visitor's screen.

A message that the form accepted can end up in a spam folder, in a mailbox nobody reads, or in an inbox for an address you stopped using. Check the address the form sends to first, because a single wrong character sends every message to someone else. Then check the spam folder for the test message you sent from outside the site. If the test arrives there and not in your main inbox, the problem is your mail setup, not the form. A visitor who saw a thank-you line has no way to know any of this, so they never ask again.

The simulated visitor fills the required fields, presses Send, and waits for whatever the page shows next. The report records the step, a screenshot at the press, and any failed request or script error at that moment. A run that reaches the thank-you line counts as a send from the visitor's side. It does not follow the message into your mail, so the test ends at the confirmation. Pair each run with one test message you check by hand, and treat that check as the last stop.

Adding a field, changing a required setting or editing the contact page can stop the send with no visible error. Run the same simulated visitors after each change, from a phone as well as a laptop, and check that every one reaches the confirmation. Keep one test message going to an address you check, so you can confirm delivery as well as the button response.