WooCommerce Breaks Purchase Tracking in Four Specific Places

WooCommerce stores fail at conversion tracking in a particular way: the store works perfectly. Orders are taken, payments clear, confirmation emails go out, the customer sees a receipt. Only the tracking is missing, and because every human-facing part of the flow is fine, nobody discovers it until somebody asks why the ad platform shows a quarter of the sales the store database does.

WordPress is the reason this is more common here than on hosted platforms. A WooCommerce store is an assembly of a theme, a stack of plugins, a caching layer, a payment gateway and sometimes a page builder, each of which can interfere with the moment a purchase tag is supposed to fire. The good news is that there are only about four places it actually goes wrong, and they produce different symptoms.

First, establish what kind of broken you have

Before touching anything, place a test order with the gateway in test mode and watch what happens. The answer to one question narrows this immediately:

• No purchase event at all, ever. Caching, a custom thank-you URL, or the tag is not on the confirmation page. Sections one to three.
• Purchase fires, but with no value or a zero value. The tag is firing but cannot read the order. Usually a blocks or data-source problem, section four, and conversion values arriving as zero goes deeper on the reporting side of it.
• Purchase fires more than once per order. Either the customer reloaded the receipt, or you have the same tag installed twice, which happens more often than you would think.
• Some orders tracked, some not. Almost always caching, because caching is the only one of these that is intermittent by nature.

1. The order received page is being cached

This is the most common cause and the easiest to get wrong, because caching a WooCommerce store is both necessary and dangerous. WooCommerce documents that certain pages must be excluded from page caching, for the straightforward reason that they are personalised per visitor and per order.

The order received page is the extreme case. Its entire content — order number, line items, total — is specific to one order that has just happened. Serve a cached copy and at best the tag fires with somebody else’s order data; more often the dynamic block your tag reads from is not there at all.

What to exclude, as a minimum: cart, checkout, my account, and the order received or thank-you page. The detail people miss is matching child paths. The order received page is not /checkout/— it is a path underneath it, with the order ID and a key appended. An exclusion rule written as an exact match on /checkout/ will not cover it. Use a pattern that includes everything below checkout.

Also worth knowing that caching is not only your caching plugin. A CDN or reverse proxy in front of the site can cache independently, with its own rules, and so can some hosting platforms at the edge. Three layers of caching with two of them configured correctly still breaks the page. If you have excluded the right paths in the plugin and the problem persists, the next question is what sits in front of WordPress.

How to confirm it

Place two test orders a few minutes apart and compare the order received pages. If the second shows the first order’s details, or if the page source is identical between two different orders, it is cached. Response headers from your CDN will usually say so outright.

2. Checkout moved to blocks

WooCommerce now ships block-based cart and checkout alongside the older shortcode versions, and the two are genuinely different implementations rather than a styling change. The block checkout is a JavaScript application that talks to WooCommerce’s Store API, where the shortcode checkout was a conventional server-rendered form submission.

That matters for tracking because a great deal of tracking code was written against the old model. Template overrides, PHP hooks that fired at a particular point in the checkout render, and plugins that injected script into the classic form may simply not run in a block checkout. Nothing errors. The hook just never fires.

If a store’s tracking stopped working around the time somebody “modernised the checkout”, this is the first thing to check. Look at the checkout page in the editor: if it contains a Checkout block, you are on the new implementation, and any tracking that depends on classic hooks needs revisiting rather than debugging.

There is a caching interaction here too. Because block cart and checkout make requests to Store API endpoints, caching those API responses causes problems that look nothing like a caching issue from the outside. If you are on block checkout, make sure your caching rules exclude WooCommerce’s Store API routes as well as the page paths.

3. The thank-you page is not the thank-you page

Most purchase tracking is wired to WooCommerce’s default order received page, because that is the one page guaranteed to load exactly once after a successful payment. Plenty of things move it:

• A funnel or page-builder plugin that substitutes its own confirmation page.
• A payment gateway that returns the customer to a custom URL rather than the WooCommerce endpoint.
• A deliberate redirect to a bespoke upsell or onboarding page, added by whoever wanted a better post-purchase experience and not told the tracking was attached to the page they replaced.

The symptom is total: no purchase events at all, with everything else about the store healthy. The fix is to decide which page is now the single confirmation page and attach tracking to that, then verify it loads exactly once — some redirect chains pass through the original order received page briefly, which is enough for a tag to fire sometimes and not others.

Gateways that return the customer asynchronously deserve particular suspicion. If payment confirmation arrives at your server by webhook while the customer is sent somewhere else entirely, browser-side purchase tracking will miss orders structurally, and no amount of tag debugging fixes it. That is a case for server-side conversion reporting rather than a pixel, which is the territory covered in server-side versus browser-side tracking.

4. Add to cart never reloads the page

WooCommerce adds to cart over AJAX on archive and product pages by default. The cart updates, no navigation happens, and a tag configured to fire on page view never has a page view to fire on.

This is rarely what breaks a Purchase event, but it is routinely what breaks AddToCart and ViewContent, and those are the events feeding upper-funnel optimisation and remarketing audiences. A store with healthy Purchase numbers and almost no AddToCart events is usually this, not a tagging oversight.

The fix is event-based rather than pageview-based triggering: listen for the WooCommerce AJAX event or the cart fragment refresh and fire from there. The same class of problem, in a more general form, is covered in tracking single-page apps and route changes.

The thing that breaks it six months later

Everything above is a setup problem. There is a fifth category that is worse, because it arrives on a day nobody touched the tracking: WordPress and WooCommerce updates, and plugin updates underneath them.

A plugin that reads order data can stop reading it after a WooCommerce release changes where that data lives. A security or performance plugin update can introduce caching that was not there before. A theme update can drop the hook a snippet was attached to. None of these announce themselves as tracking changes in a changelog, which is why a WordPress update breaking your tracking is a recurring category rather than an unlucky one.

The practical consequence for an agency is that a WooCommerce store cannot be verified once and trusted. It has to be rechecked, because its surface area changes without you.

Verifying a fix properly

1. Put the gateway in test mode and place a genuine order through the real checkout flow, rather than triggering the tag manually. Manual triggers confirm the tag works, not that the store fires it.
2. Confirm the purchase event fires exactly once, and that the order value and order ID in the event match the order in WooCommerce.
3. Reload the confirmation page. If a second purchase event fires, you will double count every customer who refreshes, and some will.
4. Place a second order and check it is also tracked, which is what catches caching.
5. Check it again a week later. On WooCommerce specifically, this is the step that earns its keep.

Watching it after you walk away

The pattern across all of this is that a WooCommerce store stops recording conversions without stopping working, so the only reliable signal is the absence of data — and absence is exactly what nobody notices in a dashboard.

Taglertrechecks every connected Meta and Google Ads account every thirty minutes and emails you when conversions stop arriving or a conversion action’s status changes, which is the signal that a store-side change has broken something. It watches the ad accounts rather than the WordPress install, so it will tell you the day purchases stopped being recorded; it will not tell you which plugin update did it. That part is the checklist above.

If you want to see what is currently installed on a store before you start, our free tracking scan reads the public source and lists every pixel, tag and container with its real ID, which is a faster way to find a tag that was never there than reading a plugin list.