You switched your WooCommerce store to Block Checkout — faster page, modern UI, Gutenberg-native. What nobody mentioned: every GTM DataLayer purchase event you were tracking is now silent. No purchase fires. No GA4 conversion. No Facebook CAPI signal. Just a clean-looking checkout page that has quietly stopped reporting revenue to every platform you use to make campaign decisions.
This isn’t a GTM misconfiguration. It’s not a plugin conflict. It’s a fundamental architecture problem — and WooCommerce 8.3+ set Block Checkout as the default for all new installations, making this the most common silent tracking failure in WordPress ecommerce right now.
Why Block Checkout Breaks GTM DataLayer Events
Classic WooCommerce checkout is PHP-rendered. When an order completes, WordPress fires server-side hooks — woocommerce_thankyou and woocommerce_checkout_order_processed — that trigger page renders, thank-you page loads, and the DataLayer events your GTM setup depends on. Every major GTM DataLayer plugin was built against these hooks. They’ve been stable for years.
Block Checkout is a React application. It runs in the browser, not on the server. The PHP hooks that Classic Checkout fires on order completion do not fire in Block Checkout. The React component handles the entire checkout flow — and it doesn’t speak to GTM’s DataLayer the same way PHP hooks do.
GTM4WP has 500,000+ active installs — the largest GTM DataLayer fleet for WordPress — and it was built on those PHP hooks. Switching to Block Checkout mid-store doesn’t trigger a warning, doesn’t throw a visible error, and doesn’t send you a notification. Your tracking just stops. Silently.
The Detection Delay That Makes This Dangerous
This isn’t a failure you spot immediately. Stores typically discover Block Checkout tracking failure 3–7 days after migration — by which point GA4 has already recorded a week of missing purchase events, and your ad platforms have already used that incomplete data to adjust bidding strategies, evaluate campaign performance, and make budget decisions.
The 3–7 day lag happens because most store owners check GA4 periodically, not daily. And when they do check, dropping conversions look like a traffic problem, a campaign problem, or seasonality — not a checkout architecture problem. The tracking failure disguises itself as a marketing problem. Teams spend days or weeks optimising ads against data that doesn’t reflect reality.
This is why 70% of ecommerce stores have broken or incomplete tracking configurations (Conversios, 2025) — not because store owners are careless, but because the breakages are silent and the detection signals are ambiguous.
You may be interested in: Your WooCommerce CLV Is Fiction Because GA4 Only Sees 60% of Customers
How to Confirm Your Purchase Events Are Broken
Three checks. Run all three.
Check 1: GTM Preview Mode. Open Tag Assistant and Preview mode. Complete a real test transaction through your Block Checkout. Watch the DataLayer panel. If no purchase event appears on the order confirmation step, Block Checkout has broken your tracking.
Check 2: GA4 Realtime. Complete a test purchase and watch Realtime > Events. If purchase doesn’t appear, the event isn’t reaching GA4 — either because GTM didn’t fire it, or because the tag fired but failed to send.
Check 3: Date comparison. In GA4 Explorations, compare purchase event counts for the week before and the week after your Block Checkout switch. A drop that correlates exactly with the migration date is the signature of hook failure.
If Check 1 fails — no DataLayer event — the problem is at the GTM layer and the fix is there, not in GA4.
The Two Fix Paths
There are two architecturally different ways to restore purchase event tracking with Block Checkout.
Path 1: Update Your GTM Plugin to Block-Aware Versions
GTM4WP has been adding Block Checkout support incrementally. The specific version that added Block-compatible purchase events is documented in the plugin changelog — check it, update, and test end-to-end. Don’t assume an update restores all tracking; test each funnel step explicitly in GTM Preview Mode after updating.
The limitation of this path: you’re still relying on browser-side JavaScript to capture and fire purchase events. That means ad blockers, browser extensions, and network interruptions can still drop events before they reach GA4 or any ad platform. Block Checkout support in the plugin fixes the hook problem — it doesn’t fix client-side data loss.
Path 2: Move Purchase Tracking Server-Side
Server-side tracking captures the purchase event at the server level — after WooCommerce confirms the order — and sends it directly to GA4, Facebook CAPI, Google Ads, and any other destination. The checkout UI is irrelevant. Classic Checkout, Block Checkout, headless checkout — the server fires regardless.
This is the architecture that removes checkout UI changes from the tracking dependency chain entirely. When WooCommerce updates its checkout again — and it will — your purchase events don’t break because they were never listening to the browser-side render in the first place.
You may be interested in: GTM Server-Side Costs Are Out of Control: What Small WooCommerce Stores Actually Pay
Why This Will Happen Again
WooCommerce is actively evolving. The Block-based editor, Gutenberg-native components, and React-rendered checkout are the direction of the platform. Classic Checkout will eventually be deprecated. Every store that stays plugin-dependent for GTM tracking is one major WooCommerce update away from another silent breakage.
GTM was designed before React-rendered checkout was a concept. Its DataLayer model assumes PHP-rendered pages with discrete load events — the kind of event Classic Checkout has always produced. Block Checkout’s JavaScript-rendered flow doesn’t match that model cleanly, which is why plugin support has to be retrofitted with each major WooCommerce release.
GTM isn’t broken. It’s structurally mismatched with where WooCommerce is going. Patching that mismatch each release cycle is technically workable — but it puts your revenue data at risk every time WooCommerce ships a major update before your GTM plugin catches up.
What Seresa Does Differently
The Transmute Engine™ captures purchase events server-side, directly from WooCommerce order hooks that fire at the database level — not at the checkout UI level. When your checkout switches from Classic to Block, from Block to headless, or to any future checkout architecture WooCommerce introduces, the Transmute Engine keeps firing. It doesn’t listen to the browser. It listens to the order.
That signal goes simultaneously to GA4, Facebook CAPI, Google Ads Enhanced Conversions, BigQuery, and any other configured destination — from a first-party subdomain that ad blockers can’t reach. The checkout migration that breaks GTM-dependent stores doesn’t register as an event in the Transmute Engine at all.
Key Takeaways
- Block Checkout doesn’t fire the PHP hooks GTM DataLayer plugins were built on. This is by architecture, not by accident.
- GTM4WP has 500,000+ installs directly affected. If you’re using it and you’ve switched to Block Checkout, test your purchase events now.
- Detection takes 3–7 days on average. Bad data compounds daily before most teams notice the drop.
- Plugin updates can restore hook compatibility — but can’t fix the underlying client-side data loss problem.
- Server-side tracking removes the checkout UI from the tracking dependency chain entirely.
WooCommerce Block Checkout is a React-rendered application. It does not fire the PHP hooks (woocommerce_thankyou, woocommerce_checkout_order_processed) that GTM DataLayer plugins like GTM4WP rely on to push purchase events. When you switch to Block Checkout, those hooks never fire — so GTM never receives the data, and purchase events disappear from GA4 and any platform using them.
GTM4WP has partial support for Block Checkout, but it requires specific configuration and may not cover all purchase event scenarios. Check the GTM4WP changelog and documentation for the exact version that added Block support, and test your checkout funnel end-to-end after any update.
Open GTM Preview mode and complete a test transaction. If no purchase dataLayer event fires on the order confirmation step, Block Checkout has broken your tracking. Also check GA4 Realtime — if purchase events stop appearing after a checkout change, the hook failure is the most likely cause.
The two reliable paths are: (1) use a GTM plugin that has been updated with native Block Checkout support and Block-specific event listeners, or (2) move purchase event tracking server-side, where it runs independently of the checkout UI and fires reliably regardless of whether Classic or Block Checkout is in use.
Your Block Checkout migration wasn’t the problem. Not knowing what it does to your tracking — that’s the problem that costs you real money. Run the three checks above today. If purchase events aren’t firing, fix the architecture before next week’s campaign report tells you a story that isn’t true.