![\"Tolinku](\"https:\/\/tolinku.com\/blog\/wp-content\/uploads\/2026\/03\/screenshot-banners-1772822959022.png\")
\nThe banners list page showing all configured smart banners with status toggles.<\/em><\/p>\n\n\n\nThe 2017 Policy in Plain Terms<\/h2>\n\n\n\n
Google announced the Intrusive Interstitials in Mobile Search ranking update<\/a> in August 2016 and rolled it out in January 2017. The policy applies to mobile pages that appear in Google Search results.<\/p>\n\n\n\n The core principle: if a user taps a search result and is immediately shown content that covers most of the page before they can read what they came for, Google considers that a negative user experience and may rank that page lower.<\/p>\n\n\n\n Google explicitly identified three formats that violate the policy:<\/p>\n\n\n\n The policy explicitly exempts several categories:<\/p>\n\n\n\n That last exemption is where smart banners live, if they are implemented correctly.<\/p>\n\n\n\n Google has not published a specific pixel count or percentage threshold for what counts as "reasonable." However, based on guidance from Google's John Mueller in various Google Search Central office hours<\/a> and community responses, the general consensus is:<\/p>\n\n\n\n Apple's own Safari Smart App Banner<\/a> is 80px tall on retina displays. This is widely considered the de facto standard for what a "slim" app install banner looks like. Most compliant custom banners target a similar height (72-100px) and position at the top or bottom of the viewport.<\/p>\n\n\n\n The key behavior requirement is that the banner must be easily dismissable. If a user has to take any action other than tapping a small "X" or close button to get rid of the banner and read the page content, the implementation may not pass muster.<\/p>\n\n\n\n It is worth being precise about what the penalty does. Google describes it as a "demotion" in mobile search rankings for pages that show intrusive interstitials when accessed from search. It is not a manual penalty, a site-wide penalty, or a penalty that affects desktop rankings.<\/p>\n\n\n\n This means:<\/p>\n\n\n\n For e-commerce sites and content publishers where significant traffic comes from mobile search, even a partial demotion on key landing pages can be costly.<\/p>\n\n\n\n What is particularly relevant for teams running smart banners is that Google's original announcement specifically mentioned app interstitials:<\/p>\n\n\n\n "Pages that show intrusive interstitials provide a poorer experience to users than other pages where content is immediately accessible. This can be problematic on mobile devices where screens are often smaller. To improve the mobile search experience, after January 10, 2017, pages where content is not easily accessible to a user on the transition from the mobile search results may not rank as highly."<\/p>\n\n\n\n The examples Google provided in its visual guidelines included a pop-up promoting an app install. This was not accidental: Google was responding to a specific pattern that had become widespread and that its user research showed frustrated mobile users.<\/p>\n\n\n\n The implication for smart banners is that the format, not just the fact of promoting an app, determines whether you are in compliance. A slim, dismissible banner is fine. A full-screen app install wall that a user has to close before reading your page is not.<\/p>\n\n\n\n For practical implementation purposes, the following size guidelines are widely accepted as compliant with Google's policy:<\/p>\n\n\n\n Height:<\/strong> Maximum 90-100px on mobile screens. This keeps the banner below roughly 10-12% of viewport height on typical smartphones.<\/p>\n\n\n\n Position:<\/strong> Top or bottom of the viewport, outside the main content flow. A banner that is part of the document flow and pushes content down can still cause a Cumulative Layout Shift (CLS)<\/a> problem, which is a separate ranking signal. More on that in the companion article on smart banners and SEO<\/a>.<\/p>\n\n\n\n Dismissal:<\/strong> A visible close button that removes the banner immediately. The button should be at least 44x44px in tap target size to comply with Apple's Human Interface Guidelines<\/a> and Google's Material Design accessibility guidelines<\/a>.<\/p>\n\n\n\n Timing:<\/strong> Best practice is to not show the banner immediately on page load for pages that receive significant organic search traffic. A brief delay (1-2 seconds) or a scroll-depth trigger means the user can confirm they have arrived at useful content before being prompted. Google has not specified that immediate-on-load banners are always penalized, but the spirit of the policy is about not blocking access to content.<\/p>\n\n\n\n Google moved to mobile-first indexing<\/a> for all new sites in 2019 and completed the rollout for existing sites in 2023. This means Google uses the mobile version of your page as the primary version for indexing and ranking.<\/p>\n\n\n\n Historically, some sites tried to detect Googlebot's user agent and suppress interstitials when the crawler was visiting. This approach is now explicitly against Google's policies (showing different content to Google than to users is cloaking) and may result in a more serious manual penalty.<\/p>\n\n\n\n The correct approach is to implement your banners in a way that is compliant for all users, and your ranking will reflect that. You do not need to suppress banners specifically for crawlers.<\/p>\n\n\n\n One nuance: Google typically crawls pages without executing JavaScript, which means if your banner is rendered entirely by JavaScript, the crawler may not see it at all. This is actually a compliance advantage: a JavaScript-rendered banner that does not affect the initial HTML render will not be seen by the crawler as blocking content. However, you should still implement it correctly because Chrome's rendering pipeline (which Google uses for JavaScript indexing) does execute scripts, and a penalizable banner that shows up in rendered pages can still affect ranking.<\/p>\n\n\n\n If you already have smart banners running, a quick audit against these criteria will tell you whether they are at risk:<\/p>\n\n\n\n Check the height.<\/strong> Load one of your banner-enabled pages on a mobile device and measure how much of the screen the banner covers. If it covers more than 15% of the viewport, it is worth revisiting.<\/p>\n\n\n\n Check the dismissal experience.<\/strong> Is there a visible, easily tappable close button? Can the user dismiss the banner and immediately see the full page content?<\/p>\n\n\n\n Check the timing.<\/strong> Does the banner appear before or during page load in a way that delays content access? Or does it appear after the page is readable?<\/p>\n\n\n\n Check for app-already-installed logic.<\/strong> If users who have your app installed see an "Open in App" banner, that is lower-friction and less likely to be considered intrusive because the user has already demonstrated intent. If the same users see a full install prompt, that is more aggressive and less justified.<\/p>\n\n\n\n Google's Mobile Usability report in Google Search Console<\/a> does not specifically flag intrusive interstitials, but the Core Web Vitals report<\/a> will surface CLS issues that often accompany poorly implemented banners.<\/p>\n\n\n\n\n
\n
What "Reasonable Amount of Screen Space" Means<\/h2>\n\n\n\n
\n
How the Penalty Works<\/h2>\n\n\n\n
\n
App-Specific Interstitials: The Direct Call-Out<\/h2>\n\n\n\n
\n
Banner Size Requirements<\/h2>\n\n\n\n
Mobile-First Indexing Implications<\/h2>\n\n\n\n
What to Do With Existing Implementations<\/h2>\n\n\n\n
Compliant Implementation in Practice<\/h2>\n\n\n\n