WooCommerce Checkout Block vs Classic Shortcode: What to Check

WooCommerce supports the modern Checkout block and the legacy [woocommerce_checkout] shortcode. New installations have used Cart and Checkout blocks by default since WooCommerce 8.3, while many established stores still rely on classic checkout because of existing themes, extensions, templates, and custom code.

Both approaches can be valid. The important questions are which one is actually present on the page assigned as Checkout, whether the store’s extensions support it, and whether the public journey renders and behaves as intended.

1. Open WooCommerce → Settings → Advanced and note the assigned Checkout page.
2. Edit that exact page.
3. Open List View in the block editor.
4. Look for a Checkout block or a Shortcode/Classic Shortcode block containing [woocommerce_checkout].
5. Check whether a page builder or checkout extension intentionally replaces the content or template.

Do not assume the editor content tells the whole story if the active theme or extension replaces the checkout template. Review the installed stack and public rendered page together.

• Rendering: Blocks use block-based components and Store API interactions; classic checkout uses shortcode-driven templates and established WooCommerce hooks.
• Customization: Block checkout is edited through block settings and supported block extensibility. Classic checkout commonly uses PHP hooks, template overrides, and extensions designed for the shortcode flow.
• Compatibility: An extension can support both, only classic, or only a particular block integration. Verify its current documentation.
• Debugging: Browser and network evidence may differ. Record whether a failure involves Store API requests, classic AJAX, a gateway iframe, or an extension-specific request.

Regardless of checkout type, confirm:

• The page is published and assigned as Checkout.
• Cart and Checkout use separate destinations.
• The URL is served over the intended HTTPS hostname.
• A valid product can reach checkout through the cart journey.
• Expected shipping and payment methods are eligible for the test context.
• The browser shows no relevant JavaScript, request, or mixed-content failure.
• Caching and optimization exclude session-sensitive commerce behavior.
• A controlled end-to-end test is planned after local diagnostics.

A switch can change field rendering, extension integrations, analytics events, gateway behavior, styling, validation, and custom hooks. Create a backup and use staging that mirrors production.

1. Inventory every checkout-related extension and customization.
2. Confirm documented support for the target checkout type.
3. Transform or replace the checkout content on staging.
4. Test guest and account checkout, addresses, shipping, taxes, coupons, payment test modes, order creation, emails, analytics, and mobile layout.
5. Document a rollback path before changing production.

Cobalt Checkout Diagnostics detects block, classic, and mixed page setups and records the finding with the rest of the local configuration snapshot. Use it before and after a planned change to confirm which setup WooCommerce sees and whether the assigned pages remain renderable.

The check does not determine whether every third-party checkout customization is compatible. Review each extension and complete controlled functional testing.

Record the current checkout setup →