What you must block before consent (and what you must not)

Under the GDPR and ePrivacy rules, the test is simple: anything that stores or reads data on the visitor's device and is not strictly necessary for the service they requested needs consent first. The hard part is knowing what, concretely, that covers on a modern website — because it is much more than 'analytics'. Here is the working checklist we apply when scanning sites.

The rule of thumb

Ask two questions about every third-party resource on your page: does it set or read cookies (or localStorage, or fingerprint the device)? And would the page still deliver what the visitor came for without it? If it tracks and the page works without it, it waits for consent. Full stop.

Block until consent: the usual suspects

• Google Analytics 4 — sets _ga cookies and sends behavioral data on load. Category: analytics.
• Google Ads / conversion tags and DoubleClick — advertising cookies, remarketing lists. Category: marketing.
• Meta (Facebook) Pixel — sets _fbp and matches visitors to profiles the moment it runs. Category: marketing.
• TikTok, LinkedIn Insight, X/Twitter pixels — same story, same category.
• Session-replay and heatmap tools (Hotjar, Microsoft Clarity) — record behavior, set identifiers. Category: analytics.
• YouTube and Vimeo embeds — a standard YouTube iframe sets tracking cookies before the visitor presses play. Use the privacy-enhanced domain (youtube-nocookie.com) or hold the iframe behind a consent placeholder.
• Google Maps embeds — set cookies and expose the visitor's IP to Google; show a static image or placeholder until consented.
• Chat and support widgets (Intercom, Zendesk, Crisp) — set visitor identifiers on load; load them after consent or on first interaction.
• A/B testing and personalization tools — identifiers by design. Category: preferences or analytics depending on use.
• Embedded social feeds and share buttons that load vendor JavaScript.

How blocking actually works

The mechanics matter, because a banner that merely hides while trackers run is the most common compliance failure on the web — see prior-blocking explained. There are two reliable techniques:

1. Script neutralization: the consent layer rewrites tracker script tags to type="text/plain" so the browser won't execute them, and restores the real type only for categories the visitor accepted.
2. Placeholder embeds: iframes (video, maps) are replaced with a lightweight preview that explains what will load; the real embed is injected only after consent.

<!-- Held until the visitor accepts "marketing" -->
<script type="text/plain" data-cc-category="marketing"
  src="https://connect.facebook.net/en_US/fbevents.js"></script>

Auto-blocking covers the known universe: a good consent platform recognizes common trackers by URL pattern and holds them without you editing markup. Manual tagging covers the rest — your custom scripts, unusual vendors — with an explicit category attribute.

Never block: strictly necessary

Blocking too much is its own failure — it breaks the site and, worse, some teams respond by blocking nothing. These run without consent, legitimately:

• Session and authentication cookies — the visitor asked to be logged in.
• Shopping cart contents and checkout state.
• CSRF tokens and other security cookies.
• Load-balancer affinity cookies.
• The consent cookie itself — remembering the choice is what the law wants.
• A language or accessibility preference the visitor explicitly set (defensible as necessary or as 'preferences' — categorize it honestly).

The part everyone forgets: drift

Your cookie inventory is only correct until the next deploy. A marketing colleague pastes one new tag into the tag manager and your carefully audited site is non-compliant again, silently. This is why scanning has to be recurring, not a launch-day ritual — and why the scanner must execute JavaScript like a real browser, because most trackers today are injected dynamically by other scripts.