Fix guide · Webflow · medium · about 30 min

Meta Pixel not firing after cookie consent on Webflow

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

What this means

The Meta Pixel (still often called the Facebook Pixel) script is on your Webflow site, 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 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. If your consent tool shows its banner only in some regions, use a VPN or ask a colleague in the EU.

  1. Open your published site on the domain your ads link to, in a private (incognito) window.
  2. Open developer tools (F12), go to the Network tab and filter by facebook.com/tr.
  3. Click Accept on the cookie banner and 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.
  4. Click to another page. If events only appear now, the pixel starts one page too late and you lose the first page of every new visit (often the ad landing page).
  5. Open the Console tab and look for errors such as fbq is not defined.

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 Webflow 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. Repeat it on your other key pages, such as form and thank-you pages.

How to fix

The pixel is installed, but something between “visitor clicks Accept” and “pixel sends” is broken. Work along that chain.

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

  2. If you use Webflow’s built-in integration with “Delay for cookie consent” on (Site settings > Apps & Integrations > Meta Pixel): Webflow then starts the pixel with fbq('consent', 'revoke'), and nothing is sent until something on the page calls fbq('consent', 'grant'). Webflow does not connect this to your consent tool for you. Add a script that your tool runs only after marketing consent, for example in Site settings > Custom code > Footer code with Consent Pro:

    <script type="fs-consent" fs-consent-categories="marketing">
  fbq('consent', 'grant');
</script>

    With Finsweet’s older Cookie Consent use type="fs-cc" fs-cc-categories="marketing"; with Cookiebot use type="text/plain" data-cookieconsent="marketing". If you built your own banner from Webflow’s help article, check that its script calls fbq('consent', 'grant') when the visitor accepts and on later page loads.

  3. If the pixel is in custom code marked for your consent tool, check the category and the spelling:

    • Consent Pro version 2 assigns categories when it scans your site, and the category set in the app takes precedence over a fs-consent-categories attribute. Open the app, check that the pixel is listed under Marketing, and that your banner’s Accept button grants Marketing.
    • Switched consent tools? Scripts still marked type="fs-cc" are only started by Finsweet’s older fs-cc.js library. If that library is no longer on the site, and your new tool does not handle that attribute, those scripts never run.
    • Consent Pro on a custom domain needs a paid plan. Without one, the banner does not appear on the live domain, and scripts waiting for consent never run.

  4. If the pixel is in Google Tag Manager:

    • Open GTM’s Preview mode, enter your published URL and click Accept. Check that a consent update appears and that ad_storage changes to granted, then check whether the Meta tag fired or was blocked by consent.
    • A tag with only a page view trigger runs once, before the visitor has answered, and is blocked. Add the trigger your consent tool documents: Consent Pro’s GTM guide uses a Custom Event trigger named consent-updated; Finsweet’s older Cookie Consent pushes marketing-activated; Cookiebot pushes cookie_consent_marketing. Keep the ad_storage consent requirement and set the tag to fire Once per page.
    • Test both a first visit (click Accept) and a later page (consent already stored): the tag should fire once on each.

  5. Check script order. On Webflow, page-level custom code is placed after the site-wide code in the same section, and Footer code comes after everything in the <head>. If Meta’s base code is in Footer code but an event snippet such as fbq('track', 'Lead') is in a page’s Inside <head> tag field, the event runs before fbq exists and the console shows fbq is not defined. Put the base code in Head code.

  6. Check that the pixel is on every page. Code in one page’s settings, in a Code Embed on some pages only, or missing from CMS template pages or from a secondary locale (Webflow Localization lets each locale have its own page code) leaves those pages silent.

  7. Publish to your custom domain, not only to the webflow.io staging domain, and publish the GTM container if you changed it.

Common causes

  • Delay for cookie consent is on in Webflow’s Meta Pixel integration, but nothing calls fbq('consent', 'grant') after Accept.
  • The pixel is assigned to a category that the Accept button does not grant, or Consent Pro’s scan put it in a different category than the attribute says.
  • Scripts are still marked for a consent tool that was removed (for example type="fs-cc" after moving to Consent Pro).
  • The Meta tag in GTM has only a page view trigger and no trigger for the consent tool’s event.
  • The base code loads after page code that already calls fbq, so the event fails with a script error.
  • The site was published to the staging domain but not to the custom domain.

How to verify the fix

  1. In a fresh private window on the published custom domain: no facebook.com/tr requests before Accept, and a PageView request within a few seconds after Accept, on the same page.
  2. Open another page: PageView is sent once 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