A consent banner asks the visitor to make a decision before the page is fully theirs. A person reads it, clicks, and forgets it. An agent cannot click. It fetches the page, finds the dialog in the markup, and has no way to accept, reject or close it, so whatever the dialog covers stays covered. That is an interstitial, and it is why check A6, "no hard interstitial", treats a cookie wall the way it treats a CAPTCHA or a challenge page, with one difference: a cookie wall on its own scores one of the check's two points rather than zero. This post explains what the scanner looks for, why the score is what it is, and why our own site has no banner at all.
What an interstitial is to an agent
An agent meets a page in one of two ways: a plain fetch of the HTML with no browser, or a headless browser working from the rendered page. The two fetches covers the difference; for consent dialogs it decides what the agent experiences.
For the plain fetch, a banner in the server-rendered HTML arrives as a block of markup: a heading, a paragraph about cookies, two or three buttons. The page's content is still there underneath, and a reader that extracts text gets both. A banner injected by a script, the usual case with a consent-management vendor, may not appear in the raw HTML at all; only the loader tag does.
For the rendering agent, the banner is whatever it is in a browser. A strip along the bottom edge takes up a strip. A modal with a backdrop and a scroll lock takes up the page, and the agent's viewport is a cookie notice with nothing reachable behind it. The rubric's wording for A6 describes this: a rendered page dominated by a CAPTCHA, challenge screen or cookie wall, detected from known challenge markup and from any overlay covering more than half the viewport.
Neither kind of agent can consent. That is what makes the dialog an interstitial rather than a component: there is no action available to the agent that clears it.
What the scanner looks for
A6 reads the homepage. Where a headless render was captured it reads the rendered HTML, so a banner injected after load is seen; otherwise it reads the raw response. It then tests that document against a short list of markers; each label appears in the evidence block under markers.
| Marker label | What matches |
|---|---|
| Cloudflare challenge | cf-challenge, cf_chl_ or challenge-platform |
| CAPTCHA | g-recaptcha, the reCAPTCHA api.js loader, or hcaptcha |
| Cookie wall | id="onetrust, osano, cookieyes, cookie-consent, cookie-banner (with or without the hyphen) or cc-window |
| Interstitial page | the text Just a moment... |
| JS-required interstitial | the text Please enable JavaScript to continue or to view |
The scoring is three cases. No markers scores two points. Markers that are all "Cookie wall" score one. Any other marker scores zero, whether or not a cookie wall is also present. The recommendation attached to anything below two is the same in every case: an agent cannot dismiss a consent dialog or solve a challenge, so whatever sits behind it is unreachable, and cookieless analytics removes the need for a banner entirely.
Two honest caveats about the cookie marker. It is a string match against the document, not a measurement of the dialog, so the scanner cannot tell a two-line strip from a full-screen wall, and a page containing one of those strings in an unrelated class name or URL will trip it. The evidence lists which marker fired, so a false positive is visible rather than silent. Equally, renaming the element does not change what an agent experiences. The marker is a proxy for the dialog; the dialog is the problem.
Why it costs one point and not two
A challenge page replaces the content. A cookie dialog, in the common case, sits on top of it, and for the agent that reads HTML the content is still in the document. That is the reasoning behind the split: a cookie-only wall loses one point because it hides part of the page from some agents, and a challenge or CAPTCHA loses both because it hides all of the page from every agent.
The point is small. The reason to fix it anyway is the pattern it belongs to. A site that needs a consent dialog has a script that sets cookies or loads third parties, and that script is rarely the only one: the same page tends to carry a tag manager, a chat widget, an embedded calendar and a session-recording snippet. Each is client-side weight the plain fetch never sees and a candidate overlay in a rendered viewport. Removing the reason for the banner tends to remove the rest of the pattern with it.
Whether you need the banner at all
The banner exists because of what the site does with cookies and trackers, not because of any rule about banners as such. Whether a site must ask for consent, for what, and in what form is a legal question, and the answer varies by jurisdiction; we are not offering legal advice here. For our two markets, the Singapore PDPC and the US FTC's business guidance are the primary sources, and a site serving Europe has its own to consult.
The technical question is separate and much smaller: what are the cookies for? On many marketing sites the honest answer is analytics and nothing else. If so, the decision is whether the analytics need to identify a visitor across visits. Cookieless analytics counts page views and events without setting a cookie or storing a persistent identifier, and where that is enough, the reason for the dialog goes away, and the dialog with it.
That is the choice we made, and it is documented rather than asserted. Our privacy page states that the analytics are cookieless, that no advertising or profiling cookies are set, and that this is why no consent banner has been shown. The events we record, a scan requested, a report emailed, are posted from the server-side action that handled the form rather than from a script in the page, so the site ships no analytics JavaScript at all. Booking links out to the calendar provider rather than embedding it, for the same reason: a third-party widget is script weight and a potential overlay. None of this was done for A6 in particular. It follows from what agent readiness means taken seriously: the page an agent receives should be the page.
If you keep one
Some sites will keep a consent dialog, because the cookies it governs are ones the business needs. In that case the aim is to make it a component rather than a wall.
Keep the content in the server-rendered HTML, so the plain fetch gets the page whether or not the dialog is present; that is check A7's territory and it matters more than A6. Prefer a dialog that occupies a strip over one with a backdrop and a scroll lock, so a rendering agent has a page to read around it. Do not gate rendering of the content on the consent state: a page that is blank until a script decides the visitor has agreed is a challenge screen by another name. And do not let the consent script become a dependency for anything else on the page; a tag manager that loads the navigation after consent is an A7 finding waiting to happen.
Finally, do not try to hide the dialog from crawlers specifically. Serving different markup to a bot user agent makes a site harder to trust in every other check, and it does nothing for user-triggered fetches, which carry a person's request and arrive with a browser-like identity.
Check your own site
Fetch your homepage and search the response for the strings in the table above, then load it in a browser and look at what covers the viewport. The free scan records the markers it found under A6, alongside the raw and rendered text lengths under A7. The definition of the check is on the methodology page under discovery and access, and our own result is on our live report.