How to Implement Consent Mode in WooCommerce with Cookiebot

The implementation has to control behaviour, not only display a banner

Consent Mode does not collect consent. It receives a consent state from a banner or Consent Management Platform and changes how supported Google tags behave. Cookiebot collects the choice. Consent Mode passes that choice to Google. WooCommerce provides the commercial events that need to be measured.

If one of those connections is missing, the site can look compliant without behaving correctly. I have seen stores where the banner worked, but analytics_storage remained granted before any interaction. In others, consent changed correctly but the purchase event came from both a WooCommerce extension and Google Tag Manager.

The useful way to approach this work is as a release with acceptance criteria. The banner, consent signals, tag behaviour and ecommerce events all need separate tests.

Google describes two Consent Mode implementations. Basic mode blocks Google tags until consent is granted. Advanced mode loads consent-aware Google tags with denied defaults and can send cookieless signals when storage is denied. The choice affects data transmission and modelling, so it should be agreed with the organisation's legal or privacy owner before configuration starts. Google Analytics: Basic and Advanced Consent Mode.

The stack used in this guide

The main path in this guide uses:

• Cookiebot CMP WordPress plugin for the banner, consent record, category mapping and Consent Mode updates,
• Google Analytics for WooCommerce for the Google tag and standard ecommerce events,
• WP Consent API as the consent interface between the two WordPress extensions,
• GA4 as the analytics destination.

This is the shortest route for a store that does not need custom GTM logic. The official WooCommerce extension supports WP Consent API but does not provide a banner. Cookiebot provides that user interface and also integrates with WP Consent API. WooCommerce: Google Analytics for WooCommerce and Cookiebot CMP for WordPress.

If the store already manages GA4 and Google Ads in Google Tag Manager, keep GTM as the tag layer. Use a WooCommerce data layer integration to produce events, let Cookiebot load GTM or deploy Cookiebot through its GTM template, and do not also enable the Google tag in the WooCommerce analytics extension. The event source may change. The rule does not: one component owns each Google tag and each ecommerce event.

Step 1. Inventory every tracking entry point

Do this before installing another plugin. Search the theme, child theme, header injection tools and active plugins for:

• GA4 measurement IDs beginning with G-,
• Google Tag Manager container IDs beginning with GTM-,
• Google Ads IDs beginning with AW-,
• Site Kit, pixel plugins and theme-level analytics settings,
• custom code in header.php, functions.php or a snippets plugin,
• checkout, payment and thank-you page customisations,
• cache or performance tools that delay, combine or defer scripts.

Then load the store in a clean browser profile and record the current network requests and cookies. Test the home page, a product page, cart, checkout and order confirmation. This baseline makes duplicate tags much easier to find after the change.

I also write down who owns each component. On a mature store, WordPress access, Cookiebot configuration, GTM publishing and GA4 administration may sit with different people. A technically correct change can remain half deployed because one container version or plugin setting was never published.

Step 2. Define the consent model before configuring Cookiebot

Cookiebot categories and Google consent types are related, but they are not interchangeable labels. Cookiebot maps them as follows:

This mapping is built into Cookiebot's Google integration. Cookiebot documents the complete category mapping.

The organisation still needs to decide where the banner appears, which regional rules apply, whether Google tags may send cookieless pings and how withdrawal should work. Consent Mode is a technical control. It does not decide whether a particular configuration is lawful for the store's markets and purposes.

Step 3. Configure Cookiebot and run the first scan

1. Create the Cookiebot domain group and add the production hostname without https://.
2. Add every hostname that participates in the journey, including a separate checkout or shop subdomain when it is under your control.
3. Configure the banner language, geographic scope, categories and consent-expiry policy according to the approved requirements.
4. Make Reject and Manage Preferences easy to find. Do not hide the refusal path in a second screen unless the approved design and applicable rules support it.
5. Run the Cookiebot scan and review every unclassified tracker. An unclassified script is an unresolved implementation task, not a harmless report row.

Cookiebot says a new domain scan can take up to 24 hours. The scan is useful, but it is not a substitute for browser testing. A crawler may not reach a cart state, logged-in account, express checkout or payment-return page. Cookiebot: WordPress installation.

Step 4. Install the Cookiebot WordPress plugin

1. Install and activate the current Cookiebot CMP plugin from WordPress.
2. In Cookiebot Admin, open Implementation and copy the Domain Group ID.
3. In WordPress, open Cookiebot > Settings > General settings, paste the Domain Group ID and save.
4. Open the Google Consent Mode tab and confirm that Consent Mode is enabled. Cookiebot enables it by default in the current plugin, but I still verify the saved state after an update.
5. Create a cookie declaration page and link it from the footer so visitors can inspect trackers and change or withdraw their choice.

Do not install Cookiebot twice. If the WordPress plugin loads it, pause or remove a Cookiebot tag already present in GTM. If GTM was hardcoded in the theme and you decide to let the Cookiebot plugin load the container, remove the old loader after validating the new one. Two CMP instances can create a race between default and update commands.

