Does Rejecting Cookies Actually Stop Tracking on Your Site?

A visitor lands on your site, sees the cookie banner, and clicks Reject All. They reasonably assume that is the end of it. On a surprising number of sites it is not: the Meta pixel still fires, LinkedIn still gets a page view, and advertising cookies are written to the browser anyway.

Nobody usually decides this. It happens because the banner was added on top of a tracking setup that was never wired to listen to it. The banner looks correct, the privacy policy reads well, and the tags underneath carry on as before.

The good news is that you do not need a specialist tool to find out. You can test it yourself in about fifteen minutes with a browser you already have.

Does clicking "Reject All" actually stop tracking?

Only if your tags are configured to respect it. The banner records the choice, but each tag on the page has to be told to check that choice before it runs, and many are not.

A consent banner is a user interface. On its own it blocks nothing. What stops tracking is the connection between the banner and your tags: consent settings in Google Tag Manager, a consent platform that controls script loading, or code that checks the stored choice before a pixel initializes.

When that connection is missing or incomplete, the banner and the tracking run independently. The visitor clicks Reject All, the banner records it, closes politely, and your advertising tags fire exactly as they did before the banner existed. From the outside, the site looks compliant. In the Network tab, it is not.

How do I test whether my site still tracks after I reject cookies?

Open a clean browser profile, load your site with DevTools open, click Reject All, then browse a few pages and watch which requests leave the browser and which cookies appear.

The steps, in Chrome or any Chromium browser:

Start clean. Use a new browser profile or a guest window with no extensions. An incognito window works, but make sure no ad blocker is running, because blockers hide exactly the requests you are looking for. If you are testing European behavior, you need to appear to be in Europe, so use a VPN set to an EEA country or the UK.

Open DevTools before the page loads. Press F12, go to the Network tab, tick Preserve log, and then load your homepage. Preserve log keeps requests visible as you navigate between pages.

Do not touch the banner yet. Look at what has already fired. Anything advertising related that appears before any choice is made is a problem on its own, because in opt-in regions nothing non-essential should run before consent.

Click Reject All, then browse. Visit three or four pages, including one with a form or a product. Filter the Network tab for each platform in turn:

• facebook.com/tr for the Meta pixel
• px.ads.linkedin.com or linkedin for the LinkedIn Insight Tag
• analytics.tiktok.com for the TikTok pixel
• collect for GA4, and googleadservices or doubleclick for Google Ads

Check the cookies. In DevTools go to Application, then Cookies, and select your domain. Look for _ga and _ga_ followed by an ID (GA4), _gcl_au and _gcl_aw (Google Ads), _fbp (Meta), _ttp (TikTok) and li_fat_id or similar LinkedIn identifiers. After a reject, in an opt-in region, none of these should be present. If you already had them from a previous visit, that is why you start from a clean profile.

Why do Google requests still appear after I reject cookies?

If you use Google Consent Mode in advanced mode, Google tags are designed to keep sending cookieless pings after a reject. That is expected. What matters is the consent state those requests carry, which you can read from the gcs parameter.

Open any GA4 collect request or Google Ads request and look at its query string. Find the gcs value. It encodes the consent state for storage:

• G100 means both ad_storage and analytics_storage are denied
• G111 means both are granted
• G110 and G101 are the mixed states

After Reject All, you should see G100 on every Google request. That tells you the tags are running in their restricted, cookieless state, which is how advanced Consent Mode works and what allows Google to model the conversions it can no longer observe directly. No _ga or _gcl cookies should be set.

If you see G111 after a reject, the banner is not sending its update to Google, or it is sending the wrong one. If you see no gcs parameter at all, Consent Mode is probably not implemented, and those requests are ordinary tracked hits.

In basic Consent Mode the picture is different. Google tags do not load until consent is granted, so after a reject you should see no Google requests at all.

Which requests after a reject mean the choice is being ignored?

Any request to a non-Google advertising platform after Reject All, in a region where consent is required, generally means the visitor's choice is not being honored.

Meta, LinkedIn and TikTok do not read Google's consent signals. They have their own mechanisms, and unless your setup explicitly holds them back, they fire. So a facebook.com/tr request with a PageView event after a reject is not a cookieless ping. It is a full tracking hit carrying the pixel ID, the page URL and, where the _fbp cookie exists, an identifier.

The same logic applies to Hotjar, Microsoft Clarity, Bing UET, Pinterest, Reddit, affiliate scripts and chat widgets that set marketing cookies. If it is not strictly necessary for the site to function and it runs after a reject, treat it as a finding worth investigating.

Why would tags ignore a rejected cookie banner?

Almost always one of four setup faults: tags in GTM with no consent requirements, pixels hardcoded outside GTM, tags firing before the banner has loaded, or a server-side container forwarding data without checking consent.

Tags in GTM with no consent checks. Google tags read Consent Mode signals automatically. Third-party tags do not. Unless each Meta, LinkedIn or TikTok tag has "Require additional consent" configured, or its trigger includes a condition based on the consent state, GTM fires it regardless of what the banner says. This is the most common cause we see, and it usually affects every non-Google tag in the container.

