WooCommerce Cart & Checkout Blocks Broken? Here's the Fix

If your WooCommerce cart or checkout page suddenly went blank, started throwing a red "something went wrong" box, or reverted to an ugly unstyled form after an update, you're almost certainly running into the new block-based Cart and Checkout — not the old [woocommerce_cart] / [woocommerce_checkout] shortcodes. WooCommerce has been pushing every store toward these blocks since version 8.3, and as of the 9.x releases the classic shortcode templates are being phased out entirely. If your theme, a plugin, or some custom code was built for the old checkout, this is where it breaks.

Symptom: what a broken checkout block actually looks like

This isn't one bug, it's a family of them. Depending on what's conflicting, you'll see one of these:

• The checkout page is completely blank below the header, no error visible at all.
• A message reading "There was an error loading the content" or a red box with a generic error string.
• The cart or checkout loads, but payment methods never appear (spinner runs forever).
• Fields render but look completely unstyled — no theme CSS applied, plain HTML boxes.
• Coupon field, shipping calculator, or order notes disappeared after upgrading a plugin that used to hook into the old checkout form.

Open the browser console (F12 → Console) on the affected page first. Almost every one of these cases throws a JavaScript error you can read directly — that's your fastest path to the actual cause.

Cause 1: A plugin or theme still hooks into the legacy checkout form

The shortcode-based checkout fired a long list of PHP action hooks — woocommerce_checkout_before_customer_details, woocommerce_review_order_after_submit, and so on — that plugins used to inject custom fields, trust badges, or upsells. The block-based checkout does not fire most of these. If a plugin (or a snippet in your child theme's functions.php) adds content this way, it silently does nothing on the new checkout, or in some cases it throws a fatal error trying to output HTML into a page structure that no longer exists.

Fix:

1. Deactivate plugins one at a time (start with anything that adds custom checkout fields, trust seals, or gift options) and reload the checkout page after each one.
2. Check your theme's functions.php and any mu-plugins for calls to add_action('woocommerce_checkout_...') — these are the usual suspects.
3. If you find the culprit, don't just delete it. Most well-maintained plugins now ship a Checkout Block-compatible version, or the developer has documented a block filter to replace the old hook. Update first before removing anything.

Cause 2: The page still has the old shortcode instead of the block

If you migrated from an older WooCommerce version, your Cart and Checkout pages might still literally contain [woocommerce_cart] and [woocommerce_checkout] in the page content, while WooCommerce's settings expect the block version. Recent WooCommerce releases have started removing the classic shortcode template files from the shipped code — when that happens, the shortcode renders nothing, or falls back to a broken bare-bones form.

Fix:

1. Go to Pages in wp-admin, open your Cart and Checkout pages, and check the content in the block editor.
2. If you see the shortcode text sitting in a Classic block, remove it and insert the actual WooCommerce Cart and WooCommerce Checkout blocks from the block inserter instead.
3. Alternatively, under WooCommerce → Settings → Advanced → Page setup, use the "Add checkout block" / "Add cart block" prompt WooCommerce shows automatically if it detects the shortcode is still in use.

Keep a staging copy before you touch these pages — if you have custom CSS targeting the old shortcode's markup (classes like .woocommerce-checkout vs the block's .wp-block-woocommerce-checkout), your styling will need updating too.

Cause 3: Caching or a page builder is stripping block markup

The Cart and Checkout blocks render most of their content client-side via the WooCommerce Store API (a REST endpoint under /wp-json/wc/store/v1/). If a caching plugin serves a fully static HTML snapshot of these pages, or a security plugin blocks REST API requests from unauthenticated visitors, the block's initial server-rendered shell loads but never hydrates — you get a blank space where the form should be.

Fix:

• Exclude /cart/, /checkout/, and /my-account/ from every layer of caching: the WordPress caching plugin, LiteSpeed Cache server-level cache, and Cloudflare's page rules if you're using it.
• In your security plugin (Wordfence, Sucuri, etc.), confirm requests to wp-json/wc/store/* aren't being blocked. Test directly by visiting https://yourdomain.com/wp-json/wc/store/v1/cart while logged out — you should get a JSON response, not a 403 or a firewall block page.
• If you're on Cloudflare, check under Caching → Configuration that "Cache Level" isn't set to bypass-then-cache in a way that catches the REST endpoint. A quick test: purge cache, load checkout in an incognito window, and watch the Network tab for the store API calls — they should return 200, not cached 304s with stale data.

Cause 4: A page builder or Elementor template overrides the block container

If your Checkout page was built with Elementor, Divi, or a similar builder before you migrated to the blocks, the page content type may still be set to the builder's canvas template rather than the default WordPress content area the WooCommerce blocks need to render into. This shows up as the checkout block simply not appearing at all, even though it's technically inserted in the page.

Fix: Edit the Cart/Checkout page, switch the page template back to "Default template" (or your theme's standard page template, not a builder canvas/blank template), and re-add the WooCommerce blocks in the native WordPress block editor rather than inside the builder's own widget area.

Cause 5: An outdated WooCommerce Blocks version bundled separately

Some older setups still have the standalone WooCommerce Blocks plugin installed from before it was merged into WooCommerce core. Running that alongside a current WooCommerce version causes duplicate block registrations — you'll see a console error like Block "woocommerce/cart" is already registered.

Fix: Deactivate and delete the standalone WooCommerce Blocks plugin. Everything it provided has been part of WooCommerce core since version 7.2, so you don't lose functionality — you just remove the conflict.

Quick diagnostic table

Prevention: don't get caught by this again

• Before any WooCommerce major update, spin up a staging copy (Getwebup's cPanel WordPress Toolkit clone feature makes this a couple of clicks) and test checkout end to end there first.
• Read the WooCommerce changelog for "Blocks" entries before updating — deprecation of the shortcode fallback is called out explicitly when it happens.
• Audit any custom checkout code yearly. If you paid a developer for custom checkout fields years ago, check whether it's still hook-based or has been rebuilt for blocks.
• Keep your caching exclusions for /cart/, /checkout/, and /my-account/ as a standing rule any time you switch caching plugins.

If you've gone through all five causes and checkout is still broken, it's usually faster to open a support ticket with your browser console errors and a screen recording attached than to keep guessing plugin by plugin — that context alone usually narrows it down in minutes.