What Google actually penalizes
Since January 2017, Google applies a ranking signal against what it calls intrusive interstitials. The definition is far narrower than most people assume, and it is spelled out in their official announcement.
Only three cases count, and all three share one condition: they happen when someone has just arrived from a search result, on mobile. First, a pop-up covering the content as the page loads. Second, a block you must dismiss before you can read. Third, a layout that pushes the real content below the fold behind something that reads as a full-screen ad.
The operative word is cover. Google does not object to the pop-up itself: it objects to someone clicking through expecting an answer and hitting a wall.
What Google does not penalize (and almost nobody knows)
Explicitly excluded: exit-intent pop-ups, triggered as the cursor heads for the edge of the window. Ones firing later in the visit, after the person has read something. Banners and slide-ins sitting in a corner with the content still visible. And the cookie notice, which Google exempts outright because it answers a legal obligation.
It does not apply on desktop either: the signal was designed for mobile, where a covered screen is an unusable screen.
That reframes the whole conversation. The useful question is not *"should I use a pop-up?"* but *"when does it appear and how much does it cover?"*.
Six rules that make a pop-up help instead of hurt
One: make it a banner, not a full-screen modal. Two: keep it under 30% of the screen on mobile. Three: a visible close button, not an eight-pixel grey cross hidden in a corner.
Four: fire it after a real signal of interest — meaningful scroll, time on page or exit intent — never on load. Five: once per session; the second pop-up of the same visit does not convert, it annoys. Six: defer the load, so it does not push content around when it appears and wreck your CLS, one of the three Core Web Vitals.
None of the six is a design opinion. All six come straight from what Google measures.
Recognizing a visitor without breaking the law
A pop-up saying something relevant converts far better than a generic one. That means remembering what the person looked at last time — and this is where most implementations go wrong.
The temptation is to identify by IP address. Bad idea, on two counts. Technically, IP is a terrible identifier: several people in one office or home share it, and on mobile it changes constantly. Legally, in Canada an IP is personal data under [PIPEDA](https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/), with every obligation that entails.
The right alternative is storing a minimal signal in the person's own browser local storage: which section they viewed and when. It never leaves their device, identifies nobody, and must respect the cookie consent the site already asks for.
What we found measuring our own
We applied these rules on duolabs.tech, then verified them against the running site — which is where the surprises show up.
The banner measures 344 × 116 pixels on a 390 px phone: 12% of the screen, well under the 30% limit. It floats in a corner, covers nothing, and closes with a visible button or the Escape key.
But measuring for real exposed a flaw that reading the code never would have. The condition to show it was "the person has scrolled past 40% of the page". Sounds reasonable, and the percentage was chosen precisely to avoid a fixed pixel count, which means different things on a long article and a short landing page. The problem: on our landing page the scrollable area is 67 pixels. 40% of 67 is 27 pixels — an accidental brush of a thumb. The banner fired almost instantly, exactly what the rules say to avoid.
The fix was requiring both conditions at once: a percentage and a real distance. We share it because it makes the underlying point: you do not audit a pop-up by reading the code, you audit it by measuring the running site.