Mobile Pop-up Best Practices: Bars, Small Modals and Separate Mobile Creatives

Why mobile pop-ups need their own plan

Most pop-ups are designed on a desktop monitor and then checked on a phone, if they are checked at all. That order causes most of the problems people complain about. Four things are different on a phone:

These happen to every phone visitor, so a mobile pop-up deserves its own design pass rather than a shrunken copy of the desktop one.

What Google’s guidance actually says

Google Search Central has a page called “Avoid intrusive interstitials and dialogs.” Its main instruction is short: “Don’t obscure the entire page with interstitials.” It explains that intrusive dialogs and interstitials “make it hard for Google and other search engines to understand your content, which may lead to poor search performance.” As an alternative, it recommends that you “use banners that take up only a small fraction of the screen,” and adds that “you can reuse these small containers for other kinds of notifications, such as newsletter sign-up prompts” (Google Search Central).

The same page lists two other points worth knowing. First, it says not to redirect the user to a separate page for their consent or input — put the prompt on the page instead. Second, it notes that mandatory interstitials, such as an age gate where the user must provide their age, are exempted from that guidance. A marketing pop-up for a coupon or a newsletter is not mandatory, so it falls under the “small fraction of the screen” advice.

Google’s page experience documentation includes a self-assessment question that sums it up: “Do your pages avoid using intrusive interstitials?” It also asks, “Is your page designed so visitors can easily distinguish the main content from other content on your page?” The same page is clear that a good page experience alone “doesn’t guarantee that your pages will rank at the top of Google Search results” (Google Search Central, page experience). So treat the guidance as a design standard for visitors, not as a ranking trick.

Choosing a format for phones

Pop-up tools usually offer three display styles: a modal (centered, often with a dimmed background), a floating box (sits in a corner or at an edge without dimming the page), and a bar (a thin strip across the top or bottom). On mobile they behave quite differently.

A practical default for phones: use a bar for information and a small modal only when the visitor has to type something or make a choice. If a message does not need an action — “Free shipping over $50,” “Sale ends Sunday” — it does not need to interrupt anyone. For more on wording a threshold message, see Free Shipping Banners: Where to Show Them and How to Word the Threshold.

Bars on mobile: top or bottom, overlay or push

Top or bottom. A top bar is read first and sits where people expect announcements. A bottom bar sits closer to the thumb, so a “Shop now” or “Get the code” button is easier to tap. The bottom of a phone screen is also where many stores put sticky “Add to cart” buttons, cookie notices and chat launchers, so check what is already there before you claim that space.

Overlay or push. A bar can float on top of the page (covering a strip of the header or content) or be inserted into the page so that everything below moves down. Floating is less disruptive to the layout but hides whatever is under it, which on many sites is the logo, the menu button or the cart icon. Pushing keeps the header visible but moves the content. When content moves while someone is reading or about to tap, that is a layout shift, which Google measures as Cumulative Layout Shift (CLS); web.dev notes that layout shifts “only occur when existing elements change their start position” (web.dev, CLS). There is no universally right choice; pick the one that covers nothing important and moves nothing unexpectedly on your own pages.

Write mobile bar copy for a single line at phone width. If the desktop version reads “Free standard shipping on all orders over $50 — this week only,” the mobile version may need to be “Free shipping over $50.” Two-line bars on a phone start to look like a small modal glued to the top of the screen.

Sizing a small modal

When a modal is the right tool, the goal is a box that is clearly a pop-up — something on top of the page, not a replacement for it. These checks keep it in that zone:

1. Leave the page visible around the modal. On a phone, some of the page should show above and below the box, not just a thin border on the sides.
2. Cut the content before you shrink the text. One headline, one supporting line, one field or one button. A long list of benefits belongs on a landing page.
3. Keep body text readable without zooming. If you have to make text tiny to fit, there is too much text.
4. Don’t rely on a fixed height. Mobile browsers change the visible height as their toolbars appear and disappear. MDN explains that browsers “often hide part or all of the title and address bar after a user starts scrolling the page,” which is why CSS has separate small, large and dynamic viewport units (MDN, <length>). A box sized to exactly 100% of one height can end up cut off.
5. Check it in landscape, too. A modal that fits a phone held upright can overflow when the phone is turned sideways, leaving the close button off-screen.

