Testing Your Cookie Banner: How to Verify That Rejected Cookies Are Actually Blocked

Why Clicking Reject Is Not Enough

The CNIL fined SHEIN EUR 150 million in September 2025 after inspectors found that the "Reject all" button on SHEIN's website did not actually prevent advertising cookies from being placed. The cookies loaded regardless of the visitor's choice. This is not an isolated case - enforcement data from across Europe shows that broken cookie blocking is one of the most common compliance failures regulators uncover.

Your cookie banner might look correct. It might display the right categories, offer a clear reject option, and log consent properly. But none of that matters if the underlying script-blocking mechanism fails to stop non-essential cookies from firing when a visitor says no.

Verifying that rejected cookies are genuinely blocked requires hands-on testing. The good news: the tools you need are already built into your browser.

Setting Up Your Testing Environment

Before running any tests, you need a clean browser state. Open an incognito or private browsing window - this ensures no existing cookies or cached consent decisions interfere with your results. If you use Chrome, press Ctrl+Shift+N (or Cmd+Shift+N on macOS) to open a fresh session.

Open DevTools by pressing F12 or Ctrl+Shift+I. Navigate to the Application tab and expand the Cookies section in the left sidebar. You should see your domain listed. Before interacting with the banner, note which cookies are already present - these are the cookies that load before any consent decision.

Under Article 5(3) of the ePrivacy Directive, only strictly necessary cookies may be set without consent. If you spot cookies like _ga, _fbp, or _gcl_au at this stage, your site has a problem before the visitor even interacts with the banner.

The Three Scenarios to Test

Every cookie banner test should cover three distinct scenarios:

1. No interaction - load the page without touching the banner. Only strictly necessary cookies should be present.
2. Full rejection - click "Reject all" or equivalent. No analytics, marketing, or preference cookies should remain or appear on subsequent page loads.
3. Selective consent - accept some cookie categories and reject others. Only the accepted categories should set cookies.

Using the Network Tab to Catch Rogue Requests

The Application tab shows cookies already stored, but the Network tab reveals what is happening in real time. Switch to it and reload the page after rejecting all cookies. Watch for outgoing requests to known tracking domains.

Filter the network log by typing domain fragments into the filter bar. Common ones to check:

If requests to these domains appear after you rejected cookies, the scripts are firing without consent. This is exactly the pattern that CNIL and other data protection authorities flag during inspections.

Checking Set-Cookie Response Headers

Click on any network request and select the Headers tab. Look for Set-Cookie in the response headers. Even if your client-side blocking works, a server-side response might still attempt to set tracking cookies. For each Set-Cookie header, check whether the cookie name belongs to a category the visitor rejected.

Auditing Cookies After Page Navigation

A single page load is not enough. Many tracking scripts fire on route changes in single-page applications, or load dynamically as a visitor scrolls. After rejecting cookies on the initial page, navigate to two or three other pages on your site, then return to the Application tab and review the cookie list again.

Pay attention to cookies that appear after navigation. Third-party scripts embedded in specific page templates - such as a Meta Pixel on a checkout page or a YouTube embed on a blog post - might bypass the banner's blocking logic if they are hardcoded into the template rather than loaded through a tag manager.

This is where conditional script loading becomes critical. Scripts should only execute after a consent management platform confirms the visitor has opted in to the relevant category.

Automated Testing Approaches

Manual DevTools checks are thorough but do not scale. If you manage multiple websites or deploy frequent updates, automated testing catches regressions before they reach production.

Headless Browser Scripts

Tools like Puppeteer and Playwright can simulate a visitor rejecting cookies and then inspect the resulting page state. A basic test script would:

1. Launch a headless browser and navigate to your homepage.
2. Wait for the cookie banner to appear.
3. Click the reject button.
4. Collect all cookies from the browser context.
5. Fail the test if any non-essential cookies are present.

This test can run in your CI/CD pipeline after every deployment. A failed test blocks the release until someone investigates the cookie leak.

Network Request Assertions

Beyond checking stored cookies, your automated tests should monitor outgoing network requests. Playwright's page.on('request') event lets you capture every request the page makes. Build an allowlist of domains that may receive requests without consent (your own domain, your CDN, font providers) and flag anything else.

This approach catches a gap that cookie-only checks miss: some tracking services send data via server-side requests or pixel images without setting a client-side cookie.

Common Failures and How to Fix Them

Certain patterns cause cookie blocking to fail repeatedly across different sites. Knowing these helps you diagnose problems faster.

Race Conditions on Page Load

If your consent management script and your analytics script both load asynchronously, the analytics tag might execute before the CMP has had time to check the visitor's consent state. The result: cookies set before the banner even appears. Fix this by ensuring your CMP loads synchronously in the <head> and blocks other scripts until consent is resolved.

Hardcoded Scripts Bypassing the Tag Manager

A properly configured tag manager can gate scripts behind consent triggers. But scripts pasted directly into theme templates, plugin files, or CMS content blocks bypass this gating entirely. Run a cookie audit to identify every script source, not just those managed through GTM.

Consent State Not Persisting Across Subdomains

If your consent cookie is set for www.example.com but your checkout lives on shop.example.com, the subdomain may not receive the rejection signal. Set your consent cookie's domain attribute to .example.com (with the leading dot) so it applies across all subdomains.

Third-Party Iframes Loading Independently

Embedded iframes from third parties - maps, video players, social widgets - often set their own cookies regardless of your banner. The iframe loads in its own browsing context and does not read your consent cookie. Replace these with placeholder elements that only load the iframe after consent, or use privacy-enhanced alternatives where available.

Building a Repeatable Testing Checklist

Document your testing process so it can be repeated after every site update. A practical checklist covers the following:

• Test in an incognito window with cache and cookies cleared.
• Verify no non-essential cookies exist before banner interaction.
• Reject all cookies and confirm only strictly necessary cookies remain.
• Check the Network tab for requests to tracking domains after rejection.
• Navigate to at least three different page types (homepage, blog post, product page) and recheck.
• Repeat on mobile viewport sizes - some banners render different code paths on smaller screens.
• Test in at least two browsers (Chrome and Firefox) since cookie handling differs.
• Record which cookies and domains were found in each scenario.

Keep records of each test. If a data protection authority investigates your cookie practices, documented testing evidence demonstrates that you actively monitor compliance rather than relying on a set-and-forget banner.

What Regulators Actually Check

Enforcement actions from CNIL, the ICO, and other DPAs reveal a consistent inspection method. Regulators visit the website, reject cookies, and then examine the browser's cookie storage and network traffic - the same technique described above. The CNIL's 2025 enforcement wave, which resulted in fines totalling over EUR 486 million, repeatedly cited non-functional reject buttons and cookies loading before consent as primary violations.

The GDPR requires that consent be freely given, specific, informed, and unambiguous under Article 7. A reject button that does not actually reject anything fails the most basic test of valid consent architecture.

Frequently Asked Questions

Take Control of Your Cookie Compliance

If you are not sure which cookies your site sets, start with a free scan. Kukie.io detects, categorises, and helps you manage every cookie - so your visitors get a clear choice, and you stay on the right side of the law.

Start Free - Scan Your Website