A cookie banner only counts if clicking Reject changes what the browser sends. On many sites it does not: the banner appears, the visitor declines, and analytics, ad pixels or session recording keep firing exactly as before. You can check this yourself in about five minutes with the browser's developer tools, or run a free scan that shows what fires on a visit where the banner is declined, or left unanswered where there is no reject control.
What does "tags firing after reject" actually mean?
It means a tracking request leaves the browser after the visitor has declined consent, carrying the same identifiers it would carry after an accept. The banner has been shown and the choice recorded somewhere, but nothing downstream reads that choice. The site looks compliant to a visitor and to a source-code scanner, and behaves as if the banner were not there.
There are three states to tell apart, and only the third is a working block:
| state | what the network shows after Reject |
|---|---|
| No gating | Every tag fires on page load, before the banner is answered, and again after Reject. |
| Partial gating | Some tags wait for consent and others do not. The most common pattern is an analytics tag behind the banner and an ad pixel, chat widget or session-recording script outside it. |
| Enforced | After Reject, no request goes to analytics, advertising or recording endpoints, or only cookieless "denied" pings go (Google's Consent Mode in its advanced form). |
How do I test a cookie banner in five minutes?
You need a browser that has never seen the site. A private window is not enough if you have visited before in that profile; use a fresh profile or clear site data first.
- Open DevTools → Network before you load the page. Tick Preserve log. Filter by the word
collect,pixel,tr,eventsor the vendor names you expect (for examplegoogle-analytics,facebook,clarity,hotjar). - Load the page and stop. Do not touch the banner. Note every request in the filter that already went out. Anything here fired before consent.
- Click Reject (or "Necessary only", "Decline", "Continue without accepting"). Watch the network panel for ten seconds.
- Scroll to the bottom, click one internal link, and start typing in a form field without submitting. Many tags fire only on interaction, so a page-load-only check misses them.
- Read what you see. Every request to an analytics, advertising or replay endpoint after step 3 is a tag firing after Reject. Open the request and check the query string or payload: if it carries a client or user id, it is identifying the visitor, and a
gcs=G100-style parameter in a Google request means the tag is at least saying consent was denied. - Check cookies under Application → Cookies. Compare the list with what the banner's own policy says is "necessary".
Write down three things per tag: did it fire before the banner, did it fire after Reject, and does it carry an identifier. That table is the finding.
Why do tags fire after Reject even with a consent platform installed?
Not because the consent platform is broken. In the audits we run the banner itself is almost always installed correctly; what fails is the wiring between the banner and the tags. The usual reasons:
- Tags added outside the tag manager. A pixel pasted into the theme, a chat widget, a hosted form, an A/B testing snippet or a video embed does not know the banner exists. The banner blocks what it was told about and nothing else.
- Tags in the tag manager without a consent trigger. The consent platform sets a signal; each tag still needs a trigger or built-in consent check that reads it. A tag that fires on "All Pages" fires on all pages.
- Consent read before it is set. The tag manager loads and fires before the consent script has run, so the first page view goes out under whatever default the tag manager assumes, which is often "granted".
- Defaults set to granted. Google's Consent Mode has a default state per consent type. If the defaults are "granted" until the visitor acts, everything fires on load and Reject only affects later pages.
- A second copy of the tag. Two GA4 configurations, or a tag manager plus a hard-coded snippet, where one copy is gated and the other is not. The gated one waits; the other fires.
- Third-party scripts that load their own trackers. The script you gated is blocked; the script you allowed as "necessary" drops a recording or advertising cookie of its own.
- Reject that only closes the banner. The button dismisses the overlay and never writes a decision, so every tag reads "no choice yet" and falls back to its default.
None of these is visible from the banner's settings screen. All of them are visible in the network panel.
What does a working block look like?
After Reject, the network panel shows requests to your own domain and to whatever the page needs to render, and nothing to analytics, advertising or replay endpoints. If you use Google's Consent Mode in its advanced form, you will see cookieless requests to Google endpoints carrying a "denied" consent state and no client id cookie; that is by design, and it is the one case where a request after Reject is not a failure. Interaction should change nothing: scrolling, clicking and typing produce no new tracking requests. Cookies are limited to the ones your policy names as necessary, and none of them belongs to an analytics or advertising vendor.
How do I check this on a site I don't control?
The same way. The developer-tools method needs nothing from the site owner, and neither does TagAudit's free scan: give it a public URL and it opens the site in a clean browser with no cookies, scrolls, clicks and fills form fields without submitting them while the banner is still unanswered, then visits again with the banner declined, or left unanswered where there is no reject control, and lists every tag it found and what fired. Agencies use it before a pitch and on the first day of an engagement, when there is no access to the tag manager yet.
What this method can't tell you
- Whether the site is legally compliant. It shows which requests leave the browser and when. What counts as necessary, and what a regulator would accept, is a legal question about your jurisdiction and your purposes. Treat the network evidence as the input to that conversation, not the verdict.
- Server-to-server tracking. Conversions API, offline uploads and warehouse syncs never pass through the visitor's browser, so a browser-side test cannot see them. Check those in the vendor accounts.
- What happens after a form submit or a purchase. A test on a site you do not own should never submit forms or complete a checkout, so tags that fire only after one stay unobserved. TagAudit's own scan works the same way: actions that would send something to a site are switched off in our current configuration, on every site.
- Every page. A tag missing on the homepage can be present on the blog template or the checkout. Test the templates that matter, not one URL.
- Geography. Some sites show a different banner, or none, depending on where the visitor is. A test from outside the EU can pass a banner that fails for EU visitors.
FAQ
Is "Reject" the same as "Necessary only"? For this test, yes. Any control that lets a visitor decline non-essential tracking counts. What matters is what fires afterwards.
My banner is from a large consent vendor. Do I still need to test? Yes. The banner and the tags are wired separately, and the most common finding across the audits we run is a properly installed banner that gates only part of the stack.
Does a request after Reject always mean a problem? No. A cookieless request that carries a "denied" consent state, as Google's advanced Consent Mode sends, is intended behaviour. A request carrying the same client id it would carry after Accept is the problem.
How often should I re-test? Every time a tag, plugin, theme or consent setting changes, and after any site migration. Tags are added far more often than banners are reconfigured.