Your Meta Pixel Is Tracking Visitors Before They Accept Cookies. Here's How to Fix It.

You can have a cookie banner on your website, a privacy policy in the footer, and still have the Meta Pixel fire before anyone clicks “Accept.”

I've seen this setup become surprisingly easy to get wrong, especially on WordPress sites where a plugin installs the pixel automatically.

The problem isn't necessarily the banner. It's what happens behind it.

If you're running Facebook or Instagram ads and using the Meta Pixel to track PageViews, leads, or purchases, here's what to check.

The problem: the banner appears, but the pixel is already running

A typical Meta Pixel installation looks something like this:

fbq('init', 'YOUR_PIXEL_ID');
fbq('track', 'PageView');

Those calls initialize the pixel and send a page view. If the browser executes them immediately, they can run before your visitor has made a choice in your cookie banner.

For websites serving visitors in the EU and UK, advertising trackers generally require consent before accessing or storing information on a visitor's device, subject to the applicable legal requirements.

Putting a banner on the page doesn't automatically make the tracking code wait.

And this isn't limited to Meta. TikTok, LinkedIn, Pinterest, Reddit, Microsoft Advertising, and other tracking tools can have the same problem.

Two ways to stop the Meta Pixel

Meta documents a consent API with two relevant calls:

fbq('consent', 'revoke');
fbq('consent', 'grant');

The first revokes pixel consent; the second grants it. But there are some details worth getting right.

Option 1: Don't load the pixel until consent is given

This is the straightforward approach.

Instead of allowing the browser to execute the script immediately, mark it so your consent manager can release it only after the visitor accepts marketing cookies.

For example, with Builderify:

type="text/plain"
data-bdf-consent="marketing">

// Your normal Meta Pixel initialization here
// fbq('init', 'YOUR_PIXEL_ID');
// fbq('track', 'PageView');

The browser doesn't execute a script with type="text/plain" as JavaScript. Builderify can release the script when the visitor gives marketing consent.

The advantage is that the browser doesn't even request Meta's pixel library before consent.

There is one important catch: every event needs to respect the same consent gate. If your purchase event runs separately on the checkout confirmation page, it can still cause problems.

Also check your pixel's fallback. An image-based tracking request can bypass a JavaScript-based consent mechanism.

Option 2: Use Meta's own consent API

If you want the pixel library to load before consent, Meta provides a different approach.

The important part is to revoke consent before initializing the pixel:

fbq('consent', 'revoke');
fbq('init', 'YOUR_PIXEL_ID');
fbq('track', 'PageView');

When the visitor accepts marketing cookies, your consent integration can grant consent:

fbq('consent', 'grant');

You need to handle the visitor's existing consent choice on every page load, not just on the first visit.

There's a trade-off here: the pixel library still loads from Meta, even while consent is revoked. Blocking the entire snippet avoids that request before consent.

For most people who simply want to prevent tracking before acceptance, the first approach is easier to reason about.

Five mistakes worth checking

Before assuming your website is compliant, look for these common problems.

1. Revoking consent after initialization

If fbq('init') or an event fires before the revoke call, the damage may already be done. Follow Meta's documented ordering.

1. Handling consent only on the landing page

Someone who accepted cookies last week shouldn't have to accept again on every page. Your integration needs to restore the saved choice and apply the appropriate consent state on subsequent page loads.

1. Leaving purchase events outside the consent gate

Your base pixel might be blocked while a separate Purchase, Lead, or CompleteRegistration event still executes. Gate the event code too.

1. Forgetting the no-JavaScript fallback

A tracking image can send a request even when your JavaScript banner never gets the chance to ask for consent. Review whether you need it and how it can respect your consent requirements.

1. Ignoring server-side tracking

The Meta Conversions API is a separate consideration. It sends events from your server or another integration directly to Meta, so a browser cookie banner cannot automatically control those requests.

If you're using both browser and server-side events, make sure the server-side integration follows your consent decisions too.

What if you use WordPress?

WordPress makes this a little more complicated because your theme, plugins, and tag managers can all add tracking code.

The Meta Pixel plugin and tools such as PixelYourSite may insert the script automatically. In that case, adding a custom attribute to a script in your theme won't necessarily change the code generated by the plugin.

You have a few options:

Configure consent handling through the plugin, if supported.

Disable the plugin's pixel injection and let your consent manager handle the pixel.

Use a tag manager or another integration that respects the visitor's consent state.

After making changes, test the actual page source and browser network requests. Don't rely solely on the fact that the cookie banner appears correctly.

A quicker way to check your tracking setup

I built a checker as part of the Builderify guide that looks for tracking scripts in your page source.

It can identify code from Meta, TikTok, LinkedIn, Microsoft UET, Pinterest, Snap, X, and Reddit, flag common cases where tracking runs before consent, and generate a version that holds the relevant scripts until consent.

The check runs in your browser; the pasted source isn't sent to a server.

It also has limitations. It can't reliably detect everything injected later by plugins, tag managers, Shopify app pixels, or server-side integrations. Treat the output as a debugging aid, not a legal compliance certificate.

The simpler alternative: let your consent banner manage the tags

If you're already configuring a cookie banner, you may not need to maintain every tracking snippet manually.

Builderify's cookie consent feature lets you connect supported tracking tags by ID or mark scripts so they wait for the appropriate consent category.

That means you can manage marketing tags in one place rather than having separate implementations scattered across your theme and plugins.

It supports tags for Meta, TikTok, LinkedIn, Microsoft UET, Pinterest, Snap, X, Reddit, and several analytics tools.

There are limitations. Connecting a pixel by ID handles its base page-view integration; custom purchase and lead events still need to be configured correctly. Server-side events also need their own consent handling.

Builderify isn't an IAB TCF platform or a guarantee of legal compliance, so check your advertising and regulatory requirements before switching tools.

Final checklist

Before sending another campaign to your website, I'd check these five things:

The Meta Pixel doesn't fire before the required marketing consent.

Existing consent choices are respected on every page.

Purchase and other custom events follow the same consent rules.

No-JavaScript fallbacks and plugins aren't bypassing the consent mechanism.

Server-side tracking handles consent separately where necessary.

A working cookie banner is only one part of the setup. The real test is what your website sends before the visitor makes a choice.

Read the complete guide and try the checker here:

Meta Pixel Cookie Consent: How to Hold Tracking Until Consent

The full guide includes code examples for both Meta consent methods, a multi-pixel source checker, and instructions for connecting tracking tags through Builderify.

Disclaimer: This article is for technical information, not legal advice. Consent requirements depend on the applicable laws and your website's configuration.