WooCommerce
WooCommerce blocks vs shortcodes in 2026
WooCommerce blocks vs shortcodes in 2026 is no longer a taste argument. Shortcodes still render a shop, a cart and a product. Blocks are where WooCommerce ships new cart, checkout, product collection and single-product template work. I am Alan Vo, a Gold Coast developer. I maintain WordPress shops that still have [products] in a page builder and others that run a full block theme. The job is to know which surfaces you can leave classic and which will strand you without gateways or editor support.
WooCommerce's overview of blocks is the feature list. This note is the production split I use: what I keep as shortcodes, what I move, and what I refuse to mix on one URL.
What "WooCommerce blocks vs shortcodes" actually means on a live shop
WooCommerce blocks vs shortcodes means two render pipelines. Shortcodes ([woocommerce_cart], [woocommerce_checkout], [products], [product_page], add-to-cart URLs) go through PHP templates in the theme (woocommerce/cart/cart.php and friends) or the plugin. Blocks go through the block editor, WooCommerce Blocks, Store API for cart and checkout, and block theme templates for the product and shop archives when you opt in.
Both can be live on one site. That is the trap. A block theme with a shortcode checkout, or an Elementor homepage with a block product collection that hydrates a second mini-cart, produces double scripts and split CSS.
In 2026 I treat these as default-block:
- Cart and checkout (if plugins allow). See how to migrate to WooCommerce block checkout.
- Product Collection block instead of
[products]loops on landing pages, when you want editor control and consistent query blocks. - Single product template parts when the merchant needs to reorder gallery, summary and related without PHP.
I treat these as keep-shortcode or keep-classic-templates until there is a reason:
- Legacy landing pages that already convert, built in a page builder, where
[products ids=""]is stable. - B2B or specialist flows whose plugin only patches classic templates.
- Email and PDF templates. Those were never shortcodes in the editor sense. Do not "block-ify" invoices.
The product page decision is its own template project: WooCommerce product page blocks that still sell.
Why shortcodes still exist and when they still win
Shortcodes still exist because millions of pages embed them and because classic themes still call the_content() with a checkout shortcode. They win when the surrounding page is not a block canvas. Elementor, old WPBakery, and some themes only give you a shortcode widget that works. Forcing a Checkout block into a builder widget is how hydration fails.
Shortcodes also win for tiny merchandising embeds: a single add-to-cart button in a blog post, a [products limit="4"] in an old campaign page you will not rebuild. Rewriting every historical page into Product Collection blocks is not SEO. It is unpaid archaeology.
Shortcodes lose when you need new WooCommerce checkout fields, Express payments, or a cart drawer that matches the Cart block. They lose when the classic template pack in a theme is abandoned and every Woo update fights cart.php overrides from 2019.
I also see "shortcode" used for page-builder Woo widgets that are neither. Those widgets often load both classic CSS and extra builder JS. They are the worst of both. Replace those with real blocks or real classic templates, not with another widget.
How I choose WooCommerce blocks vs shortcodes per template
I choose per template, not per brand slogan.
Shop and archives: if the theme is a block theme (or a hybrid with archive-product.html), I use the Product Collection / product catalog blocks so filters and sorting stay in the Woo stack. If the theme is classic with archive-product.php and a working AJAX filter plugin, I leave it until the filter plugin has a block equivalent.
PDP: classic content-single-product.php hooks (woocommerce_single_product_summary) still power a lot of real catalogues. I move to a block single product template when the merchant must swap content without a developer, and when gallery and add-to-cart blocks exist for their product types (variable, grouped, bundled).
Cart and checkout: blocks, with a plugin gate. This is the one place I push hard in 2026.
Cart fragments mini-cart versus Mini-Cart block: pick one. Classic fragments plus Mini-Cart block is duplicate requests.
Landing pages: Product Collection block on new pages. Shortcodes on old pages unless we are already in the editor rebuilding that URL.
I write the decision in the project README so the next contractor does not "upgrade" a converting shortcode page for sport.
A practical example: a wine shop landing page from 2022 with [products category="red"] inside a builder column. If that URL still converts and the HTML contains product links, I leave it. A new "summer reds" page in 2026 gets a Product Collection block on a block-enabled page so merchandising can change the query without hunting a shortcode attribute. Same catalogue. Two eras. One cart.
Another example: a games shop that sells downloads and physical SKUs. The product types already stress classic templates. If the download plugin only patches content-single-product.php, I do not force a block PDP on those SKUs until the plugin documents a block template. I can still put the Cart and Checkout blocks on the order path. WooCommerce blocks vs shortcodes is allowed to be mixed by template. It is not allowed to be mixed by two carts.
Production checklist
- Inventory pages containing
[woocommerce_,[products,[product_page,[add_to_cart. - Inventory theme overrides in
woocommerce/*.php. - List plugins that
add_filtercheckout fields, cart fragments, orwoocommerce_locate_template. - Mark each template: block, classic, or mixed (mixed is a bug to schedule).
- For checkout and cart, run the compatibility pass from the block checkout note.
- For shop, test filters, sort, pagination, and empty states in the chosen pipeline only.
- For PDP, test simple, variable, backorder, out of stock, grouped, and external/affiliate if you sell them.
- Remove theme CSS that hides "the other" pipeline's markup. Dead CSS still downloads.
- Dequeue classic cart fragments if Mini-Cart block is canonical.
- Confirm GA4
view_item,add_to_cart,begin_checkoutstill fire on the chosen markup. - Train the merchant: which pages they edit in the block editor versus which are theme PHP.
- Do not enable "coming soon" Woo features on production without staging. Block experiments have shipped rough.
- After WooCommerce updates, re-test checkout and the shop archive the same day. Blocks and classic break on different releases.
- Document Elementor: which templates must remain builder, which URLs are now block pages.
What breaks when you mix blocks and shortcodes
Two mini-carts. The header count updates from fragments. The Cart block shows a different quantity. Customers add twice.
Checkout fields that appear on classic and vanish on blocks, or the reverse if you switched pages but left a plugin assuming woocommerce_checkout_after_customer_details.
SEO: product collection blocks that client-render the grid. View source has no product links. Classic [products] was server HTML. Configure blocks to render products in the initial HTML. I check "View source," not only the browser inspector.
Performance: classic woocommerce.css plus blocks checkout CSS plus a builder. INP dies. Pick a primary stack per URL.
Theme updates that replace archive-product.php while a block template is also active. Which one wins depends on WooCommerce template hierarchy and theme.json. I keep one archive source of truth.
Accessibility: shortcode tables versus block grids have different headings and button names. Mixing on one journey confuses both users and automated tests.
How I measure the split
I measure completed checkout, add-to-cart from collection and PDP, and whether merchandisers can edit the pages they were promised. Technical: HTML contains product links on collections (crawl). Field INP on shop, PDP and checkout separately.
If a rebuilt block landing page loses organic clicks, I diff the server HTML against the old shortcode page before I blame Google.
I do not invent conversion rates for a block migration. Games, wine and mixed catalogues I have shipped succeed when the purchase path is one pipeline, not when every page uses the newest block.
I also watch plugin changelogs after WooCommerce minor releases. A gateway that was classic-only in 2024 may ship a block payment method in 2026. That is the moment I schedule the checkout swap, not a random redesign week. Conversely, a Product Collection block that starts omitting product URLs from the initial HTML is a regression I treat like a 404. Crawlers do not run your hydration.
For merchants, the editor story has to be honest. If half the shop is PHP and half is the site editor, I show them which URLs open where. "Everything is blocks now" is a lie that produces support tickets when they cannot find the old shortcode page. WooCommerce blocks vs shortcodes only works as a programme if the people who merchandize the catalogue can still find the page.
Related work on this site
Mixed catalogues expose this split quickly. Splattered Ink Games sells physical tokens, downloads and books from one WooCommerce shop. Franc Lizer is a wine catalogue that has to shop in more than one language. Those are stores where I would keep a single cart and checkout stack, and only use shortcodes as embeds on content pages, not as a second checkout.
FAQ
Is classic WooCommerce going away in 2026?
Classic templates and many shortcodes still work. New checkout and cart investment is on blocks. WooCommerce blocks vs shortcodes in 2026 is about where new features land, not a hard kill switch on [products]. Plan checkout first.
Can I use Product Collection blocks and a shortcode checkout?
Yes, technically. I still avoid mixing on the order path. Collection blocks plus shortcode checkout is a common interim. Cart fragments versus the Cart block is the mix that actually hurts.
Which should a new WooCommerce site use?
A new site in 2026 should default to a block theme, block cart and checkout, and block product templates, then fall back to classic only for incompatible plugins. WooCommerce blocks vs shortcodes should not start as "shortcodes everywhere because the developer learned them in 2016."
Do shortcodes hurt SEO?
Not by themselves. Server-rendered [products] can be fine. Client-only block grids can hide links from crawlers. Judge the HTML, not the word "block."
Keep reading
Contact if you want this kind of work on a live store.