If the store uses Google Tag Manager

The Cookiebot WordPress plugin can also insert the GTM container. In Cookiebot > Settings > Google Tag Manager, enable GTM and enter the GTM-XXXXXX ID. Leave the custom data layer name empty unless the site really uses one.

There is another supported architecture: deploy Cookiebot with its Community Template Gallery tag in GTM and fire it on Consent Initialization - All Pages. Pick one route. The WordPress plugin route is easier when theme and plugin scripts outside GTM also need Cookiebot's automatic blocking. The GTM template route suits a container that already owns the consent architecture.

Step 5. Configure Google Analytics for WooCommerce

1. Install and activate Google Analytics for WooCommerce.
2. In GA4, open Admin > Data Streams and copy the web stream Measurement ID.
3. In WordPress, open WooCommerce > Settings > Integration > Google Analytics and enter the G-XXXXXXXXXX ID.
4. Enable the ecommerce actions the measurement plan needs, including purchase, product views, add to cart, remove from cart and checkout initiation where supported by the store's templates.
5. Save, clear the WordPress and CDN caches, then inspect the rendered page source.

The extension uses the WooCommerce Product ID as the Google product identifier by default. If merchandising, feeds or reporting use SKU instead, change the identifier intentionally and document it. WooCommerce exposes the woocommerce_ga_product_identifier filter for this purpose. Mixing Product ID, variation ID and SKU across events makes an apparently complete funnel impossible to join at item level.

The free extension records purchases when the payment flow returns the customer to the order-received page. That dependency matters. Test every active payment gateway, express checkout, custom thank-you page and mobile flow. A successful order in WooCommerce does not prove that the browser reached the page that sends purchase.

Step 6. Confirm the consent default is set before measurement

On a new visit in a region where prior consent is required, the initial state should include all four Consent Mode v2 signals:

ad_storage: denied
analytics_storage: denied
ad_user_data: denied
ad_personalization: denied

Cookiebot also maps preference and security storage. The exact approved defaults can differ by region, but no Google tag should read an undefined state and assume the wrong behaviour. Google requires the default command to happen before commands that send measurement data. The consent update must happen on the page where the visitor makes the choice. Google: set up Consent Mode on websites.

With the current Cookiebot WordPress integration, the plugin creates the default and sends updates. Do not paste a second default snippet into the theme unless you have established that the plugin cannot own this step. Duplicate defaults are harder to diagnose than a missing one because the final state depends on load order.

A performance plugin can break an otherwise correct setup by delaying Cookiebot while allowing gtag.js or GTM to load immediately. Exclude the Cookiebot consent script and consent initialisation from delay or defer rules. Recheck this after any change to caching, script optimisation or the WordPress theme.

Step 7. Apply consent to Google and non-Google tags correctly

Google tags for Analytics, Ads, Floodlight and Conversion Linker have built-in consent checks. In an approved Advanced Consent Mode setup, they can use their normal triggers and adapt to the current consent state. Google advises against adding extra consent checks to these tags because the additional block can prevent them from firing after a same-page consent update. Google Tag Manager: unblock consent-aware Google tags.

That rule does not extend to every script in the store. Meta Pixel, affiliate tags, heatmaps, chat tools, embedded video and other third-party code may need explicit control. Use one of these mechanisms:

• Cookiebot automatic blocking for scripts and embeds loaded outside GTM,
• manual Cookiebot markup such as type="text/plain" and the relevant data-cookieconsent category,
• GTM Additional Consent Checks for tags without built-in support, combined with Cookiebot's cookie_consent_update event so a tag can fire immediately after the visitor changes the choice.

Necessary WooCommerce functions must remain usable without analytics or marketing consent. Cart contents, checkout security, payment and account login cannot depend on the Statistics or Marketing category merely because a broad script bundle contains both functional and tracking code. Split the bundle or change the integration.

Step 8. Test the consent lifecycle in Tag Assistant

I test consent as a state machine, not as one click on Accept All. Start each scenario with clean cookies and storage.

1. No interaction: open a product page and check the earliest Consent event. The On-page Default column should show the approved initial state for all four v2 parameters.
2. Reject all: refuse optional categories and confirm the latest Consent event contains denied updates. In Basic mode, Google tags remain blocked. In Advanced mode, network requests can still occur without analytics or advertising cookies, so the presence of a request alone does not prove failure.
3. Statistics only: grant Statistics and reject Marketing. Expect analytics_storage to become granted while ad_storage, ad_user_data and ad_personalization remain denied.
4. Accept all: confirm that all approved states update on the same page, without requiring a reload.
5. Withdraw: reopen preferences, remove consent and check that the update is sent. Then navigate to another page and confirm the choice persists.
6. Returning visit: close the browser, return with the saved consent cookie and verify that tags use the stored choice without a brief granted state first.

Google's Tag Assistant shows the default, the latest update and the consent checks evaluated by each tag. This is more reliable than looking only for _ga in browser storage. Google: troubleshoot Consent Mode with Tag Assistant.

