Before you launch or pay for traffic

Newsletter sign up form: where readers see it

The form works when you test it on a laptop with the cookie bar already dismissed. A reader on a phone meets the banner, the header and the frame first, and a simulated reader can show you which one sits on top of the Subscribe button.

5 visitors try to .
First test free with an accountRun it from your coding agent

Why does a newsletter sign up form get few sign ups on a post?

Often the reader can see the form and still cannot press Subscribe, because a cookie bar, a sticky header, a pop-up or an embedded frame sits on top of the button or cuts off its fields. Once the reader does press, the success line can appear out of view, so they press again and read an error that makes the form look broken. Check the form on a phone with the cookie bar open, and check what appears under the button after one press. A simulated reader shows the layer that covered the button and a screenshot after the press, which tells you which of these is losing subscribers.

What this looks like in a report

Who
Ayodele, a teacher looking for a weekly science digest
How they arrived
Opened a post from a link in a group chat, on her phone
Where they stopped
Subscribe button, under the cookie bar at the end of the post

“I want the weekly issue and the form is at the bottom. The cookie bar covers the button. When I tapped where it should be, I hit Accept all, and the form slid off the screen.”

The fix. Keep the Subscribe button clear of the cookie bar on phones, by moving the form above the bar's space or giving the bar a fixed height. After a press, show the success line directly under the button, then check it on a phone with the bar open.

An illustration. Run a test to see your own.See a real sample report

A cookie banner covers the Subscribe button on a phone

A reader reaches the end of a post and finds the newsletter form where the owner put it, at the bottom. On a phone, a cookie bar sits along the lower edge of the screen, a sticky header hides the top of the form, and a pop-up may still be open from the first visit. The reader taps where the button should be and hits Accept all, or the header catches the tap. The owner tested on a laptop with the banner already dismissed, so the form looked fine. The reader sees a form that is hard to use, and leaves.

  • The Subscribe button sits clear of the cookie bar, any sticky header and any pop-up on a phone.
  • An embedded form shows every field, with no inner scroll bar hiding the button.
  • The success line appears next to the button, where the reader is already looking.
  • A reader who is already subscribed sees a plain message, not an error that looks like a failure.
  • The form appears in the same place on every post, not only on the homepage.

The layers on top of the form on a phone

Three layers commonly sit over a newsletter form on a phone: the cookie bar, fixed to the top or bottom of the screen; a sticky header; and a pop-up, which may take the whole screen and close with a small control. An embedded form may sit in a frame with a fixed height, so on a narrow screen it shows the first field and hides the button in a scroll area. The wrong version sets that height once on a laptop and never checks it again. The right version uses a frame that resizes to its content, or a form built into the page, and tests the layers on a phone at the end of a post.

Where the success message goes

A reader presses Subscribe, and the success message appears above the visible screen, where they are no longer looking. They press again. The second press is a duplicate, and the tool may answer that the address is already subscribed, which reads as a failure to someone who just tried to sign up. The wrong version shows the message in a separate box at the top of the page. The right version places the message directly under the button, says the subscription worked, and names the next step, such as the confirmation email, if the list needs one. A simulated reader's screenshot after the press shows where the message landed, and whether the button still looks active.

Where the form sits decides whether a reader reaches it

The form can also sit too far down to matter. A footer form is seen only by readers who reached the bottom, and a reader who stops earlier never sees it. The wrong version places one form in the footer of every page. The right version places a form once after the first paragraph or two, when the reader knows what the newsletter covers, and once more at the end. The screenshot tells you where a reader stopped. A simulated reader that stops above the form never reached it, so move the form up. A simulated reader that stops on the form, with the button covered or the success line lost, reached it, so the cause is the layers.

What you get with Mimiq

  1. 01

    Run it by hand, or on every pull request

    Paste a link and a task in the app and watch the visitors work. Or run them on every preview deploy: the GitHub Action comments on the pull request, any other CI can call the MCP endpoint, and your coding agent can run it too.

  2. 02

    Bugs and usability problems in one report

    The browser records errors and failed or slow requests on the step they happened. The visitors say where the wording or the steps confused them, and where they left.

  3. 03

    Visitors that behave like your audience

    Each visitor is a different profile with a reason to be there, matched to who the page is for, described by you, or built from your own customers.

  4. 04

    A prompt to fix each problem

    Every problem comes with a fix to paste into Cursor, Claude Code, Lovable or any coding agent, and one prompt hands over the top problems at once. Then send the same visitors through again.

  5. 05

    Follow every visitor

    See each visitor's whole path, step by step with screenshots, and what it was thinking at every step. Ask any visitor a question.

The browser records relevant JavaScript errors and failed or slow app requests encountered during the run, attached to the step where they occurred. The visitors are simulated: they find problems, they do not predict how many real people will convert.

A new pop-up or consent tool can cover the form again

A team adds a discount pop-up, a chat widget or a new consent tool, and the Subscribe button goes under it without anyone noticing on a laptop. Run the same visitors to the form on a phone after each addition, and read the screenshot at the step where they try to subscribe. With paid credits, visitors can reach protected previews, so a redesigned post template can be checked before it goes live.

Starter

Try it on one launch

$9 once
120 credits, never expire

About 4 tests of 5 visitors

  • Visitors on your landing page, signup and checkout
  • Where they left and why, with a fix to copy for each problem
  • Run it in the app or on every pull request
  • Ask any visitor a question, included
  • Test accounts and protected previews
Buy 120 credits

Builder

Test every build

$19 a month
500 credits every month

About 20 tests of 5 visitors

  • Everything in Starter
  • Credits refill each month, and what is left rolls over once
  • Cancel anytime
Choose Builder

Pro

Test every release, as a team

$49 a month
1,500 credits every month

About 60 tests of 5 visitors

  • Everything in Starter
  • Credits refill each month, and what is left rolls over once
  • Cancel anytime
Choose Pro

Scale

Test at scale, every day

$149 a month
6,000 credits every month

About 240 tests of 5 visitors

  • Everything in Starter
  • Credits refill each month, and what is left rolls over once
  • Priority support
  • Cancel anytime
Choose Scale
$0for your first test, with a free account (Google sign-in, no card). It includes 50 credits, enough for 10 visitors. After that a visitor uses 5 credits, and packs start at $9 for 120 credits.
See a sample report

Questions

Where should a newsletter form go on a post?

Put it once after the first paragraph or two, when the reader knows what the newsletter covers, and once at the end. A form in the footer alone is seen by readers who reached the bottom. Name the topic or the next issue beside the form, so the reader knows what they are subscribing to.

Should I use a pop-up for the newsletter?

A pop-up can work, but it has to close with one tap and must not cover the cookie choice or the Subscribe button. Test it on a phone, where a pop-up often takes the whole screen and the close control is small. Keep the inline form too, for readers who closed the pop-up.

Can a simulated visitor show me my sign-up rate?

No. It does not predict how many readers will subscribe, and it does not measure a rate. It shows whether the simulated reader reached the form, which element covered the button, and what appeared after the press. Your rate comes from the newsletter tool's count against real post views.

Does the form need a name field?

Usually not. A name field adds a step and one more thing to type on a phone. Ask for a name only when you send by name, and make it optional when you do. The email field alone is enough for most newsletters.

Keep reading

Send visitors and see what breaks first.

Your first test is free: sign in with Google and it starts right away. Last checked 2026-11-02.

5 visitors try to .