WooCommerce Tracking Broken After Blocks? 7 Proven Fixes

You migrated the cart or checkout to blocks, the store kept taking orders, and everything looked fine. Three weeks later your ad platform is reporting a fraction of the conversions your WooCommerce dashboard shows. This is what WooCommerce tracking broken by the blocks looks like, why nothing warned you, and how to fix it properly.

Why WooCommerce tracking broken is so easy to miss

The classic cart and checkout were rendered by PHP and wired up with jQuery. When somebody added an item, WooCommerce fired a jQuery event called added_to_cart. Every tracking plugin on the market listened for it.

The blocks are React. They do not use jQuery, and they do not emit those events. They emit their own, through the Store API.

So a plugin listening for added_to_cart now waits forever. It does not error, because waiting for an event that never arrives is not an error — it is just waiting. Your site is fast, your orders are fine, and your measurement is gone.

Check for WooCommerce tracking broken in five minutes

Do not read a compatibility list. Watch the request.

Any step where nothing appears is the step where your WooCommerce tracking broken. That is the whole diagnosis, and it is more reliable than any vendor’s claim.

# Does the store emit Store API events at all?
curl -sS https://yourstore.com/wp-json/wc/store/v1/cart | head -c 200

# Which tracking plugins are active
wp plugin list --status=active --format=table | grep -iE 'pixel|analytics|tag|track|gtm'

The seven causes of WooCommerce tracking broken, in order

1. The plugin listens for jQuery events

The big one, and the cause of most WooCommerce tracking broken reports. Check the plugin’s own JavaScript for the old hooks.

grep -rn "added_to_cart\|removed_from_cart\|checkout_init\|updated_cart_totals" \
  wp-content/plugins/your-tracking-plugin/

Hits mean the plugin was written for the classic cart. Check for an update; if none exists, the plugin needs replacing, not configuring.

2. The plugin reads the thank-you page and nothing else

Some setups only fire a purchase event, by injecting script into the order-received page. Those usually survive the migration — the thank-you page is still PHP. If your purchase event works but add-to-cart does not, this is you, and only half your funnel is missing.

3. Consent mode is blocking it

Worth ruling out before blaming the blocks. If a consent banner gates your tags and the banner’s integration changed, WooCommerce tracking broken has nothing to do with the migration at all.

# Accept cookies, then retest. If events appear, it was consent.

4. Google Tag Manager triggers on the old events

GTM containers frequently use custom triggers bound to jQuery events pushed by WooCommerce. Those pushes stopped. The tags are fine; their triggers never fire.

Open GTM Preview on your live store and add to cart. If no trigger lights up, the container needs rebuilding against the Store API events rather than the legacy ones.

5. The data layer is empty

Related but distinct: the tag fires, and sends nothing useful. Product ID, price and currency came from a data layer the classic templates populated. The blocks populate a different one.

# In the browser console, on a product page
window.dataLayer
# Then add to cart and run it again — did anything get pushed?

6. A caching layer is serving a stale thank-you page

The order-received page must never be cached. If it is, one shopper’s purchase event can fire for the next visitor, or not at all. Our note on what to cache in a store covers the pages that must always be excluded.

7. Two tracking plugins fighting

Common after a migration, because somebody installs a second plugin to fix the first. Now you have duplicate events, or two plugins each assuming they own the data layer. Deactivate one and retest before adding anything.

Fixing it properly

There are three levels of fix for WooCommerce tracking broken, and the cheap one is not always the right one.

If WooCommerce tracking broken has already cost you a month of attribution, the last row is worth the conversation. Server-side events fire from PHP when the order is created — no browser, no jQuery, no blocker, no consent-banner race.

# The hook that fires once, server-side, when an order is placed
add_action( 'woocommerce_checkout_order_created', function ( $order ) {
    // $order->get_total(), get_items(), get_billing_email() — all available
    // Send to your platform's server-side endpoint here.
}, 10, 1 );

That hook fires for block checkouts and classic ones identically, which is the point. It is the only tracking on a WooCommerce store that a front-end migration cannot silently break.

Listening to the Store API directly

If you maintain your own tracking snippet, repairing WooCommerce tracking broken is not hard — you swap which events you subscribe to.

// Classic — no longer fires under the blocks
jQuery( document.body ).on( 'added_to_cart', function () { /* ... */ } );

// Blocks — the store's own event bus
window.addEventListener( 'wc-blocks_added_to_cart', function ( e ) {
    // e.detail carries the cart state
} );

Verify names against the current WooCommerce documentation rather than a blog post, including this one — the event surface is still settling and woocommerce.com is the source of truth.

If you have never owned this code, that is a reason to prefer a maintained plugin or a server-side setup. A tracking snippet nobody understands is how WooCommerce tracking broken goes unnoticed for a quarter, and our note on building versus buying applies here as much as anywhere.

What to do about the lost weeks

You cannot recover the events WooCommerce tracking broken never fired. You can stop the gap from corrupting your decisions.

