WooCommerce Checkout Block Blank? Causes & Fix
Your checkout page loads, but where the form should be there are only empty grey boxes — no address fields, no payment methods, no Place order button. The page isn't broken; the checkout app never started. Here's how to find what stopped it.
Last updated: 16 Jul 2026 · ~7 min read
The most common cause is a JavaScript optimiser — Jetpack Boost, WP Rocket, LiteSpeed, Autoptimize — concatenating, minifying or delaying WooCommerce's checkout block bundle, so the React app never mounts and you're left staring at the placeholders. Turn off JS concatenation, minification and delay, then clear every cache and reload the checkout.
What the grey boxes actually are
The WooCommerce Checkout block isn't plain HTML. WooCommerce prints skeleton placeholders server-side, then a JavaScript app takes over, calls the Store API at /wp-json/wc/store/v1/cart, and builds the real form in the browser. The grey boxes are those placeholders. Seeing them means the HTML arrived fine and the JavaScript never finished.
That's why it looks so alarming and is usually so shallow: nothing is wrong with your cart, your orders or your gateway. One script failed to load or threw before the app mounted. To the customer it's a dead page — they can't buy, and they leave without telling you.
The most common causes (most likely first)
- A JS optimiser is concatenating, minifying or delaying the block bundleThe checkout works with the optimiser off and dies with it on. Jetpack Boost's "Concatenate JS", WP Rocket's "Combine JavaScript files" / "Delay JavaScript execution", LiteSpeed's JS combine, and Autoptimize all do this. Merging the bundle breaks WordPress's script dependency order, so
wp.elementor the blocks registry isn't there when checkout asks for it. By far the #1 cause. - Another plugin or the theme throws a JS error before checkout mountsThe browser console shows one red
Uncaught TypeErrororUncaught ReferenceErrorfrom a file that isn't WooCommerce — a sticky-cart, currency switcher, popup or analytics script. One uncaught error halts the rest of that execution, and checkout never gets its turn. - A cached page or CDN is serving asset URLs that no longer existThe Network tab shows 404s on WooCommerce block script files. After a WooCommerce update the bundle filenames change; cached HTML (or a stale CDN copy) still points at the deleted ones. Broke immediately after an update, fixes itself when you purge everything.
- The Store API is blocked, so checkout has no cart to renderThe Network tab shows the request to
/wp-json/wc/store/v1/cartreturning 403, 401 or an HTML error page instead of JSON. A security plugin, WAF or a REST-API-disabling plugin is filtering it. Often paired with a spinner rather than fully grey boxes — check which you're seeing. - An extension's checkout integration is incompatible with your WooCommerce versionThe console error names a file inside a specific extension's folder and mentions checkout, blocks or a registry. Common after updating either WooCommerce or the extension, and typically a payment, shipping or checkout-field add-on that registers itself into the block.
Where to look first
- Open the browser console on the broken checkout (F12 → Console) and reload. A red error naming an optimiser's merged file, or a plugin's script, points straight at cause 1 or 2.
- Turn off JS concatenation, combine, minify and delay in your optimiser, purge every cache, then reload in a private window. Checkout comes back? That's cause 1 — re-enable the options one at a time to find which one does it, or exclude the checkout page entirely.
- Check the Network tab for red 404s on script files. Any 404 on a WooCommerce block asset is cause 3 — purge the page cache and the CDN, and it should return.
- Look at the request to
wc/store/v1/cartin the Network tab. Non-200, or HTML where JSON should be? That's cause 4 — allow the Store API through your security plugin or WAF. - Still blank with all optimisation off? Deactivate checkout-related extensions one at a time — the console error usually names the folder for you (cause 5).
Which script is killing your checkout?
Finding it by hand means toggling optimiser settings, purging caches and re-testing checkout in a private window, over and over, while nobody can buy. DiagnosticIQ's free dashboard watches the buying funnel and flags the moment the checkout page stops working, and Checkout Guard adds checkout-lane depth to the pinpoint diagnosis — so a blank block gets named as a blank block, not left for a customer to report. Either way, the fix above stands on its own.
Get the free plugin →Made by Prima Digital — the team behind this guide. Free forever; no card to install.
How to know you fixed it
In a private window, load the checkout with a product in the cart — the real address and payment fields should render, and the Place order button should be clickable with no red errors in the console.
Frequently asked
Are my orders or cart data affected?
No. This is a front-end rendering failure. Existing orders, cart contents and gateway settings are untouched.
How do I take payments while I debug this?
Edit the checkout page, replace the Checkout block with the [woocommerce_checkout] shortcode, and update. The classic checkout doesn't depend on the block bundle, so it will render immediately. Switch back once the script issue is fixed.
Should I just delete and re-add the Checkout block?
It rarely helps. The block markup is arriving fine — the JavaScript is what's failing. Re-adding the block only fixes it if the page content itself was genuinely corrupted.
Why does it work for me as admin but not for customers?
Most optimisers and page caches are bypassed for logged-in admins. That's a strong hint you're looking at cause 1 or 3 — always test in a private window.