Make closing easy with a thumb

The close button is the part of a mobile pop-up that gets the least design attention and causes the most frustration. On desktop a 16-pixel “×” is fine; on a phone it is a target people miss and then tap the offer by accident.

Two published references help with sizing. The W3C’s WCAG 2.2 success criterion 2.5.8, Target Size (Minimum), says “the size of the target for pointer inputs is at least 24 by 24 CSS pixels,” with exceptions for targets that have enough spacing around them (W3C, Understanding SC 2.5.8). web.dev’s article on accessible tap targets goes further and says “a minimum recommended touch target size is around 48 device independent pixels,” spaced “about 8 pixels apart” (web.dev, Accessible tap targets). Treat 24 pixels as the floor and aim for something closer to 48 on phones.

1. Make the close button large and high-contrast, with a visible background behind the “×” so it doesn’t disappear against a busy image.
2. Put it where people look — usually the top right corner of the box — and keep it inside the screen, not hanging off the edge.
3. Let a tap outside the box close it for a modal with a dimmed background. People instinctively tap the dark area to get back to the page.
4. Don’t delay the close button. A close button that appears after a few seconds turns a pop-up into a wait.
5. Keep a text alternative such as “No thanks” if you use one, but don’t make it guilt-tripping. A plain decline is better for trust.

Separate mobile creatives: when one image is not enough

Image-based banners are where mobile designs most often break. A wide desktop image scaled down to a phone turns a readable headline into tiny text, and a tall mobile image scaled up to a desktop becomes enormous. If your banner is an image with text in it, you usually need two versions.

A quick test for whether you need a separate creative: put the desktop image on your phone at the size it would appear in the pop-up and try to read every word at arm’s length. If you squint, make a mobile version.

Forms inside mobile pop-ups

Email sign-up pop-ups are the most common modal on mobile, and the form is where they fail. When the visitor taps the email field, the keyboard opens and covers a large part of the screen. If the submit button is now hidden, many people will give up rather than scroll inside a pop-up.

1. Ask for one field. An email address is enough for a discount code or a newsletter. Every extra field is more typing on a small keyboard.
2. Use the right input type so phones show the email keyboard with the “@” key.
3. Put the button directly under the field, not below a block of text, so it stays visible when the keyboard opens.
4. Keep consent text short and readable, and link to your privacy policy rather than pasting it in.
5. Show the result clearly — the code, or a “Check your inbox” message — and let people copy a code with one tap if you show it on screen.

For the offer itself, how to ask, and what to do after someone signs up, see Email Sign-up Pop-ups. For general form design on small screens, see Form UX Best Practices.

Timing and targeting on phones

A pop-up that appears the moment a phone page loads blocks the very content the visitor tapped through to see — often from a search result or an ad. On mobile it is usually better to let people start reading first. Two simple triggers work well:

Targeting matters more on mobile, because every pop-up costs more screen space. Show a sign-up offer to first-time visitors rather than to people who already subscribed, show a campaign banner only to visitors who arrived from that campaign’s ad, and keep a banner off pages where it gets in the way, such as checkout. See Target Returning Visitors for visit-based rules and UTM Parameters for tagging campaign links so you can target by traffic source.

A mobile pop-up checklist before you publish

1. Open it on a real phone, not only a desktop browser’s device preview. Toolbars, keyboards and font rendering behave differently on the real thing.
2. Check the smallest phone you can find as well as a large one.
3. Confirm the page is visible around the pop-up and that it does not cover the menu, cart icon or primary button.
4. Tap the close button with your thumb, one-handed, five times in a row. If you miss once, make it bigger.
5. Tap outside a modal and confirm it closes (if you enabled that) and that the page scrolls normally afterward.
6. Fill in the form with the keyboard open and make sure the button is still reachable.
7. Rotate the phone to landscape and check that nothing is cut off.
8. Read every word of an image banner at arm’s length.

