Pop-ups on a Business Website Without Hurting SEO or Users

Interstitials, dialogs and banners

Google's guide to avoiding intrusive interstitials and dialogs uses two words. Interstitials "are overlays on the whole page" and dialogs "are overlays only on a part of the page". It calls them intrusive when they "obstruct users' view of the content, usually for promotional purposes". A banner is the third option: a strip that takes up a small part of the screen and leaves the page readable.

The words matter less than the effect. What counts is whether a visitor who arrives from a search result can see and read what they came for without first fighting their way past something.

What Google says

Google's position is that intrusive overlays hurt twice. The interstitials guide says interrupting users "may frustrate them and erode their trust in your website", and 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."

The rule goes back to a 2016 announcement on the Google Search Central blog, helping users easily access content on mobile. It said that from 10 January 2017, pages where content is not easily accessible to a visitor arriving from mobile search results "may not rank as highly". It gave three examples of what makes content less accessible:

• a popup that covers the main content, either straight after the visitor arrives from search or while they scroll through the page;
• a standalone interstitial the visitor has to dismiss before reaching the main content;
• a layout where the top of the page looks like a standalone interstitial and the real content sits below the fold.

Keep this in proportion. The same post calls the signal "just one of hundreds of signals that are used in ranking" and says a page may still rank highly if it has great, relevant content. Google's page experience guidance lists the question "Do your pages avoid using intrusive interstitials?" alongside questions about ads, HTTPS and Core Web Vitals. It is part of the overall experience, not a switch that removes a page from search.

The interstitials guide also names two mistakes to avoid unless an overlay is legally required: don't obscure the entire page, and don't redirect the visitor to a separate page for their consent or input.

Overlays Google treats differently

The 2016 post lists techniques that "used responsibly, would not be affected" by the signal:

• interstitials that respond to a legal obligation, such as for cookie usage or age verification;
• login dialogs on sites where the content is not publicly indexable, such as private content like email, or content behind a paywall;
• banners that use a reasonable amount of screen space and are easily dismissible.

The current guide calls these mandatory interstitials. It says they are exempt from its guidelines, but still recommends overlaying the content rather than replacing it, so Google can at least index some of it, and not redirecting requests to one consent page. Redirecting every address to a single page "will remove all but that one page from search results". For an age gate in front of adult content, it suggests letting verified Googlebot requests through without the gate.

A cookie banner that is legally needed is therefore not the problem. A promotional pop-up that covers the page on arrival is. If you are setting up consent, our guide to cookie consent banners covers what the banner has to do.

Less intrusive ways to ask

Google's own suggestion is to "use banners that take up only a small fraction of the screen" instead of full-page interstitials, so that visitors and search engines reach the content as soon as the page loads. For app installs it points to the browser-supported options, such as Smart App Banners in Safari, or a simple HTML banner that links to the right app store. It says the same small containers can be reused for other notices, such as newsletter sign-up prompts.

In practice that leaves several options that do not get in the way:

• A sign-up form placed in the page itself, at the end of an article or in the footer.
• A slim bar at the top or bottom of the screen that can be closed in one tap.
• A dialog that opens only when the visitor asks for it, for example by pressing a "Get the guide" button.
• A clear call to action on the page, which on a landing page usually does more than an overlay. Our landing page guide covers how to build one around a single action.

Google also notes that many content management systems have plugins for common dialogs such as newsletter sign-ups, and that well-maintained plugins can help because their developers improve them at scale. Choose one you can configure: when it appears, how often, and how it closes.

Pop-ups and layout shift

An overlay that floats above the page does not move anything. A bar that is pushed into the page after it loads, shoving the content down, does. Google's web.dev article on Cumulative Layout Shift says unexpected movement often happens when elements "are dynamically added to the page before existing content", and that it can make people lose their place or click the wrong link. Good CLS is 0.1 or less.

Shifts that come within 500 milliseconds of user input are flagged so they can be excluded, so a box that opens because someone pressed a button is treated differently from one that appears on its own. If you add a bar at the top, reserve its space from the start or lay it over the content instead of inserting it. Our guide to Core Web Vitals explains how CLS is measured.

What accessibility asks of a pop-up

