Cookie consent GDPR testing: the assertion lives in the network log, not the banner

Almost every cookie consent test I've seen checks the wrong thing. It confirms the banner appears, that clicking "Accept" makes it disappear, and maybe that a preferences link exists. All of that can pass while the one behavior regulators actually care about is broken: your analytics and ad scripts firing the moment the page loads, before the visitor has clicked anything. The banner is theatre in front of the real question, and the real question isn't answered in the DOM. It's answered in the network log — which requests left the browser, and when.

That reframing is the whole post. Cookie consent GDPR testing is not UI testing; it's a network-and-storage assertion wearing a UI. And it happens to be a near-perfect fit for a browser agent that can watch every request a page fires, because the failure you're hunting is invisible on screen and obvious in the traffic.

What the rule actually requires (so we test the right thing)

Let's ground this in a primary source rather than a vendor's compliance-checklist blog. The UK regulator, the ICO, states the standard plainly in its guidance on cookies and similar technologies: "you cannot set non-essential cookies on your website's homepage before the user has consented to them." Consent itself, the ICO says, "must be freely given, specific and informed. It must involve some form of unambiguous positive action — for example, ticking a box or clicking a link," and — the line that kills the pre-ticked-box pattern — "this must be more than simply continuing to use the website."

There's a carve-out, and testing it correctly means respecting it: cookies "strictly necessary to provide an information society service" the user requested are exempt — the ICO's examples are a shopping basket, session-security cookies for online banking, and load-balancing. But the ICO is explicit that the bar is high: "cookies that are helpful or convenient but not essential, or that are only essential for your own purposes, will still require consent." So your session ID and CSRF token get a pass; your Google Analytics, your ad pixel, and your "helpful" heatmap tool do not.

One honest caveat before any prompt runs, because it matters and because the backlog that seeded this post insisted on it: you're testing the mechanism, not adjudicating legal compliance. Whether your specific setup satisfies GDPR, PECR, or an EU member state's ePrivacy transposition is a question for your DPO and counsel, and the ICO notes it's currently consulting on revised guidance. What a test can prove is concrete and valuable on its own: did a non-essential request fire before consent, did "reject" actually stop it, did the choice persist. Those are the mechanical facts underneath the legal question, and they're where the regressions hide.

Why a browser agent is the right tool here

The reason this maps so cleanly onto an agent is that the evidence is traffic, and a Monito Session records the network log for a run — every request with its method, URL, and status. So the agent doesn't need to guess whether tracking is active from what's on screen; it can look at whether a request to a known tracker actually left the browser, which is the ground truth. This is the same "read the network, not the pixels" move behind testing a webhook receiver by its consequences and checking cross-tenant access by what the server returns — the interesting assertion is in the request/response, and the agent is watching it.

Being precise about the capability and its limit keeps this honest. The agent's strong, verifiable signal is the requests that fire: a GET to google-analytics.com, googletagmanager.com, doubleclick.net, or connect.facebook.net before consent is a real, observable failure in the network log. Reading the raw cookie jar or localStorage byte-for-byte is a different, weaker surface — if you need to assert on the exact cookie names written to storage, keep a small dedicated check for that, the same way we tell people to keep a unit test for cell-level CSV encoding while the agent owns the far more common wrong-query bug. But in practice the tracker's request is both easier to observe and the more meaningful violation: a pixel that fired has already phoned home, whether or not a cookie stuck. Test the traffic; that's where the leak is.

One piece of test hygiene first

Cookie-consent tests are uniquely easy to fool yourself with, because the browser remembers. If you tested this yesterday and clicked "accept," today's page already has your consent stored and won't fire the banner or suppress anything — so a run in that state proves nothing about a first-time visitor. Every test below assumes a genuinely fresh state: a clean session with no prior consent, the way a real first visit arrives. The ICO's own model reinforces why the first-visit case is the one that matters — it notes that once you've told people about cookies and taken consent, "you do not have to repeat it every time the same person visits," which means the pre-consent behavior only ever happens on that first, unprimed load. Test the unprimed load, or you're testing a decision you already made.

The five things worth testing

1. Nothing non-essential fires before a choice. Load the page fresh, in a clean session, and do nothing — don't click the banner. Then read the network log. Requests to your own origin for the page, its assets, and session/security endpoints are expected. A request to any analytics or advertising domain at this point is the headline bug. This is the check that catches the most common and most serious failure: a tag manager that loads and fires on page load regardless of the banner sitting on top of it.

2. "Reject all" is honored — and is as easy as "Accept." Click reject, then keep using the site for a bit, then read the log again. No non-essential requests should appear after rejection. Two things to assert here: the mechanical one (trackers stay silent) and the structural one the ICO ties to valid consent — that the reject control exists and is a real, reachable option, not buried a menu deep while "Accept all" is a giant button. The ICO frames freely-given consent as users having "the means to enable or disable non-essential cookies" and making "this easy to do."

3. Accept actually turns things on. The mirror of the reject test. After clicking accept, the previously-suppressed requests should now fire. This matters because the failure mode isn't only "fires too early" — a banner that blocks tracking even after consent is a different bug (your marketing team's, but a bug), and a test that only ever checks the reject path won't see it.

4. The choice persists. Reload the page after making a choice; navigate to another page; come back. The banner should not re-prompt on every view, and the earlier decision should still be in force — trackers still silent after a reject, still active after an accept. Persistence is state, and state that resets is both an annoyance and a consent bug. (If you've read our walkthrough of URL-and-reload state persistence, this is the same discipline applied to a consent choice instead of a filter.)

5. Withdrawal works. The ICO's model of freely-given consent includes being able to change your mind. Open the preferences UI, switch from accept to reject, and confirm the network log goes quiet afterward — withdrawal that updates the banner text but keeps the pixels firing is the quietest failure of the set, because nothing on screen looks wrong.

This is the one to run first, because it catches the failure that actually draws enforcement, and it needs no special setup. Point a Test Scenario at a staging or production URL — production is fine here, you're only loading pages — and paste this:

Test cookie consent on https://www.yourapp.com as a first-time visitor.

1. Load the homepage in a clean session. Do NOT interact with the
   cookie banner at all. Wait a few seconds.
2. From the network log, list every request whose domain is a known
   analytics or advertising tracker — for example google-analytics.com,
   googletagmanager.com, doubleclick.net, connect.facebook.net,
   or any third-party analytics/ads domain. Any such request at this
   point is a FAIL: report it with the exact URL.
3. Now click "Reject all" (or the reject/decline option) on the banner.
   Browse to one more page and wait. Read the network log again. Any new
   non-essential tracker request after rejecting is a FAIL — report the
   URL and the page it fired on.
4. Confirm the banner offered a reject option with roughly equal
   prominence to accept, and note if reject was hidden or harder to
   reach than accept.

Report a clear pass/fail for steps 2 and 3 with the offending requests
listed, plus any console errors.

The agent reads the rendered page like a first-time visitor and, crucially, reads the network log the way you'd read it in DevTools — except it does it every run, on a schedule or in CI against every deploy, instead of the one time someone remembered to check by hand. You can describe this without writing any code, and the whole run comes back as a Session with the request list as evidence. Your first run is free: every account starts with 50 credits, and one test run is one credit. After that, Monito Pro is $79/mo (Team $199/mo). Run it against your own homepage right now — the honest answer to "does anything fire before consent?" is one run away, and it's the answer that matters more than whether the banner looks nice.