Meta Pixel firing before consent is one of the most common findings in real-world scans — and one of the easiest to miss, because fixing Google Consent Mode correctly does nothing for it. Meta Pixel has no native consent API of its own, so "Consent Mode is working" and "Meta Pixel is gated" are two entirely separate facts about a site, not one.
Why fixing Consent Mode doesn't touch Meta Pixel at all
Google Consent Mode works through gtag('consent', ...) — a Google-specific API that only
Google's own tags (GA4, Google Ads, Floodlight) check automatically. Meta Pixel doesn't
call or check this API, because it's not Google's spec. A site can have a textbook-correct
Consent Mode implementation — default and update both complete, all four consent types
correctly set — and Meta Pixel will still fire on every page load regardless, because
nothing is telling it to wait. Gating Meta Pixel requires a separate, explicit mechanism.
1. Check whether your CMP's script-blocking actually covers the pixel
How to check: in your CMP's admin panel (Cookiebot, OneTrust, Termly, and similar all
support this), find the category your Meta Pixel is assigned to — typically "Marketing" or
"Advertising" — and confirm the pixel is listed as a blocked script under that category
before consent. Then check DevTools Network tab in a fresh incognito session: if you see
requests to facebook.com/tr or connect.facebook.net/signals before clicking anything,
the category setting and the actual behavior disagree.
The fix: this usually means the pixel is loading through a path the CMP's
auto-blocking doesn't intercept — a hardcoded snippet in the page template, a pixel loaded
by a separate app/theme integration (common on Shopify and similar platforms), or a pixel
injected by a different tag manager instance. Auto-blocking works by pattern-matching known
script tags before they load; anything outside that pattern needs manual blocking instead
— rewriting the pixel's script tag with a type="text/plain" (or your CMP's equivalent
data-attribute convention) so it only executes after the CMP explicitly re-enables it.
2. If you load Meta Pixel through GTM, check its Additional Consent Checks
How to check: in GTM, open your Meta Pixel tag and check its Consent Settings (Advanced Settings → Consent Settings, or "Require additional consent for tag to fire"). If no additional consent type is required there, GTM will fire the tag as soon as its trigger condition is met, with no relationship to your CMP's category state at all.
The fix: add a custom consent type (commonly something like ad_storage or a
CMP-specific consent signal, depending on your setup) to the tag's Additional Consent
Checks, and make sure your CMP's integration actually pushes that consent state into
dataLayer when a visitor accepts — the same dataLayer consent entries covered in
consent default fires after GTM, just referenced
by a non-Google tag instead of a Google one. This is the GTM-native way to gate a
non-Google tag behind consent, and it's independent of whether the tag is also covered by
CMP-level script-blocking — either mechanism alone can work, but only if actually
configured.
3. Check whether the pixel fires on Reject, not just before any choice
How to check: click Reject on your own banner (not Accept), then reload and check the Network tab again. A pixel that respects consent should show zero requests after an explicit reject — the same check covered in how to check if cookies fire before consent, applied specifically to the pixel.
The fix: if the pixel still fires after Reject, whatever blocking mechanism is in place isn't actually connected to the CMP's reject action — re-verify the category mapping and the auto-blocking pattern match from check #1, since a mechanism that only responds to "before any interaction" but not to an explicit reject usually means the blocking is based on page-load timing rather than the actual consent decision.
Why this one specifically carries more than a compliance risk
Meta Pixel is one of the most frequently named tags in current US wiretapping-style lawsuits (CIPA and comparable state statutes) targeting website tracking — alongside session-replay tools. That's a documented litigation pattern, not a hypothetical, and none of this is legal advice — if you've actually received a demand letter, that's a conversation for a lawyer, not a blog post. What it does change is prioritization: this is worth fixing before a lower-profile tag if you're triaging multiple pre-consent findings at once.
If you'd rather have this checked automatically
A pre-consent scan checks exactly this: whether Meta Pixel (and 25+ other tracker signatures) fires before consent, whether it respects an explicit Reject, and which specific request is responsible — worth running after any fix to confirm it actually closed the gap rather than just changed which script pattern triggers it.
— Petrus, ConsentCheck founder. Meta Pixel is the tag I see "fixed" incorrectly most often -- someone fixes Consent Mode, checks the box mentally, and never realizes the pixel was never actually connected to it in the first place.