Written from production audits, not documentation. Each cause comes with a verification step you can run in minutes - because "the pixel is installed" and "the pixel is firing" are very different claims.
The short answer, in the order to check them: a consent banner that never releases the tag, a caching plugin’s delay-JavaScript option that makes fbq arrive after the script that calls it, the pixel initialised more than once, a GTM trigger chain that never completes, a redirect checkout that eats the Purchase, a checkout in an iframe or on another domain, and finally ad blockers and browser privacy, which is the only one you cannot fix client-side. On WordPress the second one is by far the most common and the hardest to catch, because it hides while you test it.
First, know what you're looking for. A firing pixel sends network requests to facebook.com/tr. Open DevTools > Network, filter by tr, and act on the site. No requests = not firing, whatever your tag manager says.
If you run Cookiebot, OneTrust or any CMP in opt-in mode, the pixel is legally supposed to stay silent until the visitor accepts. The bug: after acceptance it often STAYS silent, because the pixel tag in GTM is not wired to the consent state, or fires before consent updates.
facebook.com/tr requests. Silent even after full acceptance = your consent wiring is broken, not working.WP Rocket, LiteSpeed and Perfmatters all have a “delay JavaScript execution” option. It wraps your inline fbq('init') in <script type="text/rocketlazyloadscript">, so fbq does not exist until the visitor first moves the mouse or scrolls. Meanwhile whatever calls fbq - a page builder’s tracking script, GTM, your theme - usually is not delayed, because the default exclusion list has a broad rule covering /wp-content/. The consumer runs before the provider exists, throws ReferenceError: fbq is not defined, dies on that line, and the PageView never happens.
It is a race, not a constant. It only works when the visitor happens to interact before that script runs, which is why the same page seems fine sometimes.
This is the one that hides from manual testing. Opening the page and checking with Pixel Helper moves the mouse, and moving the mouse is exactly what releases the delayed scripts. The bug disappears while you look at it. That single sentence usually explains why a client has been stuck on this for a month.
This cause has its own full write-up with the exclusion-list fix and its regex traps: fbq is not defined - the delay-JavaScript fix.
The tell that confirms it: your server-side events count normally while the browser PageView does not. Clients call that impossible. It is not - they are two independent delivery paths.
typeof window.fbq returns undefined, and there is a live ReferenceError: fbq is not defined. Then count the scripts whose type is text/rocketlazyloadscript - if there are any, the plugin is delaying them. Do it logged out - caching plugins skip optimisation for logged-in admins, so an admin session gives you a false pass.fbevents.js, connect.facebook.net, fbq, plus a keyword from whatever script calls the pixel. Write fbq, not fbq( - the exclusions are PCRE and an unescaped bracket breaks the pattern silently. Then clear and preload the cache and re-verify in a cold anonymous session.A hardcoded base code in the theme AND a GTM tag AND a platform integration all loading the same pixel. Symptom is usually the opposite of silence - events fire 2-3x per action, purchases double-count, and audiences pollute.
fbq.getState().pixels (Meta Pixel Helper reads JavaScript state, not the wire - it can show green while nothing reaches /tr, so treat it as a hint, never as proof). More than one init of the same ID, or multiple IDs you don't recognize = consolidate before anything else.The tag exists, but its trigger waits for a dataLayer event (purchase, add_to_cart) that the site never pushes - a theme update or checkout change silently broke the push. The tag is "active" and fires exactly never.
PayPal, financing providers, bank-redirect payments: the buyer leaves your site to pay and often never returns to the thank-you page where the Purchase pixel lives. The pixel works perfectly - for the customers who come back. The rest vanish.
Embedded checkouts (Eventbrite, Calendly, some booking and payment widgets) run in a cross-origin iframe. Your page's pixel physically cannot see events inside it.
Some meaningful share of your visitors block facebook.com/tr outright - ad blockers and Firefox’s strict tracking protection stop the request itself. Safari’s ITP is a different problem and belongs in a different bucket: it does not block the request, it caps cookie and script-writable storage lifetime, so the request still fires but match quality and attribution windows degrade. No client-side fix exists. This is exactly what the Conversions API is for: the same event, sent server-to-server, deduplicated against the browser event via a shared event_id.
Don't trust any dashboard that says "connected". Trace one real event end to end - browser network tab, GTM Preview, Events Manager Test Events - and compare monthly totals against your backend's paid orders. The number that matches reality is your backend. Everything else is a suspect.
Numbers still don't add up? I do this for a living: tracking audits that reconcile the ad platform, GA4 and your backend, then server-side fixes with proper deduplication. Send me your two numbers below and I will tell you which of the causes above is yours, no charge. If the gap is under about 10%, you probably do not need me, and I will say so.
or email work@rytisbalys.com · every rated job 5.0 · verify on Upwork
"Installed" only means the base code is present. Firing means the browser sends requests to facebook.com/tr. Open DevTools, Network, filter by tr and act on the site. No requests means it is not firing, whatever the tag manager or Pixel Helper says.
The usual cause on WordPress is a caching plugin's delay-JavaScript option. It postpones fbq until the first interaction, while the script that calls fbq is not delayed, so the call throws ReferenceError: fbq is not defined and the PageView never fires. Testing hides it, because moving your mouse is exactly what releases the delayed scripts. Verify on a cold anonymous load with no interaction, and while logged out.
Yes. They are two independent delivery paths. Server-side events go straight from your backend to Meta and are unaffected by delayed scripts, ad blockers or consent wiring in the browser, so one can work perfectly while the other sends nothing.
No. ITP does not block the request to facebook.com/tr. It limits cookie and script-writable storage lifetime, which degrades match quality and attribution windows. Ad blockers and Firefox's strict tracking protection are what block the request itself.