Blocking Scripts Before Consent: Is It a Legal Requirement

A cookie banner that only displays a message, without 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 a technical requirement, and regulators (France's CNIL, and increasingly others across the EU) now check it directly in a site's code.

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. In many implementations the banner 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. 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. The specific obligation around cookies and similar tracking technologies comes from the electronic communications law, which transposes the EU's ePrivacy Directive.

If a script fires and sets a cookie before the user has clicked anything, consent collected a second later is legally worthless, because the data leaked before the decision was made. That's why a banner with an "accept" button alone isn't enough. You need a technical block behind it that actually halts code execution.

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 controls Google tags and nothing else. In Advanced mode the Google tag loads and runs right away, and without consent it sends measurements without cookies; Basic mode holds Google tags back until the user decides (Google documentation). 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 release you from the obligation to keep unnecessary cookies out of 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 consists of 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 instead of page load alone; 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 (decision SAN-2020-012) and Amazon €35 million (decision SAN-2020-013) in December 2020 for failing to properly block cookies before consent, then fined Google €150 million (decision SAN-2021-023) and Facebook €60 million (decision SAN-2021-024) for making it harder to refuse consent than to accept it (decisions dated December 31, 2021, announced in January 2022). In Poland, the cookie rules in Art. 399 of the Electronic Communications Law (Journal of Laws 2024, item 1221) are enforced by the President of UKE, the electronic communications regulator, who can impose a financial penalty for breaching them (Arts. 444 and 446). The data protection authority (UODO) steps in when a GDPR breach is also involved, such as processing personal data without a legal basis. European regulators increasingly test sites technically as well, in the code and network traffic.

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. Our free Consent Mode and cookie consent checker runs the same check automatically: it 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 on every later page load too, beyond the first one
• 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 consent record in a cookie or localStorage "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. You can check whether GA4 measures traffic correctly after consent with our free GA4 audit.

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