Guide
Meta pixel not firing at checkout
PageView looks fine and Purchase is missing. Hosted checkout is the usual reason. How to prove it, and what a scanner can and cannot observe.
Last reviewed September 2026.
The usual picture
Meta Events Manager shows PageView. Purchase is empty or thinner than Shopify or WooCommerce orders. Ad spend continues. The pixel is “installed”.
1. PageView is not Purchase
On a product page, filter for facebook.com/tr (or the current Meta collect host) and read the event name. PageView or ViewContent only proves the library can send something. Purchase has to appear on the page where purchase happens.
2. Hosted checkout is the common reason
Shopify hosted checkout, and many gateway redirects, run on a domain you do not control. A scanner loading your storefront will never see those pages. Reporting them as broken would be a lie; they are unobservable.
If Purchase is configured only inside that hosted flow, the gap is where the event lives, not a silent pixel on the cart. What the scanner cannot see lists this first.
3. Thank-you pages you do control
Some setups fire Purchase when the customer returns. View source on that URL. Confirm the pixel snippet is present, then confirm the collect request carries Purchase and a value, not a second PageView. A duplicate PageView will keep Events Manager looking “alive”.
4. Consent and pixel helpers
A consent banner that never grants ads will stop Purchase while leaving a stub library in the page. That is a blocked tag, not a missing one.Consent mode blocking analytics.
Official pixel helpers light up when the library is present. They do not prove Purchase left. Use the network panel for the collect request.
Confirm it with a scan
Four page types, a real browser, no account. A scan will not fix the tag. It will tell you whether it is firing now.