Why 'Reject all' is often decorative: how to test consent gating yourself in 10 minutes

Correction 2026-09-27: an earlier version of this piece said TagPatrol's full audit loads every page in all three consent states. It loads the start page in all three states and walks the further pages only under a live reject-all and accept-all.

Correction 2026-09-14: the Healthline quote in the second paragraph now matches the source verbatim ("appeared to allow users to disable advertising cookies but did not effectively do so"), and the ICO figure has been replaced with the confirmed January 2025 numbers (200 sites reviewed, 134 contacted) after this run could not verify the previously cited December 2025 figures (1,000 tested / 564 corrected / 17 notices) against a fetchable source.

A cookie banner does two jobs. The first is to record a choice. The second is to enforce it: to stop the analytics tag, the ad pixel and the session-replay script from loading until someone has said yes. Most consent management platforms (CMPs) do the first job well. The second job is where sites fail, and they fail more often than anyone running the site expects.

The numbers are not subtle. In June 2026 Privado scanned the top 250 websites by traffic in France, the UK and California and found that 44% of the French set and 47% of the UK set kept tracking after "reject all" was clicked. Across all tests, 90% of sites failed at least one privacy check, and these are sites with budgets for enterprise CMPs. Regulators are testing the same thing. The CNIL's €150 million SHEIN decision listed, among other findings, that cookies were still placed after users clicked "Refuse all". Its €1.5 million American Express decision found advertising cookies placed despite refusal and cookies still read after consent was withdrawn. In California, Healthline paid $1.55 million partly because its cookie banner "appeared to allow users to disable advertising cookies but did not effectively do so".

None of those findings needed special tooling. Each is visible in a browser's developer tools within minutes. This article shows you how to look; it mirrors what TagPatrol automates, so run the manual version first if you want to judge whether the automated one is worth your time.

Why the button ends up decorative

The failure modes cluster into five patterns.

1. Tags fire before the banner exists. Google Tag Manager (GTM) or a hard-coded script loads on page render. The CMP loads a few hundred milliseconds later. By the time the banner is painted, the analytics hit and the ad pixel have already been sent. GTM ships a dedicated "Consent Initialization – All Pages" trigger that is guaranteed to fire before every other trigger, precisely so consent defaults can be set first. Many containers never use it.

2. Tags are not gated at all. GTM tags fire on "All Pages" with no consent requirement. The CMP dutifully writes the user's choice to a cookie and nothing reads it. GTM's Consent Overview screen lists such tags under "Consent Not Configured"; on an unaudited container that list is usually long.

3. Wrong category mapping. The CMP's auto-blocker is on, but the analytics script has been classified as "strictly necessary" or the ad pixel as "functional". As one OneTrust validation guide puts it, "analytics scripts end up in the 'Strictly Necessary' category" and "marketing pixels get bundled with functional cookies". Reject all then blocks the categories nobody cares about.

4. Tags outside the tag manager. A developer pasted the Meta pixel, Hotjar or a chat widget straight into the template. The CMP only controls what runs through GTM or what its script-blocker recognises. Everything else runs regardless.

5. Rejection is not persisted or not honoured on the next page. The first page respects the choice; the second page, loaded from a different template or a subdomain, loads a fresh GTM container and fires everything. Privado's finding that 19% of European sites fail to update Google Consent Mode after "reject all" is often this pattern: the CMP updated its own state, but never sent the update to Google's tags.

Notice that none of these is a legal question. They are engineering defects, and you find them by observing the browser.

The 10-minute test

You need Chrome, Firefox or Edge, a page you can open in a fresh profile, and a notepad. Do the whole thing in an incognito or guest window so no earlier consent choice interferes. Disable ad-blockers and privacy extensions for the test; they hide exactly the requests you are trying to see.

Minute 0–2: set up the network tab before the page loads

1. Open a new incognito window. Press F12 (or Cmd-Option-I on a Mac) to open DevTools before typing the URL.
2. Go to the Network tab. Tick Preserve log and Disable cache. Preserve log matters: without it, a redirect or a reload wipes the evidence.
3. In the filter box, type a domain fragment you want to watch. Good first filters: google-analytics, googletagmanager, doubleclick, facebook, connect.facebook.net, hotjar, clarity.ms, linkedin, tiktok, bing. You will clear and change this filter several times.
4. Now type the URL and press Enter.

Minute 2–4: read the pre-consent state

Do not touch the banner. Look at what has already happened.

• Filter on collect or g/collect. Any request to google-analytics.com/g/collect or analytics.google.com/g/collect is a GA4 hit. If you see one before you have clicked anything, analytics is firing pre-consent. Click the request and open the Payload tab. Look for a gcs parameter: G100 means no consent was granted for either ads or analytics; G111 means both were granted. A hit with G111 before you clicked is a misconfigured default, as Simo Ahava's decoding guide explains.
• Filter on facebook or tr?. A request to facebook.com/tr?id=...&ev=PageView is the Meta pixel firing.
• Filter on doubleclick and googleads. Requests to googleads.g.doubleclick.net/pagead/viewthroughconversion or td.doubleclick.net are Google Ads tags.
• Switch to the Application tab (Chrome) or Storage (Firefox). Expand Cookies and select your domain. Note every cookie present. _ga, _gid, _fbp, _gcl_au, _hjSession*, _clck, _uetsid are all non-essential and should not exist yet on a site that gates properly.

