ConvertKit form not working on your page

Some email tools hold a new subscriber until the person clicks a link in a confirmation email. If your form works that way, the visitor sees a short line asking them to check their inbox, and may read it as a failure. If the email is slow or lands in spam, they submit again. A second cause is a success message hidden under a sticky header or a cookie banner. The owner sees subscribers arriving and assumes the form works, but visitors who never confirm may never count as subscribers.

• Submit the form with a new address and read the message that appears. Note whether it asks you to confirm by email.
• Check the inbox for the confirmation email, the spam folder included, and note how long it takes to arrive.
• Open the console after submit and look for a blocked request, such as one to the email tool's address.
• On a phone, scroll to the form and confirm no banner or sticky header covers the success message.
• Compare the subscribers in your list with the submits you made in testing, to see which never confirmed.

The visitor types an address and presses Subscribe. The button may show a small spinner, then return to its old label, with no message at all. Or the form may clear and show a line of small text somewhere a phone's keyboard has pushed out of view. A visitor who sees nothing has no way to know whether the signup worked, and some will not try again. The owner, testing from a laptop with the address already saved, may see a clear success message and never see the phone version.

Confirmation is the cause that looks like a failure. A confirmation step asks a new subscriber to click a link before they count as subscribed, and the page should say so under the button in plain words, such as: check your inbox to confirm your address. Without that line, the visitor reads a quiet form as a broken one. Send the confirmation to the address you test with, and time how long it takes, since a slow email reads as a failed signup to someone waiting on the page.

Blocked requests and covered messages look different in the browser. A blocker or privacy setting can stop the request to the email tool's address, so nothing reaches the list, and the console shows the refused call. A banner or sticky header can cover the success line on a phone, so the request works and the visitor sees nothing. Compare the list after each test, and check the console on the press, to tell which of the two is happening.

A simulated visitor fills in the form, presses Subscribe, and records what appeared on the screen. Mimiq visitors have a working inbox, so a confirmation email sent to them can arrive, and the report shows whether that step was reached. The run does not read your email tool, so it cannot tell whether the subscriber is on the list, confirmed, or tagged for the right sequence. Check those in your account, under the address the visitor typed.

Pages change after launch. A new cookie banner, a sticky header or a pop-up can cover the success line, and a theme update can block the request. Run the same signup from a phone and a laptop after each change, and read what the visitor sees before the next campaign sends traffic to the page.