Most WooCommerce consent advice starts in the wrong place. WooCommerce's own cookies, the ones that make the cart and checkout work, are strictly necessary and don't need consent at all. The cookies that do need consent come from the plugins you bolt on top: Google for WooCommerce, a Meta pixel, an abandoned-cart tool, a product-recommendation widget. Getting the line between those two groups right is the whole job, and getting it wrong either breaks compliance or breaks checkout.

The compliance side has teeth. France's CNIL fined SHEIN 150 million euros in September 2025, partly because trackers fired before any choice and continued after "Reject all" (CNIL). On a store, that's the marketing pixels loading on your product pages before a visitor opts in.

WooCommerce cookies that need no consent

Per WooCommerce's own documentation, the core store cookies are strictly necessary and store no personal information (WooCommerce cookies):

woocommerce_cart_hash and woocommerce_items_in_cart, session cookies that track when cart contents change.
wp_woocommerce_session_XXXX, a two-day cookie holding a unique code so WooCommerce can find each customer's cart data.
store_notice, lets a visitor dismiss the store notice.
woocommerce_recently_viewed, a functional cookie powering the recently-viewed-products widget.

You don't gate these behind consent, doing so would break the cart. You do disclose them in your cookie policy, because transparency about necessary cookies is still required.

What actually needs consent

Almost every store adds tracking through plugins, and this is where consent applies:

Google for WooCommerce: wires up GA4 and Google Ads with ecommerce events (product views, add-to-cart, purchase). Analytics and advertising cookies.
Meta for WooCommerce: the Facebook/Instagram pixel plus a Conversions API feed. Marketing cookies, and a server-side feed that also has to respect consent.
Abandoned-cart and email plugins: track browsing to trigger recovery emails, often marketing-classified.
Reviews, recommendations, and live chat: set analytics or functional cookies on load.

All of these load their own tags, usually on every page, before a visitor has chosen anything. That's what your banner has to hold back.

Where consent code goes on WooCommerce

WooCommerce runs on WordPress, so the consent loader belongs in the site <head>, output through the theme's wp_head() hook, and it needs to fire before the tracking plugins print their scripts. The clean way is a consent plugin or a small snippet that loads the CMP first. The reason ordering is hard here: tracking plugins hook wp_head and output their tags on load, so unless the consent runtime intercepts them, they've already fired.

<!-- Loaded early in wp_head, before tracking plugins output their tags -->
<script async src="https://cdn.cookiebeam.com/banner/YOUR_BANNER_ID/default/loader.js"></script>

Replace YOUR_BANNER_ID with your banner's public ID. For the WordPress-side placement details, see the WordPress cookie consent guide.

Blocking plugin trackers

You control tags you write yourself: mark them type="text/plain" with a data-category and CookieBeam activates them after opt-in. The harder case is a plugin that outputs its own <script> tags you can't edit. Two reliable options:

Route ecommerce tags through GTM and gate the container, so one consent decision governs GA4, Google Ads, and Meta together. See GTM consent setup.
Let the CMP auto-block by default. CookieBeam's loader blocks scripts it doesn't recognize until consent, which catches plugin tags you didn't hand-tag. It also scans your store and classifies the cookies each plugin sets.

Don't block the payment scripts

This is the checkout trap. Payment gateways load their own JavaScript, Stripe.js for the Stripe gateway, the PayPal JS SDK for PayPal, and those scripts are strictly necessary to take a payment. If your consent tool blocks them along with the marketing tags, checkout breaks for everyone who hasn't clicked "Accept." Classify payment and fraud-prevention scripts as necessary so they always load, and reserve blocking for analytics and marketing. Test this specifically: a visitor who rejects everything must still be able to pay.

Consent Mode v2 and ecommerce events

If you run Google Ads or GA4 for EEA or UK shoppers, Consent Mode v2 has been required since March 2024. Set defaults to denied before Google tags load, then let the banner push the update on acceptance. With Google for WooCommerce, the ecommerce events (add-to-cart, begin-checkout, purchase) then only send when analytics or advertising consent is granted:

<!-- Early in wp_head, after the loader -->
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('consent', 'default', {
    ad_storage: 'denied',
    analytics_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied',
    wait_for_update: 500
  });
</script>

CookieBeam applies the defaults and fires the update for you. To recover measurement lost to rejections without breaking consent, the server-side tagging on WordPress guide covers the server-side path.

Test the whole funnel

A store is more than a homepage, so test the full purchase path:

Open a fresh private window from an EU IP. On the product page, before clicking, confirm only WooCommerce's necessary cookies exist, no _ga, no _fbp.
Reject all, then add to cart and go to checkout. Confirm marketing tags stay blocked and the payment form still loads and works.
Accept, and confirm GA4 and pixel events fire and Consent Mode reports granted.
Complete a test order and check that the purchase event only sent when consent allowed it.

CookieBeam blocks unknown scripts by default, keeps a timestamped consent record, and scans your store so the cookie policy stays in sync as you add plugins. For the conversion side of getting this right, see the ecommerce consent and conversion guide, and run a full consent audit before launch.