# Set up Google Consent Mode v2 on WordPress CMP, GTM and default denied consent on WordPress. What breaks Ads and GA4 if signals never fire. - Date: 2026-07-29 - Category: WordPress WordPress Consent Mode v2 is the consent wiring I put on WordPress before I trust GA4 or Google Ads numbers from an Australian or international shop. I am Alan Vo, a Gold Coast developer with 18 years on business sites and stores. In 2026 the v2 signals are not optional if you still run Google tags for EEA visitors. A cookie banner that only hides a bar does not send `ad_user_data` or `ad_personalization`. Ads and modelled conversions then quietly fall apart. This note is for WordPress and WooCommerce sites using Google Tag Manager, a CMP, and Google tags. Pair it with [Consent Mode v2 for paid media](https://alanvo.com/blog/consent-mode-paid-media/) when the question is campaign-side, and with [GTM Consent Mode for Australian storefronts](https://alanvo.com/blog/gtm-consent-mode-australia/) when the legal geography is the point. Here I stay on how WordPress actually boots the default denied state. ## Why WordPress Consent Mode v2 matters in 2026 WordPress Consent Mode v2 matters because Google tags read four storage and data signals, not a single "cookies ok" boolean. The original pair was `ad_storage` and `analytics_storage`. v2 added `ad_user_data` and `ad_personalization`. If those two never fire as granted after a real choice, remarketing and much of Ads measurement will not behave as the media team expects, even when the banner said Accept. Google's own [Consent Mode setup guide](https://developers.google.com/tag-platform/security/guides/consent) is the behaviour spec: set defaults before any measurement command, then `update` when the user chooses. I implement that as HTML in `wp_head` at high priority, or I let a CMP that I have verified print it before the GTM snippet. I do not put the default command inside a GTM custom HTML tag that runs after GTM has already started. That is the most common WordPress miss I still audit. Australia is not the EEA. Plenty of Gold Coast and national shops still get EU and UK traffic, and plenty of clients run Ads with EEA inventory. Default denied for Google advertising and analytics signals is the setup I use unless counsel has signed off on something else. Privacy Act caution still applies for Australian personal information. I am not your lawyer. I am the person who makes the tags match the banner. Advanced Consent Mode (pings without cookies when denied) is a business choice. Basic Mode (do not load Google tags until grant) is simpler and loses more modelling. I document which one we shipped. Silent "the plugin defaulted to advanced" is how you get a privacy complaint and a media complaint in the same week. ![WordPress Consent Mode v2 in the block editor on a laptop](../../images/blog/wordpress-consent-mode-v2-1.jpg) ## How WordPress Consent Mode v2 actually works WordPress Consent Mode v2 actually works as three layers that must agree: default state in the page, CMP UI and storage of the choice, GTM tags that respect built-in consent checks. Layer 1: Default. Before GTM, run `gtag('consent', 'default', { ... })` with `ad_storage`, `analytics_storage`, `ad_user_data`, and `ad_personalization` set to `denied` for opt-in regions. `wait_for_update` (often 500ms) gives the CMP a moment to apply a saved choice so you do not fire a denied hit and a granted hit in a messy pair. `functionality_storage` and `security_storage` are often granted if they are not advertising. Layer 2: CMP. The banner must map categories to those four keys. Analytics grant should update `analytics_storage`. Ads/marketing grant should update `ad_storage`, `ad_user_data`, and `ad_personalization` unless you have a reason to split them (rare on a shop). The CMP must call `gtag('consent', 'update', { ... })` or the equivalent GTM consent API. A `dataLayer.push({ event: 'consent_update' })` alone does not move Google's internal consent state. It only fires tags that listen for that event. Layer 3: GTM. Google tags should use built-in consent checks. Additional pixels (Meta, TikTok, Klaviyo) need their own consent requirements in GTM or they will fire on denied. WordPress plugins that inject `gtag.js` beside GTM create a second loader that never saw your defaults. I hunt `gtag('config'` in the theme, in Woo Google Listings, and in "site kit" style plugins. One loader. WooCommerce purchase events still need to wait for consent if you are in Basic Mode, or they need to be allowed as cookieless pings if you chose Advanced and legal signed off. A thank-you page that fires `purchase` from PHP-printed gtag while defaults are denied and no update ever ran is a black hole for Ads. I keep the CMP cookie on first-party. I test an EU VPN and a domestic Australian session. Same WordPress, different default regions if the CMP supports geo. If geo is wrong, Australians get an EEA banner they ignore, or EEA visitors get opt-out defaults. Both are failures. ## WordPress Consent Mode v2 production checklist WordPress Consent Mode v2 production is order-of-operations, then proof in Tag Assistant. 1. Inventory every Google snippet: GTM, Site Kit, Woo Google plugins, theme header scripts, tag managers besides GTM. 2. Pick one loader. Almost always GTM. Remove duplicate `gtag.js` configs. 3. Install a CMP that states Consent Mode v2 support and writes the four keys. 4. Print default denied in the page before the GTM container snippet. View source on a cold tab, not a logged-in admin bar session only. 5. Map banner categories to the four keys. Do not hide Ads under a vague "performance" toggle. 6. Enable GTM consent overview and set checks on GA4, Ads, Floodlight, and conversion linker. 7. Gate non-Google marketing tags the same way. 8. Decide Basic vs Advanced with the client in writing. 9. Test first visit, Accept all, Reject all, and a saved returning visit. Use Tag Assistant plus the `gcs`/`gcd` query params on Google collect requests. 10. Test the Woo purchase path with Reject all. Confirm you do not store ad cookies. Confirm the media team knows modelled conversions may fill gaps only if Advanced is on and Google has enough data. 11. Do not block the banner with a full-page cache HTML that never updates after CMP script changes. Purge HTML cache when the CMP snippet changes. 12. Record the CMP vendor, GTM container ID, and default region rules in the repo so the next developer does not "simplify" it. ![Developer desk with two monitors during WordPress Consent Mode v2 work](../../images/blog/wordpress-consent-mode-v2-2.jpg) Hardcoded `gtag` in `header.php` plus a CMP in a plugin plus GTM is three cooks. I delete until one remains. ## What breaks when WordPress Consent Mode v2 is incomplete WordPress Consent Mode v2 breaks Ads and GA4 when defaults never run, when updates never run, or when a second gtag config races first. Failure modes: - Default granted globally because a plugin's "US friendly" preset was left on. EEA traffic then gets tags before a choice. - Default denied, but the CMP update never fires, so every session stays denied. Media reports a cliff after "we added a banner". - Update fires on click, but GTM tags are set to fire on All Pages with no consent check, so they already sent. - Cached HTML for user A (granted) served to user B (new). Consent cookies and HTML cache keys must not fight. Usually the CMP's JS applies on the client, so HTML cache is OK if defaults in HTML are denied and JS updates. A full-page cache that includes a granted inline state is not OK. - WordPress admin and front disagree because a plugin only injects CMP on `wp_footer` for logged-out users and skips some templates (checkout, order received). - Cookie yes/no stored, Google keys never updated. Banner is theatre. - Consent Mode v1 only (`ad_storage` / `analytics_storage`) with v2 keys missing. Google treats v2 as required for the Ads products that asked for it. ![Website wireframes on paper next to a keyboard](../../images/blog/wordpress-consent-mode-v2-3.jpg) I also see INP hits from heavy CMPs. A 150KB banner on every page is a performance ticket. Consent is still required. Shop a CMP that does not load a second jQuery. ## How to measure Consent Mode on WordPress Measure Consent Mode with Tag Assistant, GA4 DebugView, and Ads conversion diagnostics, not with "the banner shows". I want to see default denied on first paint, update on Accept, and the matching `gcd` string on collect hits. I also watch: - Consent rates in the CMP dashboard vs sessions in GA4. If GA4 sessions match 100% of pageviews after an opt-in banner, tags are ignoring consent. - Ads conversion volume before/after CMP go-live. A drop can be correct (you were over-tracking) or a broken update. Debug before you "fix" it by granting defaults. - Enhanced conversions still hashing first-party data only when consent allows it. That is a separate paid-media note, but it sits on the same thank-you page. Do not invent a modelled conversion percentage for my clients here. Google publishes product behaviour; your account's modelled share is account-specific. ## Related work on this site Shops that spend on media need this wiring as part of launch, not as a year-two audit. The [Skanvi furniture storefront](https://alanvo.com/work/skanvi/) is WooCommerce where product and checkout tags have to stay honest. [Retail conversion at scale](https://alanvo.com/work/retail-conversion/) is Magento operations work where year-on-year sales moved $2.5 million over three years; that kind of retail still depends on conversion tags that match the gateway, which Consent Mode will starve if defaults stay denied without updates. Skanvi was contract development on an agency team. Retail conversion was in-house ecommerce operations. Same lesson: banner, GTM, and purchase event have to tell one story. ## FAQ ### Does WordPress Consent Mode v2 apply if I only use GA4? WordPress Consent Mode v2 still applies if GA4 is a Google tag. You should set `analytics_storage` (and the v2 ad keys if Ads tags exist or might be added). A GA4-only shop can keep ad keys denied. Do not skip defaults because "we do not run Ads this quarter". Someone will add an Ads tag in GTM without reading this page. ![Content editor reviewing a page on a tablet](../../images/blog/wordpress-consent-mode-v2-4.jpg) ### Is WordPress Consent Mode v2 a plugin checkbox? WordPress Consent Mode v2 is not a single checkbox you can trust without view-source. Some CMPs do it well. Some only show a banner. Verify default in HTML, update on choice, and GTM consent checks. Then test Reject all on checkout. ### Can I implement WordPress Consent Mode v2 only in GTM? You should not implement WordPress Consent Mode v2 only as a GTM tag that fires on Consent Initialization if the container itself loads without defaults in the page. Google wants defaults before measurement commands. A CMP snippet in `wp_head` before GTM is the pattern I use. GTM then handles `update` and tag checks. ### What if WordPress Consent Mode v2 tanks my Ads numbers? If WordPress Consent Mode v2 tanks Ads numbers, first confirm updates fire on Accept. If they do, you were likely measuring people who would not have consented. Modelled conversions and enhanced conversions are the recovery path, not default granted. Fix the wiring, then talk to media. Do not silently revert the banner. HTML version: https://alanvo.com/blog/wordpress-consent-mode-v2/