Measuring mobile behavior

Impressions and clicks tell you whether a banner gets attention, but on mobile it is just as important to see what the pop-up does to the rest of the visit. Look at how far phone visitors scroll and what they tap on the pages where the pop-up appears, and compare that with the same pages before you launched it. A heatmap is a practical way to do this; see Website Heatmaps for how to read one. If the pop-up feeds a sign-up or a coupon, track what happens next as well — a micro-conversion such as reaching the cart page can show progress before an order happens.

Setting up mobile pop-ups in marketingLABO

marketingLABO’s pop-up banners include the settings this guide talks about. Here is how they map:

A typical setup for a store that wants a sign-up offer on desktop and a lighter touch on phones looks like this:

1. Create a desktop banner from one of the English templates — for example an email sign-up modal — and set Device to desktop only.
2. Create a second banner for phones, such as a bar with a short line and a button that opens your sign-up page, and set Device to mobile only.
3. Set a trigger on both, such as after N seconds or at a scroll depth, instead of showing them immediately.
4. Target first-time visitors with visit frequency, and exclude checkout pages with the page URL setting.
5. Preview on a real phone, run through the checklist above, then publish and watch impressions and clicks per campaign.

If one design works on both but the image doesn’t, keep a single banner on all devices and upload a separate mobile image instead. One detail worth knowing: the device setting is decided from the browser’s identity, while the separate image switches by screen width, so preview tablets in particular before you publish. The Free plan includes one pop-up banner, and Light and Standard add more; see pricing for the current limits, or sign up to try it on your own site.

Frequently asked questions

Are pop-ups bad for mobile SEO?

Google’s guidance targets interstitials that obscure the entire page, not every pop-up. It recommends banners that take up a small fraction of the screen and explicitly mentions newsletter sign-up prompts as a use for them. Keep mobile pop-ups small and easy to close, and you are following the guidance as written.

Should I turn pop-ups off on mobile entirely?

Not necessarily. Phone visitors still want to know about free shipping or a sale. What usually works better is a lighter format on phones — a bar instead of a modal — and stricter targeting, so fewer people see a pop-up they don’t need.

Is a cookie or age notice treated the same way?

Google’s page says mandatory interstitials, such as an age gate, are exempted from the guidance. Marketing pop-ups are not mandatory. On phones, also make sure your own banner doesn’t sit on top of a required notice or its buttons.

Do I need a separate mobile design for every banner?

Only when the desktop version doesn’t read well on a phone. Text-only bars and simple layouts often work on both. Image banners with text baked into the picture almost always need a mobile version.

Summary

Design mobile pop-ups for the phone first. Use a bar for information and a small modal only when the visitor needs to act. Keep the page visible around it, make the close button big enough for a thumb, give image banners a separate mobile creative, and let visitors start reading before anything appears. Then test on a real phone — with the keyboard open and the screen turned sideways — before you publish.

Sources

1. Google Search Central, “Avoid intrusive interstitials and dialogs” (last updated December 10, 2025; accessed October 12, 2026): https://developers.google.com/search/docs/appearance/avoid-intrusive-interstitials
2. Google Search Central, “Understanding Google Page Experience” (last updated September 22, 2026; accessed October 12, 2026): https://developers.google.com/search/docs/appearance/page-experience
3. W3C WAI, “Understanding Success Criterion 2.5.8: Target Size (Minimum)” (accessed October 12, 2026): https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
4. web.dev, “Accessible tap targets” (last updated March 31, 2020; accessed October 12, 2026): https://web.dev/articles/accessible-tap-targets
5. MDN Web Docs, “<length>” (viewport-percentage units; accessed October 12, 2026): https://developer.mozilla.org/en-US/docs/Web/CSS/length
6. web.dev, “Cumulative Layout Shift (CLS)” (last updated April 12, 2023; accessed October 12, 2026): https://web.dev/articles/cls