Google Interstitial Penalty: How It Works & How to Recover

I run a content site that monetized with popunder ads, watched its Google impressions fall off a cliff, and spent weeks untangling which Google rule actually applies. Most articles online treat "interstitial penalty" as one vague punishment. It isn't. Google now has two separate mechanisms that people confuse, and the recovery steps are different for each. Here's the accurate picture, based on Google's own documentation and my site's real data.

What exactly is the interstitial penalty?

The original policy dates to 2017. On August 23, 2016, Google announced that starting January 10, 2017, pages where content isn't easily accessible on the transition from mobile search results "may not rank as high." The current documentation lives under Search Central's avoid intrusive interstitials guidance. What it covers:

• Full-screen or near-full-screen overlays shown immediately when someone lands from mobile search
• Standalone interstitial pages that force a dismiss step before content appears
• Layouts where the ad pushes content below the fold so the first screen is mostly promotion
• The ad-heavy "top of page" pattern that dominates the viewport

The common thread: the interruption sits between the click and the content. Google's guidance is per-page, not sitewide — a great page with an intrusive overlay loses less than a thin page with the same overlay. And it explicitly exempts legal necessities (cookie consent, age gates), login walls for gated content like paywalls, and reasonably sized banners that use space already reserved for them.

What changed in 2026: back button hijacking is now spam

This is the update most 2026 guides are behind on. On April 13, 2026, Google Search Central announced a new spam policy: back button hijacking became an explicit violation under the "malicious practices" section of the spam policies, with enforcement starting June 15, 2026. Google's definition: a site that interferes with user browser navigation — by manipulating browser history or other functionality — so users can't use the back button to return where they came from.

Why it matters for this topic: pop-based ad scripts are a common vector. A script that opens a chain of pages, rewrites history entries, or traps the user so "back" cycles through the ad domain instead of leaving is doing exactly what this policy bans. Key consequences to understand:

• It can trigger a manual spam action (visible in Search Console's Manual actions report), not just an automatic demotion
• It's domain-level — the action targets the site, not one page
• Third-party scripts don't protect you — Google's examples make clear that a violation caused by a script you embedded is still your violation
• It runs on both mobile and desktop, unlike the 2017 interstitial guidance which is mobile-focused

If you run pop-up or popunder ads, you're potentially touching both rules. A full-screen pop-up on mobile arrival is an interstitial-quality problem. A script that also manipulates history or traps the back button is a spam problem — and a far more serious one.

How to check if your site is affected

Before changing anything, diagnose which track you're on. Five checks, in order:

1. Search Console → Manual actions. If anything shows here, you're on the spam track. This is the only place Google explicitly tells you about a penalty.
2. Real SERP test on mobile. Search your main keyword, click through, and watch the first 10 seconds. Does an overlay appear before content? Can you read without dismissing anything?
3. Back button test. From your own article page, press back repeatedly. Does it return to the previous page — or cycle through ad pages, your homepage, or a redirect chain?
4. Audit third-party scripts. Open DevTools, list every script that loads on a landing page, and grep each for history.pushState, history.replaceState, or window.open loops. Ad networks can inject behavior you never wrote.
5. Compare impressions before/after the ad launch. In Search Console, look at the date the script went live. A cliff on that exact day, with stable indexing, points to a quality-signal drop rather than an indexing problem. (More on this below.)

How to recover (with a real case)

Here's what a quality-signal drop actually looks like, from my own site's Search Console data. This is not a hypothetical — these are our real numbers:

Notice what did not happen: indexing stayed healthy (30-32 of 36 pages, 89%) through the whole drop. Google didn't deindex anything. It stopped showing the pages — the classic quality-signal retreat, not a spam action. The fix we applied, in order:

1. Removed the popunder script from every page and confirmed zero references in the deployed HTML (a fingerprint match on the loader file, then a live check).
2. Resubmitted the site — sitemap stays current and we pushed the updated pages through IndexNow so Google re-crawls without waiting for natural discovery.
3. Left the structure untouched. No redirects, no URL changes, no mass edits — Google needs stable signals to re-evaluate, not churn.
4. Waited, with checkpoints. Recovery from a quality-signal drop on a healthy site typically takes 4-6 weeks. Googlebot returned to crawling within days; impressions take longer.

The honest part: there's no "request review" button for automatic demotions — Google re-evaluates on its own schedule. If you're on the spam track instead (a manual action exists), the path differs: remove the violating behavior, then use Search Console's manual action flow to request a review once it's verifiably gone.

Frequently asked questions

Related: our full breakdown of which pop ads hurt rankings covers the exemption list and pop-under risk in depth; the PP-OCRv6 test shows how we audit on-device behavior when we review ad and tool scripts.