Write down what you saw. This is your "no interaction" baseline, and under the ePrivacy rules in the EU and UK, it is the state that must be clean.

Minute 4–6: click "Reject all" and watch

Clear the network log (the 🚫 icon) so what follows is unambiguous. Click Reject all (or whatever the site calls it). Then:

• Watch the network tab for ten seconds. Anything that appears now is firing in response to rejection. That is the worst version of the bug and it happens: CMP callbacks that trigger a "consent updated" dataLayer event, which triggers tags with no consent check.
• Reload the page with the log still preserved. Repeat the filters from minute 2. On a correctly gated site you should see the GTM container load, the CMP load, possibly cookieless Google pings with gcs=G100, and nothing else from the marketing domains.
• Go back to Application → Cookies. Cookies that were set pre-consent should now be gone or, at minimum, no new marketing cookies should appear after reload. The CNIL's American Express finding that previously placed cookies continued to be read after consent withdrawal is a reminder that "not setting new ones" is not the full bar.

Minute 6–8: navigate to a second and third page

Click into a product page, an article and, if there is one, a checkout or form page. Different templates, different embedded widgets, different developers. The consent state should follow you. Look for:

• A fresh burst of marketing requests on a page that has a different GTM container ID (check gtm.js?id=GTM-XXXX in the network log; if the ID changes between pages, you have two containers and probably two consent configurations).
• Third-party iframes (YouTube embeds, maps, chat widgets, payment widgets) that carry their own trackers. Filter on youtube, intercom, drift, hubspot.
• Subdomains. Consent cookies scoped to www.example.com are invisible to shop.example.com. Rejection made on one is not known on the other.

Minute 8–10: check the accept path and compare

Clear cookies (Application → Storage → Clear site data), reload, and this time click Accept all. You should now see everything: the full parade of pixels and cookies. This confirms the tags exist and that your reject-path test was meaningful. If the accept path and the reject path look the same, the button is decorative.

Compare the two lists. The difference between them is what your consent banner actually controls. Anything present in both is ungated.

Reading the results

Three outcomes are common.

Clean. Pre-consent shows only the CMP, GTM's container load, first-party essentials and, if Consent Mode is on, Google pings carrying denied signals. Reject all changes nothing because there was nothing to change. Accept all lights everything up. This is what regulators expect and it is rarer than it should be.

Leaky on load. Reject all is honoured, but two or three tags fired before the banner appeared. Typical culprits: a hard-coded pixel in the template, a GTM tag on "All Pages" without a consent check, or GTM loading before the CMP. The fix is ordering and gating: move consent defaults into the Consent Initialization trigger, set every tag's "additional consent checks", and pull hard-coded scripts into the tag manager where the CMP can see them.

Decorative. The reject path and accept path are indistinguishable. Usually one of two causes: the CMP's script blocker or GTM consent integration was never enabled, or category mappings are wrong. This is the pattern in the enforcement decisions, and it is the pattern automated scanners find on a large share of sites.

Whatever you find, keep the evidence: export the network log (right-click → Save all as HAR with content) for each state. A dated HAR file showing a clean reject path is worth more than a screenshot of a banner.

Why this matters below the enterprise tier

It is tempting to read the headline fines as a large-company problem. The pattern in 2025 and 2026 says otherwise. The CNIL's simplified procedure, capped at €20,000 per decision, produced 23 sanctions in the first half of 2026 across fast-food chains, transport operators, ticketing services, law firms and medical practices, with cookie banners that offered one-click accept and multi-click refuse named as a recurring finding. The UK ICO opened the same kind of sweep: it reviewed the top 200 UK websites, contacted 134 of them over non-compliant cookie practices, and announced it would expand the review to the top 1,000, with further enforcement to follow as that wider sweep completes. Those are automated sweeps. They find exactly what the ten-minute test above finds, at scale.

What TagPatrol does with this

The walkthrough above is one page, one browser, one person. TagPatrol runs the same procedure with a real Chromium browser: your page in all three consent states, then up to 25 pages under a live reject-all and accept-all, with click recipes for OneTrust, Cookiebot, Didomi, Usercentrics, TrustArc and Klaro, and records every request, cookie and Consent Mode signal in each state. The report is the diff: what fired that should not have, where it came from, and what to change.

To see the pre-consent state of your own site without the DevTools work, the free scan at tagpatrol.app checks one page in one consent state and shows the first five findings. It takes about a minute, and it is a reasonable way to decide whether the full three-state audit is worth running.

Written by TagPatrol's AI content team and reviewed under human direction.