Mailchimp signup form not working: where it fails

The embed is code you paste from Mailchimp into your page, and the page can change what that code does. A cookie banner, a theme script or a page builder can catch the submit before the form reaches Mailchimp, so the button looks pressed and nothing leaves the page. Some visitors run ad blockers or privacy extensions that stop requests to Mailchimp's address, and the form fails with no message. A signup that does go through may wait for a click on a confirmation email, so the audience shows nothing new for a while. The owner who signs up with a known address never meets any of these.

• Press Subscribe with the network tab open. No request to Mailchimp means the page or a blocker stopped it.
• Try the form in a private window with blockers off, then with them on, and compare the two results.
• Search the audience for the address. A pending entry is waiting for a confirmation click.
• Check the embed code. It must belong to the audience you are reading, not an older one you replaced.
• Read every message the form shows after Subscribe, including any line near the top of the form.

The first point is the page. The embed code sends the form to a Mailchimp address, but the browser sends it only if your page lets it. A theme script or a page builder that handles the form's submit event on its own can prevent the default send, so the button looks pressed while the request never leaves. Open the page in a private window to see what a first-time visitor loads, because the scripts can differ from the ones in your own session.

The second point is the visitor's browser. A blocker or a privacy setting can stop requests to Mailchimp's address, and the form then shows no message, because no reply ever arrives. The third point is Mailchimp itself. An address that is already subscribed, or one that unsubscribed earlier, can be refused, and a form pointed at an older audience adds the subscriber to a list you no longer read.

Press Subscribe with the browser's network tab open and look for a request to Mailchimp's address. No request means the page or a blocker stopped the send, so compare a private window with blockers off. A request with a success reply and a visible thank you means Mailchimp accepted it. A refusal comes back as a message, and the form displays the message it received.

Then check the audience. Open the audience the form belongs to and search for the address. A pending entry means the subscriber has not confirmed yet. If the address is missing entirely, the request never reached that audience, and the embed code is the likely cause. Compare the audience you searched with the one named in the embed code before you change anything.

The run starts on the page that holds the form, such as the journal page's signup box, and the visitor types an address with a working inbox into it. It presses Subscribe and reports the message the page showed, with a screenshot and any blocked or failed request on that step. If the audience asks for confirmation, the email arrives in the run's inbox, so you can check that it was sent.

The run stops at the form's message. It cannot read your audience, the pending list or the embed code, so it cannot tell you why an address was refused. Check the audience yourself after each run, then run the visitor again to see whether the message changes. Keep the address you used, so you can search for it in the audience.

A script added for analytics, a cookie banner or a theme update can catch the submit again, and the signup then stops quietly. Rerun the same visitor after each change, in a private window and on a phone. Owners behind a site password add it to the run, and they check the signup on each preview deploy before it goes live.