When a company installs a cookie banner on its website, the verification test usually lasts ten seconds. Someone opens the homepage in an incognito window, sees the consent popup appear at the bottom of the screen, clicks “Accept” or “Reject,” watches the box disappear, and marks the task complete.
Even many commercial compliance scanners do little more than fetch the page HTML once and list the cookie names found on initial load. That single-load check misses the exact violations that trigger data protection complaints and ad-platform disruptions.
To know what a website actually does with visitor data, you have to test three separate browser states in sequence: what happens during the first eight seconds when the visitor has not clicked anything (Untouched), what happens after the visitor clicks Reject All, and what happens after the visitor clicks Accept All. Testing all three states in an isolated headless browser exposes trackers that fire before consent, reject buttons that only hide the UI while scripts keep running, and broken tag configurations that block conversions even after a user agrees.
Executive Summary
- Why Single-Load Scans Fail: Checking a webpage only once cannot distinguish between a tracker that fires illegally before consent and one that waits properly for user interaction.
- The Three Mandatory Audit States: Every technical privacy audit must inspect network requests, cookies,
localStorage, andsessionStorageacrossState 1: Untouched (Pre-Consent),State 2: Reject All, andState 3: Accept All. - The Cosmetic Reject Trap: Roughly 30% of custom or misconfigured Google Tag Manager setups hide the cookie banner when a user clicks “Reject” while still sending pageview beacons or storing advertising identifiers in
localStorage. - Revenue Protection in State 3: Auditing the
Accept Allstate is equally important for marketing teams, as overly aggressive script blocking often breaks conversion tracking for users who genuinely consented.
Why a Single Page Load Cannot Prove Cookie Compliance
A single page load only captures a static snapshot of initial network traffic, leaving you blind to delayed script timers, broken reject handlers, and state persistence across page navigation.
In our foundational guide on how a technical GDPR website audit works, we explained why reading a written privacy policy never tells you what third-party scripts execute in the user’s browser. When auditing the consent mechanism itself, timing and interaction state determine whether the site is compliant:
- Delayed Pre-Consent Triggers (
setTimeoutand Scroll Listeners): Some tag managers delay firing Meta Pixel, LinkedIn Insight Tag, or Hotjar by three seconds or until the user scrolls 200 pixels, assuming the user will click “Accept” immediately. A scanner that closes the page after one second reports zero trackers, whereas a real visitor who reads the headline before touching the banner gets tracked without consent. - UI Dismissal Without Consent Revocation: Clicking “Reject All” must do more than set
display: noneon the banner modal. It must keep Google Consent Mode v2 flags set todeniedand prevent non-essential tags from firing on subsequent page views. - Storage Outside Standard HTTP Cookies: Modern tracking scripts frequently store visitor UUIDs and session fingerprints inside
window.localStorage,sessionStorage, or IndexedDB when cookies are blocked. Inspectingdocument.cookiealone misses these identifiers completely.
Inside the Three-State Playwright Inspection Protocol
An automated Playwright audit launches clean browser contexts to record every outbound HTTP request, cookie write, and storage key across all three user interaction states.
Instead of relying on manual DevTools checks that nobody repeats after a marketing update, we run a scripted browser inspection protocol that tests each state deterministically:
State 1: The Untouched State (Pre-Consent Baseline)
The script opens the target URL in a brand-new Chromium context with an EU IP address, waits eight full seconds, and scrolls halfway down the page without clicking the cookie banner.
- What must happen: Only strictly necessary first-party requests (HTML, CSS, self-hosted fonts, essential session or security cookies) may execute.
- What commonly fails: Google Analytics 4 (
/g/collect), Meta Pixel (connect.facebook.net), Google Fonts (fonts.googleapis.com), embedded YouTube iframes (youtube.com), or live chat widgets load immediately before the visitor interacts with the banner.
State 2: The Reject State (Refusal & Navigation Persistence)
Next, the script locates the refusal action on the banner (“Reject All”, “Decline”, “Only Necessary”, or “Alle ablehnen”), clicks it, waits five seconds, and then clicks an internal link to a second page on the same site.
- What must happen: A functional consent preference cookie or
localStorageentry records the refusal, the banner stays closed on the second page, and zero analytics or marketing requests fire on either page. - What commonly fails: We regularly find websites where
State 1is clean, yet clicking “Reject All” fires a generic GTM click trigger (gtm.click) that accidentally launches marketing tags because the tag firing rule was bound to “Any Banner Button Click” rather than checking the granted consent category. In other cases, navigating to a second page re-triggers tracking because the refusal state was not saved properly.
State 3: The Accept State (Disclosure Parity & Conversion Health)
Finally, the script starts a fresh browser session, clicks “Accept All”, and records every third-party domain, cookie expiration, and storage key that activates.
- What must happen: Expected analytics and marketing tags fire cleanly, Consent Mode v2 updates to
granted, and every active third-party domain matches the vendors listed in the site’s cookie banner and written privacy policy. - What commonly fails: Either legacy tags fire for tools the company stopped using two years ago (creating a runtime mismatch with the written privacy policy), or poorly implemented developer fixes block GA4 and Google Ads from recording conversions even after the user clicks “Accept.”
The 4 Most Common Consent State Failures Found in Production
Comparing network logs across the three states immediately pinpoints whether a violation comes from hardcoded HTML scripts, misconfigured GTM triggers, or dark-pattern banner design.
| Failure Pattern | State 1 (Untouched) | State 2 (Reject All) | State 3 (Accept All) | Root Cause in Code |
|---|---|---|---|---|
| 1. Compliant Implementation | 0 tracking requests; 0 non-essential cookies | 0 tracking requests; 1 refusal preference cookie | Disclosed analytics & ad tags fire cleanly | Scripts wrapped in consent callbacks; GTM triggers gated by consent state. |
| 2. Pre-Consent Firing (Most Common) | GA4, Meta Pixel, or YouTube fire immediately | Trackers already loaded in memory keep running | Trackers continue running | Tracking snippets pasted directly in <head> outside the CMP or GTM consent wrapper. |
| 3. Cosmetic Reject Button | 0 tracking requests on initial load | Analytics or session recording fires after clicking Reject | All tags fire | GTM trigger fires on banner button click event without filtering consent_status === 'granted'. |
| 4. Second-Page Amnesia | 0 tracking requests on homepage | 0 on homepage, but trackers fire on page 2 after navigation | All tags fire | Refusal cookie scoped to wrong path/domain or overwritten by a secondary script on navigation. |
| 5. Over-Blocked Broken Analytics | 0 tracking requests | 0 tracking requests | 0 analytics requests (marketing blind spot) | Developer deleted or broke the consent update callback when trying to fix a previous GDPR warning. |
Visual Banner Checks vs Single-Load Scanners vs Three-State Runtime Audit
Checking whether a cookie banner exists on screen tells you nothing about compliance; only comparing browser network behavior across all three consent states proves your setup works.
Basic Cookie Scanner
Single SnapshotLoads the URL once without interacting with the banner or testing navigation persistence.
- Cannot test whether Reject All actually works
- Misses scroll-triggered and delayed scripts
- Ignores localStorage and sessionStorage identifiers
3-State Playwright Audit
Full InteractionExecutes Untouched, Reject, and Accept flows in isolated browsers with full network & storage diffs.
- Proves zero pre-consent and post-reject tracking
- Verifies multi-page refusal persistence
- Confirms accepted analytics fire without data loss
Frequently Asked Questions (FAQ)
If we use a certified CMP like Cookiebot, Usercentrics, or OneTrust, can our Reject state still fail?
Yes. A Consent Management Platform (CMP) only displays the banner and broadcasts the user’s choice. If a developer or marketing agency previously pasted a LinkedIn pixel, Hotjar script, Calendly embed, or Google Font link directly into the website’s <head> or CMS template without binding it to the CMP’s blocking attributes, that script will fire in both the Untouched and Reject states regardless of which CMP you pay for.
How does Google Consent Mode v2 behave in the Untouched and Reject states?
In basic Google Consent Mode, zero requests should be sent to Google servers until the user grants consent. In advanced Google Consent Mode, cookieless pings (gcs=G100) may be transmitted without writing cookies, provided your legal basis and privacy notice explicitly cover cookieless modeling. In most strict European interpretations (including Germany and Poland), blocking all outbound analytics network pings until explicit opt-in remains the safest technical configuration.
How often should a website run a three-state consent audit?
Run an automated three-state check whenever marketing publishes new Google Tag Manager changes, embeds a third-party video or booking widget, or updates the site template. Even a single newly embedded YouTube player or HubSpot form on a landing page can introduce pre-consent tracking cookies on an otherwise clean website.
Test What Your Website Actually Does in All Three States
Do not guess whether your cookie banner actually blocks trackers before consent or after a visitor clicks “Reject.” Send us your website URL. We will run a three-state browser audit across your live pages and hand you a clear engineering report showing every network request, cookie, and storage item in the Untouched, Reject, and Accept states.
Explore our technical web engineering and compliance services or request a technical website audit today.