Several WCAG 2.2 success criteria apply directly to overlays:

• No keyboard trap (2.1.2, Level A). If keyboard focus can move into a component, it must be able to move out again with the keyboard. Understanding 2.1.2 says keeping focus inside a modal dialog does not fail as long as the user knows how to leave it, and notes that the Esc key is a commonly used way out.
• Focus not obscured (2.4.11, Level AA). When an item receives keyboard focus, it must not be entirely hidden by content the site added. Understanding 2.4.11 names sticky headers, sticky footers and non-modal dialogs as typical causes, and says a cookie banner fails if it entirely hides the item being focused. Making the banner modal, or using scroll padding so it does not overlap other content, are ways to pass.
• Content on hover or focus (1.4.13, Level AA). For boxes that appear when a pointer hovers or keyboard focus lands, Understanding 1.4.13 asks that they can be dismissed without moving the pointer or focus, stay visible while the pointer moves over them, and remain until the visitor removes the trigger or dismisses them.

The underlying point is simple: anyone using a keyboard, a screen reader or a magnifier must be able to notice the overlay, use it and leave it. Our guide to website accessibility basics covers the wider standard.

Building a dialog that works

The W3C's modal dialog pattern in the ARIA Authoring Practices Guide describes the expected behaviour:

• When the dialog opens, focus moves to an element inside it, usually the first focusable element.
• Tab and Shift + Tab cycle through the controls inside the dialog and do not leave it.
• Escape closes the dialog.
• When it closes, focus returns to the element that opened it, unless that element no longer exists.
• The guide strongly recommends a visible close button, such as a close icon or cancel button, in the dialog's tab sequence.
• The container has the dialog role, aria-modal set to true, and a label, ideally from a visible title.

The pattern also warns that marking a dialog modal when it does not behave as one for everyone has "severe negative ramifications" for some assistive technology users. Only mark it modal when the page behind it really cannot be used and is visually obscured.

You do not have to build all this by hand. MDN's reference for the HTML dialog element says that opening it with showModal() makes the rest of the page inert and that a modal dialog opened this way can be closed with the Esc key. MDN recommends putting the autofocus attribute on the element people are expected to use first, or on the close button if nothing else needs immediate interaction.

A quick check for your site

• Open a page on your phone from a Google search. Can you read the main content straight away?
• List every overlay on the site and mark which are legally required and which are promotional.
• Make sure promotional boxes do not cover the page on arrival; use a banner or an in-page form instead.
• Check that every overlay has a visible close button that works with a tap, a click and the Esc key.
• Tab through the page with a keyboard. Focus should move into an open dialog, stay there and return afterwards, and no sticky bar should hide the focused item.
• Make sure no URL redirects to a separate consent or sign-up page.
• Look at CLS in Search Console or PageSpeed Insights after adding any bar.

Frequently asked questions

Will a pop-up get my site penalised by Google?

Google says pages whose content is not easily accessible from mobile search results may not rank as highly, and that intrusive overlays make content harder for search engines to understand. It also calls this one of hundreds of ranking signals, so a strong, relevant page can still rank. The safe course is not to cover the content on arrival.

Are cookie banners and age gates a problem?

Not if they respond to a legal obligation and are used responsibly. Google exempts mandatory interstitials such as cookie notices and age verification, but recommends overlaying the content rather than redirecting visitors to a separate page.

Is an exit-intent or timed pop-up acceptable?

Google's 2016 examples include a popup that covers the main content while the visitor is looking through the page, not only on arrival. A small, easily closed banner or an in-page form is the lower-risk choice.

What makes a pop-up accessible?

Focus moves into it when it opens, Tab stays inside it, Esc and a visible close button close it, and focus returns to where it was. The page behind should be inert while a modal is open, and no sticky bar should hide the item that has keyboard focus.

Should I use the HTML dialog element?

It is a good starting point. MDN says opening it with showModal() makes the rest of the page inert and lets the Esc key close it, which covers several of the behaviours the W3C modal dialog pattern expects. You still need a clear label, a visible close button and testing with a keyboard and screen reader.

Want a site where sign-up forms, cookie notices and offers work for visitors and search engines alike? See our website development service and all our services, or email [email protected].