Fix guide · WordPress · medium · about 45 min

Meta Pixel not firing after cookie consent on WordPress

For the finding “Meta Pixel does not fire after consent”. Also for: Any website, Shopify, Webflow, Framer.

What this means

The Meta Pixel (still often called the Facebook Pixel) script is on your page, but after cookies were accepted, no events were sent to Meta. As far as Meta is concerned, this page has no visitors.

Why it costs you money:

  • Meta cannot see page views or conversions (including WooCommerce add-to-carts and purchases) from this page, so campaigns optimize without data and reported results are too low.
  • Retargeting audiences built from site visitors stop growing.

How sure we are: if our checker found and accepted your cookie banner, this is reported as critical. If we did not find a banner we could operate, it is reported as high: the pixel may be waiting for a banner we did not recognize. Test it yourself before changing anything.

How to confirm it yourself

Our check runs from a browser in the EU, so EU consent rules on your site apply to it. If your banner only appears for EU visitors, use a VPN or ask a colleague in the EU.

  1. Log out of WordPress, or use a private (incognito) window. Logged-in administrators often get different pages: some tracking plugins skip them, and optimization plugins may only optimize pages for visitors who are not logged in.
  2. Open developer tools (F12), go to the Network tab and filter by facebook.com/tr.
  3. Load the page and click Accept (accept all) on the cookie banner.
  4. Wait about 5 seconds. You should see a request with ev=PageView (in Chrome possibly of type ping). If nothing appears, the pixel does not fire after consent.
  5. Open another page. If events only appear now, the pixel starts one page too late and you lose the first page of every visit, often the ad landing page.

Meta Ads Data Advisor (Meta’s Chrome extension, formerly Meta Pixel Helper) and the Test events tool in Meta Events Manager (Data sources > your pixel > Test events) show the same thing from Meta’s side.

The same test tells you whether the Meta Pixel is working on your WordPress site at all: a PageView request with your pixel ID (id in the payload) right after Accept, also listed in Test events, means it works on that page. On a WooCommerce store, repeat it on a product page and after Add to cart.

How to fix

On WordPress the chain is usually: consent plugin, then the plugin, snippet or GTM tag that loads the pixel, with a caching or optimization plugin in between. Check each link.

  1. Check that the consent plugin records the choice. After clicking Accept, reload: the banner should not come back. If it does, fix the consent plugin first.

  2. Check the pixel’s category. The pixel must sit in a category that your Accept button grants: marketing in most plugins, Advertisement in CookieYes. In Complianz look at Complianz > Integrations; in Cookiebot, at the add-on or the data-cookieconsent value; in Borlabs Cookie and Real Cookie Banner, at the service the pixel belongs to.

  3. Test without optimization. Temporarily turn off JavaScript optimization in WP Rocket, LiteSpeed Cache, Autoptimize or similar, clear all caches and test again. If the pixel now fires after Accept, the optimization was the cause. These plugins rewrite script tags: they combine files, move inline code into combined files, defer scripts or delay them until the visitor interacts. Consent plugins block and later re-enable the pixel by recognizing its script tag or code; once that code has been rewritten or merged, the consent plugin may not recognize it any more. The Meta for WooCommerce documentation also notes that the JavaScript grouping in some caching plugins conflicts with the pixel code, and that the fix is to turn off JS grouping. Turn optimization back on with exclusions:

    • WP Rocket: on the File Optimization tab, add the exclusions to the exclusion field of every JavaScript option you use (for Delay JavaScript execution it is Excluded JavaScript Files).
    • LiteSpeed Cache: use JS Excludes and JS Deferred / Delayed Excludes on the Tuning tab of Page Optimization, or set Load JS Deferred to Off.
    • Autoptimize: use Exclude scripts from Autoptimize, and consider turning off Also aggregate inline JS.

    Exclude your consent plugin’s scripts (its documentation lists them; CookieYes, for example, publishes exact exclusions for WP Rocket) and the pixel code: fbevents.js, fbq, and the script folder of the plugin that loads the pixel.

  4. If PixelYourSite loads the pixel: in its consent settings, check that the integration you switched on is for the consent plugin you actually use (PixelYourSite marks integrations whose plugin it cannot find as not detected). Its documentation also says it cannot guarantee that every consent plugin handles consent correctly in every setup, so test after each change.

  5. If the pixel is in Google Tag Manager (added by Site Kit, GTM4WP or a theme snippet):

    • Open GTM Preview mode, load the site and click Accept. Check that a consent update appears and ad_storage becomes granted.
    • Check whether the Meta tag fired. Blocked by consent means the consent update did not arrive. Not fired means its trigger never ran.
    • A Meta tag with only a page view trigger runs once, before the visitor clicks Accept, and never again on that page. Add a trigger for the data layer event your consent plugin pushes when consent changes (GTM Preview shows its exact name; GTM4WP can also push such events for some consent plugins), keep the ad_storage requirement, and set the tag to fire Once per page.

  6. Look for leftovers from an old consent plugin. If you switched consent plugins, search your theme files, snippet plugins and page builder code for type="text/plain", data-cookieconsent or data-cookieyes. A pixel tag marked for the old plugin stays disabled, because the new plugin does not look for that marker.

  7. If you use Meta’s consent commands in your own code (fbq('consent', 'revoke') before init): make sure your banner’s Accept handler calls fbq('consent', 'grant') on the current page.

  8. Check the browser console (developer tools, Console tab) for errors from fbevents.js, the pixel plugin or the optimization plugin.

  9. Clear every cache (plugin, host and CDN) after each change, then test again while logged out.

Common causes

  • An optimization plugin combines or delays the pixel code, so the consent plugin cannot re-enable it after Accept.
  • The pixel is assigned to a category that the Accept button does not grant.
  • A pixel tag is still marked for a consent plugin you no longer use.
  • The Meta tag in GTM fires only on the first page view, before consent, and never again on that page.
  • Changes were made, but a page cache, host cache or CDN still serves the old pages.

How to verify the fix

  1. In a fresh private window, logged out: no facebook.com/tr requests before Accept, and a PageView request within a few seconds after Accept, on the same page.
  2. Reload the page: PageView is sent on load without clicking anything.
  3. Re-run the check on IsPixelWorking. The issue should be gone, and “Meta Pixel fires before cookie consent” should not appear in its place.

Sources