Pixels hardcoded outside GTM. A developer or a plugin added the Meta pixel directly to the site template years ago. It sits in the page source, not in your tag manager, so no consent setting in GTM will ever touch it. Ecommerce platforms and WordPress plugins are frequent sources, and sometimes the same pixel is installed twice, once correctly and once not.

Tags triggered on All Pages before the banner loads. If a tag fires on the All Pages or Initialization trigger and the consent platform script loads later, the tag has already run by the time the banner appears. The reject click comes too late. This also produces the pre-banner requests you saw in the first step of the test.

Server-side containers forwarding regardless of consent. With server-side tagging, the browser sends one stream of data to your own server, which then forwards it to Meta, Google and others. If the server container does not check the consent state on each incoming event before forwarding, the browser test can look perfectly clean while the data leaves from your server instead. You will not see it in the Network tab, so this has to be checked in the server container itself.

What is the risk if my site ignores rejected consent?

Regulatory exposure where opt-in consent is required, a credibility problem if a visitor or journalist notices, and data you cannot fully trust or defend.

In the EU and UK, the GDPR and UK GDPR, together with the ePrivacy rules, generally require prior opt-in consent before non-essential cookies and similar tracking. A banner that offers Reject All and then tracks anyway is, in most cases, worse than having no banner, because it shows you knew consent was needed and asked for it. Regulators and privacy advocates can run the same test you just ran, and it is easy to document.

There is also a commercial cost that is easy to miss. If some of your tags respect consent and others do not, your platforms are learning from inconsistent populations. Meta sees users that GA4 does not, and your reports stop reconciling for reasons nobody can explain. When you later fix the setup, the numbers shift again, and someone will ask why.

Exactly what is required depends on where your visitors are and what your tags do, so confirm the specifics with privacy counsel rather than treating this article as a legal assessment.

How do I fix tracking that ignores a rejected banner?

Make every non-essential tag depend on consent, remove any tracking that lives outside your tag manager, set the consent default before any tag loads, and apply the same rules on your server container.

Inventory every tag. List what runs on the site, where it is installed (GTM, hardcoded, plugin, platform app), and which consent category it belongs to.

Move hardcoded pixels into GTM or the consent platform. Remove them from templates and plugins, then reinstall them in one place where consent can be enforced. Check the page source afterward to confirm the old snippet is gone.

Add consent requirements to every non-Google tag. In GTM, set the required consent types on each tag, or use triggers that only fire once the relevant consent is granted. Where the vendor supports its own consent API, such as Meta's consent revoke and grant commands, wire that in as well.

Set defaults before anything fires. Consent defaults should run on the Consent Initialization trigger so the state is known before any other tag executes.

Check the server side. Confirm the server container reads the consent state on each event and does not forward advertising data for visitors who declined.

Retest after every change. Repeat the clean-profile test after each release. Tracking setups drift: a new campaign adds a pixel, a plugin update reintroduces a script, and the fix quietly unravels. An audit or scan that runs this check on a schedule catches drift before a regulator or customer does.

The short version

Clicking Reject All should leave Google requests showing G100 and nothing else from advertising platforms. If you see Meta, LinkedIn or TikTok requests, or advertising cookies, after a reject, the banner is decorative and the choice is being ignored. The fix is in the wiring, not the banner.

FAQ

Is it normal for Google Analytics requests to appear after I reject cookies?

Yes, if the site uses Google Consent Mode in advanced mode. Google tags send cookieless pings after a reject, and those requests should carry a gcs value of G100, meaning ad and analytics storage are denied. They should not set _ga or _gcl cookies. In basic Consent Mode, no Google requests should appear until consent is granted. A G111 value after a reject indicates a problem.

Why does the Meta pixel still fire after I click Reject All?

Usually because the pixel has no consent condition attached. Meta does not read Google's consent signals, so a Meta tag in GTM fires unless it is explicitly configured to require consent. The other common cause is a pixel hardcoded into the site template or added by a plugin, outside GTM, where no consent setting in the tag manager can reach it.

Which cookies should not exist after rejecting consent?

In regions where opt-in consent is required, advertising and analytics cookies should not be set after a reject. The ones to look for include _ga and ga with an ID for GA4, _gcl_au and _gcl_aw for Google Ads, _fbp for Meta, _ttp for TikTok, and LinkedIn identifiers such as li_fat_id. Test from a clean browser profile so old cookies do not confuse the result.

Can server-side tagging hide consent problems from a browser test?

Yes. With server-side tagging, the browser sends data to your own server, which forwards it to ad platforms. The browser test only shows the first leg. If the server container forwards events without checking the consent state, data can reach Meta or Google Ads even though the Network tab looks clean. The server container configuration has to be reviewed directly.

How often should I test whether my banner is being honored?

After any change to the site, tag manager or consent platform, and on a regular schedule regardless, monthly being a reasonable minimum for active advertisers. Tracking setups drift as campaigns add pixels and plugins update, so a setup that passed last quarter can fail today. A scheduled audit or scan makes this routine rather than something remembered only after a complaint.