---
title: "Meta Pixel not firing after cookie consent on WordPress"
description: "The Meta Pixel is on your WordPress site but sends nothing after visitors accept cookies. Check the consent plugin, caching and optimization plugins, and GTM."
updated: "2026-10-04"
url: "https://ispixelworking.com/guides/meta.not_firing_after_consent/wordpress"
---

# Meta Pixel not firing after cookie consent on WordPress

Fix guide · WordPress · medium · about 45 min · updated 2026-10-04

For the finding “Meta Pixel does not fire after consent” (`meta.not_firing_after_consent`).
Also for: [Any website](https://ispixelworking.com/guides/meta.not_firing_after_consent/generic), [Shopify](https://ispixelworking.com/guides/meta.not_firing_after_consent/shopify), [Webflow](https://ispixelworking.com/guides/meta.not_firing_after_consent/webflow), [Framer](https://ispixelworking.com/guides/meta.not_firing_after_consent/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

- WooCommerce, Meta for WooCommerce documentation (caching plugins that group JavaScript, turning off JS grouping): https://woocommerce.com/document/facebook-for-woocommerce/
- WP Rocket Knowledge Base, Delay JavaScript execution (File Optimization tab, Excluded JavaScript Files): https://docs.wp-rocket.me/article/1349-delay-javascript-execution
- LiteSpeed, LSCache for WordPress, Page Optimization (Load JS Deferred, JS Excludes, JS Deferred / Delayed Excludes, Optimize for Guest Only): https://docs.litespeedtech.com/lscache/lscwp/pageopt/
- WordPress.org, Autoptimize (aggregating inline JS, excluding scripts): https://wordpress.org/plugins/autoptimize/
- CookieYes, How to exclude the CookieYes script from WP Rocket: https://www.cookieyes.com/documentation/exclude-cookieyes-script-from-wp-rocket-plugin/
- Complianz, Does Complianz work with caching plugins?: https://complianz.io/does-complianz-work-with-caching-plugins/
- Complianz, Integrations: Script Center, Plugins & Services: https://complianz.io/integrating-plugins/
- Cookiebot, Manual implementation (`data-cookieconsent` categories): https://www.cookiebot.com/en/manual-implementation/
- CookieYes, How to implement prior consent (`data-cookieyes` categories): https://www.cookieyes.com/documentation/implement-prior-consent-using-cookieyes/
- PixelYourSite, ConsentMagic and other WordPress consent plugins: https://www.pixelyoursite.com/docs/consentmagic-integration
- WordPress.org, GTM4WP (consent integrations and data layer events): https://wordpress.org/plugins/duracelltomi-google-tag-manager/
- Google Tag Manager Help, Tag Manager consent mode support: https://support.google.com/tagmanager/answer/10718549
- Meta for Developers, General Data Protection Regulation (consent API): https://developers.facebook.com/docs/meta-pixel/implementation/gdpr
- Meta Business Help Center, Test events tool: verify app and web browser events for Meta: https://www.facebook.com/business/help/2040882565969969