Blocking Scripts Before Consent: Is It a Legal Requirement

A cookie banner that only displays a message, without actually holding back Google Analytics or the Meta Pixel from loading, doesn't meet the legal requirement. Under EU law, non-essential scripts must stay inactive until a user gives consent — that's not a UX nicety, it's a technical requirement that regulators (France's CNIL, and increasingly others across the EU) now check directly in a site's code rather than by eye.

What blocking scripts before consent actually means

Blocking scripts before consent means tracking code — the Google Analytics 4 tag, the Meta Pixel, the LinkedIn Insight Tag, a chat widget script — physically doesn't execute in the visitor's browser until they click "accept" on the consent banner. The script can be present in the page's code, but a CMP (Consent Management Platform) holds back its execution until the visitor makes a decision.

That's different from merely displaying a banner, which in many implementations is just a visual layer sitting on top of scripts that have been running since the page's first millisecond — the visitor sees a consent prompt while, in the background, Google Analytics has already set a cookie and fired a pageview event.

Is blocking scripts before consent a legal requirement

Yes — it's a legal requirement, not an optional best practice. EU law requires a user's consent before any non-essential cookie is set on their device, under national laws implementing the ePrivacy Directive (in Poland, the Electronic Communications Law, in force since November 10, 2024, replacing the earlier telecommunications-law provision). The GDPR governs what counts as valid consent — it must be freely given, specific, informed, and unambiguous — but it's the electronic communications law, transposing the EU's ePrivacy Directive, that creates the specific obligation around cookies and similar tracking technologies.

If a script fires and sets a cookie before the user has clicked anything, consent collected a second later is legally worthless — the data already leaked before the decision was made. That's why a banner with an "accept" button alone isn't enough; it needs a technical block behind it that actually halts code execution, not just a button that changes the text on screen.

Consent Mode v2 is not the same thing as blocking scripts

A common mix-up: implementing Google Consent Mode v2 gets confused with fully blocking scripts, but they're two different mechanisms. Consent Mode doesn't stop a Google tag from firing — the tag still loads and runs, it just adjusts what data it sends based on the reported consent state. In Advanced mode, without consent it sends cookieless, anonymized pings instead of full data. We cover the Consent Mode mechanism itself in more depth in Consent Mode v2 and data loss.

That's an important legal distinction: Consent Mode governs what Google does with data on its own side, but it doesn't replace the obligation to not activate unnecessary cookies on your side, in the visitor's browser. A correct setup combines both mechanisms — the CMP blocks script execution until consent, and Consent Mode additionally passes Google a signal about that consent state.

What correct script blocking looks like in practice

A correct block isn't a single switch — it's several pieces that have to work together, from tag categorization to a test on a clean browser session.

• Categorizing scripts in the CMP — every tag (analytics, marketing, functional) assigned to a consent category, with a default denied state for everything except strictly necessary ones.
• Blocking at the Google Tag Manager level — tag triggers conditioned on a consent variable, not just on page load; a tag waits for the consent initialization and update signal before it fires.
• Scripts loaded asynchronously after consent, rather than sitting in the page's code as an unconditional script tag from the start.
• Testing in incognito mode before every banner change — the only reliable way to see what actually loads on a clean session with no prior consent stored in the browser.

What not blocking costs — fines and risk

Enforcement of this obligation isn't theoretical. France's CNIL fined Google €100 million and Amazon €35 million in December 2020 for failing to properly block cookies before consent, then fined Google €150 million and Facebook €60 million in January 2022 for making it harder to refuse consent than to accept it. Poland's UODO has so far enforced this less often than CNIL, but the Electronic Communications Law gives it the same enforcement tools, and European regulators increasingly test sites technically, not just visually.

How to check whether your site actually blocks scripts

The fastest way is to open your browser's dev tools (the Network tab) in incognito mode, before clicking anything on the banner — if network requests to google-analytics.com or facebook.com/tr already show up, the block isn't working, no matter how the banner itself looks. We built exactly this check into an automated tool — our free Consent Mode and cookie consent checker scans a site across three passes (before consent, after acceptance, after refusal) and shows precisely which scripts fire before they should.

• Whether trackers (GA4, Meta Pixel, ad pixels) stay silent before any user decision
• Whether marketing scripts stay blocked after a refusal, not just on the first page load
• Whether Consent Mode v2 passes both required parameters — ad_user_data and ad_personalization
• Whether the default consent state is denied rather than granted

Common mistakes in blocking scripts

• Blocking only on the first visit — on a return visit, if the stored consent isn't read correctly, scripts fire anyway because the browser cache "remembers" the old decision differently than the developer assumed.
• A CMP wired to the banner but not to Tag Manager — the banner looks correct, but the GTM container still loads every tag right at page start.
• Blocking only at the visual layer — the script is hidden on screen but still executes and sets cookies in the background.
• An exception for "important" marketing tags — some companies deliberately don't block Google Ads or Meta because they don't want to "waste budget on the algorithm's learning phase" — that's a direct route to a fine.
• No test after every page change — a new form, integration, or chat script added without checking whether it's subject to the same block as everything else.

Blocking scripts before consent is the foundation the rest of your measurement stands on — if this layer leaks, no campaign optimization in Google Ads or Meta Ads has solid input data. We run server-side GTM and GA4 measurement setups as Zest always starting from an audit of the consent layer, because a mistake at this level corrupts every number built on top of it.

Want to check whether your site actually blocks scripts before a user gets to decide? Let's talk — we audit your CMP setup together with Consent Mode and show exactly what's leaking before consent.

FAQ