Step 9. Test the complete WooCommerce purchase journey

Repeat the ecommerce journey under at least Reject All, Statistics Only and Accept All. Use a real test product and a payment method that follows the production path.

• Open a product list and confirm the expected item-list event.
• Open a product and inspect item_id, item_name, price and currency.
• Add and remove the product from the cart. Confirm that one action produces one event.
• Begin checkout and verify the cart contents carried into the ecommerce payload.
• Complete payment and check purchase on the order-received page.
• Compare transaction_id, value, tax, shipping, currency and the items array with the WooCommerce order.
• Refresh the order-received page and revisit it from order history. The transaction must not be counted as a new purchase.

A unique transaction_id is essential to purchase integrity. Google includes it in the recommended ecommerce schema, but the implementation still needs a real WooCommerce order identifier and a duplicate-prevention test. Google Analytics ecommerce measurement.

Keep the browser test order and its GA4 DebugView evidence together. A screenshot of a green tag in GTM does not show that the value, currency or items matched the order.

Step 10. Check scripts that the Cookiebot scanner may miss

A WooCommerce storefront has state-dependent surfaces that a public crawler may never see:

• mini cart and cart drawer,
• checkout blocks and legacy shortcode checkout,
• account pages, wish lists and product comparison,
• payment-provider redirects and return pages,
• subscription renewal or saved-payment screens,
• post-purchase offers, review widgets and support chat,
• content displayed only to logged-in customers.

Open each surface manually before and after every consent choice. Review network requests, storage and console output. Classify every tracker and decide which component blocks it. Do not assume the main Cookiebot scan covers a checkout step that requires a live cart or an authenticated account.

Step 11. Release with an acceptance record

Before publishing the change, save:

• the approved consent model and regional defaults,
• Cookiebot Domain Group ID and plugin settings,
• the list of tag and event owners,
• Tag Assistant exports or screenshots for each consent scenario,
• test order IDs and corresponding GA4 events,
• the Cookiebot scan report with resolved classifications,
• the cache and optimisation exclusions needed to preserve script order,
• a rollback plan for the WordPress and GTM changes.

After release, repeat the test on production with a low-value or fully refundable order. Then compare WooCommerce orders with GA4 purchases daily for the first week. Consent will cause an expected gap between backend orders and observed Analytics purchases. Sudden changes, duplicate transaction IDs or a gap that varies after a theme release need investigation.

The failures I check first

Google Analytics is loaded from two places

The WooCommerce extension, GTM, Site Kit and the theme can each add a Google tag. Keep one implementation. Two page views are easy to notice. Two purchases can quietly inflate revenue and ROAS.

The default state arrives after the Google tag

This usually follows script delay, a hardcoded tag above wp_head() or a CMP loaded late through another tool. Move consent initialisation first and retest the earliest event in Tag Assistant.

The banner changes, but the Google state does not

The WordPress interface may show the saved choice while GA4 still sees the default. Check for the update on the same page. Confirm that the current Cookiebot plugin is active, Consent Mode is enabled and no second CMP instance overwrites the command.

Google tags have both built-in and additional checks

In Advanced Consent Mode, this can stop a Google tag from firing when the visitor grants consent after page load. Remove the extra gate from consent-aware Google tags when that matches the approved architecture. Keep explicit checks for third-party tags that do not understand Consent Mode.

The purchase event depends on a page the customer never sees

Some gateways, express wallets and custom confirmation flows do not return cleanly to the standard order-received page. The order exists, but the browser event does not. Test every gateway rather than extrapolating from one test payment.

Consent is tested, ecommerce is tested, but never together

A purchase under Accept All says nothing about Reject All. A correct consent update on the home page says nothing about checkout. The acceptance matrix must cross consent states with the actual buying journey.

What a finished implementation should prove

I consider the work complete when the evidence answers these questions:

1. Is the approved default consent state available before any Google measurement code runs?
2. Does Cookiebot update all four Consent Mode v2 parameters on the page where the choice is made?
3. Can the visitor reject, grant and later withdraw consent?
4. Do Google tags follow the selected Basic or Advanced architecture?
5. Are non-Google trackers blocked by an explicit Cookiebot or GTM rule?
6. Does WooCommerce remain fully usable without Statistics or Marketing consent?
7. Does each ecommerce action create one correctly structured event?
8. Does a completed order create one purchase with the correct transaction ID and value?
9. Does the implementation survive cache clearing, a returning visit and a payment redirect?
10. Can the team reproduce the tests after the next plugin, theme or checkout release?

A Consent Mode implementation is reliable when its behaviour can be reproduced, not when the banner happens to appear. Cookiebot provides the consent decision and Google signal mapping. WooCommerce provides the commercial journey. The implementation work is the connection between them, including the failure paths.

For a quick pre-release check, use the Consent Mode checklist. If the store has several tag sources or custom checkout flows, start with the GTM configuration checklist and reconcile the final purchase data with a broader GA4 audit.