Cookies Still Tracking After "Reject All"? Here's How to Catch It

Click "Reject All" on a cookie banner and you'd expect the tracking to stop. It usually doesn't. A 2024 study from the University of Amsterdam found that a majority of tested websites kept collecting data after users explicitly refused consent — and independent measurements put the share of sites that ignore rejection at roughly two-thirds. If your store is one of them, the banner isn't protecting you. It's documenting your violation.

This is the gap regulators now fine for directly. And it's the single most common reason a site that "has a cookie banner" is still breaking the law. Below is why cookies still tracking after reject all happens, and a 10-minute test to prove whether it's happening on your own site.

Why "Reject All" so often does nothing

A consent banner is just a UI layer. Whether tracking actually stops depends on what your tags, your tag manager, and your third parties do after the click — and that wiring breaks in predictable ways.

The most common failure isn't tags firing before consent — it's tags firing after rejection. Research measuring third-party requests found that, on the median site, roughly the same number of third parties ran whether a user rejected everything or did nothing at all. The "Reject All" button changed the UI, not the network traffic.

The usual culprits:

• Hardcoded tags — an analytics or pixel snippet pasted directly into the theme, bypassing the consent platform entirely.
• Miscategorized scripts — a marketing tag flagged as "strictly necessary," so it loads regardless of choice.
• Broken Consent Mode signals — the banner records the rejection, but the signal never reaches Google Tag Manager triggers, so tags fire anyway (see our breakdown of Google Consent Mode v2 missteps).
• Third parties that ignore the signal — a vendor script that simply doesn't honor the consent state it's handed.

Note one thing that is not a violation: strictly necessary cookies (session, cart, security) are allowed to persist under the ePrivacy Directive Art. 5(3) exemption. The problem is non-essential, tracking, and advertising cookies surviving a refusal.

The banner says "rejected"; the network tab tells the truth.

Regulators are now fining for exactly this

"Cookies placed despite an explicit refusal" is no longer a theoretical risk — it's a line item in penalty decisions.

In September 2025, France's CNIL issued €475M in cookie fines in a single day: €325M against Google and €150M against Shein. In the Shein decision, the CNIL stated that when a user clicked "Refuse all" or withdrew consent, "new cookies were still placed and others, already present, continued to be read." That is the post-rejection bypass, described in a regulator's own words.

This sits at the intersection of two laws: the ePrivacy Directive (Art. 5(3)), which requires prior consent before storing non-essential cookies, and GDPR Art. 6, which requires a valid legal basis for the processing that follows. A rejection that doesn't stop tracking fails both.

For an EU e-shop, the exposure isn't only the fine. It's that every visitor who rejected and was tracked anyway is a documented unlawful-processing event — at scale, across your whole catalogue of traffic.

The €475M wasn't for missing a banner; it was for a banner that didn't do what it claimed.

The 10-minute test: catch the bypass yourself

You don't need a lawyer to find out — you need an incognito window and the Network tab. Here's the manual version anyone on your team can run today.

1. Open a fresh incognito/private window (no prior cookies or consent state).
2. Load your site and open DevTools (F12) → Network tab. Reload once so it captures from the first request.
3. Before touching the banner, check Application → Cookies and Network for requests to google-analytics.com, googletagmanager.com, connect.facebook.net, doubleclick.net, or any ad/analytics domain. Anything firing here = tracking before consent.
4. Click "Reject All" (or the most restrictive option the banner offers).
5. Filter the Network tab for gtag, collect, pixel, facebook, doubleclick, analytics. Any new request to those after the rejection is a consent bypass.
6. Re-check Application → Cookies. Look for new _ga, _fbp, _gcl_* or similar identifiers written after you refused.

What you're looking for in plain terms: did anything network-facing change when you clicked reject? If the same trackers keep talking to the same domains, the button is cosmetic.

One caveat: not all tracking uses cookies. Fingerprinting reads your device characteristics (screen, fonts, GPU) without storing anything, and the browser's Same-Origin Policy stops a consent tool from deleting third-party cookies already set. So a clean cookie list isn't proof of compliance — the network requests are the harder evidence.

Ten minutes of DevTools beats a year of assuming your CMP "handles it."

Why your CMP's dashboard won't catch this

A consent platform validates its own configuration — not your actual site. When a CMP vendor's dashboard shows green, it's confirming that the setup passes the platform's internal checks. Those checks can't see a pixel hardcoded in your theme, a GTM trigger that ignores the consent signal, or a third-party script that simply disregards what it's told.

This is the structural blind spot of buying compliance verification from the same vendor that sells you the banner. The CMP is the thing being tested; it can't be the independent test. A 2025 analysis found that even among banners with a working reject button, dark-pattern design and miscategorization remained common — issues a vendor's own "you're compliant" badge won't flag.

This is also why a one-time check isn't enough. You add a new marketing tag, a developer pastes a snippet, a vendor updates their script — and the bypass reappears silently. Continuous, automated monitoring independent of your CMP is the only way to know your reject button still works next month.

The tool that sells you the banner is the worst-placed party to certify it works.

Turn the test into evidence

Finding the bypass is step one; proving you fixed it — with a date attached — is what protects you. If a DPA opens an inquiry, "we believe we're compliant" carries no weight. A timestamped record of what loaded, before and after rejection, does.

That's the gap CookieSentry fills. It scans any URL the way a regulator would — simulating a real rejection and recording every cookie and third-party request that fires anyway — then produces a timestamped audit PDF you can keep as evidence under GDPR Art. 6 and the ePrivacy Directive. It's not a banner. It's the independent verifier that checks whether the banner you already have actually honors a refusal.

If you want the manual route first, our complete cookie compliance audit guide walks through the full sweep. Either way, the principle is the same: test the rejection, not the configuration.

Compliance you can't show on a dated report isn't compliance a regulator will accept.

Frequently asked questions

Why do cookies still appear after I click "Reject All"?

Some are legitimately exempt — strictly necessary cookies for sessions, carts, and security can persist under ePrivacy Art. 5(3). The rest usually mean a tag bypassed your consent layer: a hardcoded snippet, a miscategorized "necessary" script, or a Consent Mode signal that never reached your tag manager. Non-essential trackers surviving a refusal are a violation, not an exemption.

Is it actually illegal to track users after they reject cookies?

Yes. The ePrivacy Directive (Art. 5(3)) requires prior consent before storing non-essential cookies, and GDPR Art. 6 requires a legal basis for the processing. Tracking after a refusal fails both. The CNIL's September 2025 fines against Google (€325M) and Shein (€150M) cited cookies placed despite explicit refusal.

How can I test whether my own site honors "Reject All"?

Open an incognito window, load your site, open DevTools → Network, click "Reject All," then watch for new requests to analytics/ad domains (gtag, doubleclick, facebook) and new tracking cookies (_ga, _fbp) written after the click. Anything new after rejection is a bypass.

Doesn't my cookie banner / CMP already handle this?

A CMP validates its own configuration, not your live site. It can't see hardcoded pixels, broken GTM triggers, or third-party scripts that ignore the consent signal. That's why the vendor selling the banner is the wrong party to certify it works — you need an independent scan.

What's the difference between cookies firing before consent and after rejection?

Both are violations. "Before consent" means trackers load on page entry before the visitor chooses. "After rejection" means they keep loading despite a clear refusal — often the more damaging finding, because it proves the consent mechanism is decorative. Test for both.

How often should I re-check?

Every time you add or change a marketing tag, and on a regular schedule otherwise. New tags, theme edits, and vendor script updates can silently reintroduce a bypass. Continuous automated monitoring catches regressions a one-time audit misses.