# Real orders for the period, from the store itself
wp db query "SELECT DATE(date_created_gmt) AS day, COUNT(*) AS orders, SUM(total_amount) AS revenue
  FROM wp_wc_orders
  WHERE status IN ('wc-completed','wc-processing')
    AND date_created_gmt > '2026-08-01'
  GROUP BY day ORDER BY day;"

That query is also the fastest way to prove WooCommerce tracking broken rather than sales falling — if orders held steady while reported conversions collapsed, you have a measurement fault, not a business one. Those are very different meetings.

A worked example: five weeks, £11,000 of spend

The shape of this is consistent enough to be worth walking through once.

A store selling homeware migrated its cart and checkout to blocks on a Tuesday. Orders continued normally. Nobody looked at the ad account closely for a fortnight, because nothing suggested they should.

What had actually happened: the store’s pixel plugin listened for added_to_cart and woocommerce_checkout_init. Both vanished. The purchase event survived, because it was injected into the order-received page by a different mechanism. So the platform could still see sales — it simply could not see anything that led to them.

That partial failure is the worst version of WooCommerce tracking broken, and it is the most common. A total blackout gets noticed in days because the numbers go to zero. A funnel missing its top two steps just looks like a campaign that suddenly stopped working, so the response is usually to change the campaign.

Five weeks later the audit took twenty minutes: private window, Network tab, add to cart, nothing. The repair was a plugin swap and a GTM rebuild, about half a day. The £11,000 spent while the algorithm optimised on a third of the funnel is not recoverable, and no amount of later accuracy buys it back.

Which events you actually need

Not every event is worth chasing. If you are rebuilding after WooCommerce tracking broken, these four earn their place and the rest are optional.

Fixing the top three is most of the value. Chasing all eleven standard ecommerce events is how a half-day repair becomes a fortnight, and the four that matter are the four that were probably working before. Our post on what actually moves checkout conversion makes the same argument about where to spend effort.

Note the fourth row. View-item fires on the product page, which is still a normal PHP template — so it usually survives. If that one also stopped, the cause is not the blocks and you should look at consent or a caching layer instead. Knowing which events are even capable of breaking narrows a WooCommerce tracking broken diagnosis considerably.

Where this goes wrong

The pattern is consistent: every one of these is invisible from the admin. Nothing in WordPress will ever tell you your WooCommerce tracking broken, which is why it belongs on a monthly checklist rather than in anybody’s memory.

Making it not happen again

Four habits keep WooCommerce tracking broken from recurring, and none of them is expensive.

The monthly comparison is the one that matters most. Two numbers — orders in WooCommerce, conversions in the ad platform — and a rough agreement between them. When they diverge, you have caught WooCommerce tracking broken in week one instead of week five.

Consent, and why it muddies every diagnosis

One complication deserves its own section, because it produces symptoms identical to WooCommerce tracking broken and has nothing to do with the blocks.

If your store shows a consent banner, most tags are held until somebody accepts. That is correct behaviour and, in the EU and UK, a legal requirement. It also means your reported conversions were always a subset of your real ones — typically somewhere between half and three quarters, depending on the audience.

So when conversions fall after a migration, there are two candidate explanations and they need separating before anyone fixes anything. Either the events stopped firing, or the consent integration changed and fewer people are now being counted. The test is the same five-minute one: accept cookies explicitly, then watch the network tab. If the events appear, you were looking at consent, not at WooCommerce tracking broken.

Worth knowing the order, too. A consent platform that loads after your tags can block the first pageview and allow everything after it, which produces a partial loss that looks exactly like a broken funnel. If your numbers fell by a stable proportion rather than a step change, suspect consent first.

Common questions about WooCommerce tracking broken

Is Google Analytics affected too?

Yes, in exactly the same way. GA4 ecommerce events come from the same data layer the classic templates populated. If add-to-cart stopped in your ad pixel, check GA4 as well — it is usually the same fault.

Can I just go back to the classic checkout?

You can, and it will restore the old events. It is a reasonable emergency measure while you sort the tracking out. It is not a plan, because the direction of travel has not changed — see our checkout blocks audit for the fuller decision.

Why did WooCommerce not warn me?

Because from WordPress’s point of view nothing is wrong. Orders are being created, the checkout works, no PHP error occurs. WooCommerce tracking broken is a fault in something WordPress has no visibility of.

Is server-side tracking hard to set up?

A day or two for a competent developer, most of it in testing deduplication. The value is that it is the last time you do it — a browser or block change cannot reach a server-side event.

How much revenue does this actually cost?

Depends entirely on how much you spend on ads. If you are not advertising, this is a reporting annoyance. If you are, a month of WooCommerce tracking broken means a month of a bidding algorithm optimising against bad data, and that compounds.

Does this affect subscriptions or bookings too?

Yes, and usually worse, because recurring revenue is measured over months rather than on the day. A renewal that never reports looks like churn in your dashboard while the money keeps arriving in the bank. If you sell subscriptions, verify the renewal event specifically — it fires on a different path from the first purchase and is frequently missed when somebody fixes the obvious one.

My developer says it is fixed. How do I check?

Open a private window, DevTools on Network, and place a test order. You should see a request at add-to-cart, at checkout, and at purchase. If you can see all three yourself, it is fixed — no trust required.