WordPress
Google Consent Mode v2 on WordPress: what it is and how to set it up
Why Google now requires consent signals before ads and analytics fire, what the four signals mean, and the simplest way to implement them on a WordPress site.
· 6 min read
Why Consent Mode exists
Google Analytics and Google Ads run on scripts that set cookies and send data the moment a page loads. Under GDPR and the UK's PECR, that can only happen after a visitor agrees. Consent Mode is Google's answer: a way for your site to tell Google's tags, before they do anything, what the visitor has and hasn't allowed.
Since March 2024, Google requires Consent Mode v2 for anyone in the European Economic Area or the UK who wants to use audience features and conversion measurement in Google Ads. Without valid signals, remarketing lists stop filling and conversion data becomes unreliable.
The four signals
Consent Mode v2 uses four consent types. Each is either granted or denied:
- analytics_storage controls whether Google Analytics can set cookies and record visits.
- ad_storage controls advertising cookies such as those used for conversion tracking.
- ad_user_data (new in v2) controls whether user data can be sent to Google for advertising.
- ad_personalization (new in v2) controls whether that data can be used for personalised ads and remarketing.
A fifth signal, functionality_storage, covers preference cookies and is optional but good practice.
Basic versus advanced mode
In basic mode, Google tags do not load at all until consent is granted. Simple and safest.
In advanced mode, tags load immediately but with everything set to denied. They send cookieless pings that let Google model conversions without identifying anyone. When the visitor accepts, the tags update to granted. Advanced mode keeps more of your reporting intact but requires that the default command runs before any Google script, which is where most DIY setups go wrong.
What a correct implementation looks like
The sequence on every page view has to be:
- Set the default consent state to
deniedfor all four signals, before Google Tag Manager or GA4 loads. - If the visitor has already made a choice on a previous visit, restore it immediately so there is no flash of the denied state.
- Show the banner. When the visitor chooses, send a consent
updatewith their choices. - Only then load or unblock the tags that need consent.
Step 1 is the piece people miss. Adding a banner plugin that fires the update after GTM has already loaded still leaks data on the first page view.
Doing it on WordPress by hand
You can implement this manually with a small script in your theme's header.php before the GTM snippet, plus JavaScript that calls gtag('consent', 'update', ...) when your banner buttons are clicked. It works, but it breaks whenever a theme update overwrites the header, and you have to remember to add wait_for_update so GTM pauses long enough for the stored consent to be read.
Doing it with a plugin
A good consent plugin handles the whole sequence for you: it injects the default-deny call at the very top of the page, restores saved choices, and fires the update when the visitor decides. Look for these things when choosing one:
- It runs the default command before GTM, not after.
- It detects your GA4 measurement ID or GTM container automatically so you are not copying IDs into two places.
- It records each decision so you can demonstrate compliance later.
- It also fires the WP Consent API so WooCommerce and other plugins respect the same choice.
Checking it works
Open your site in a private window, then open the browser console and type dataLayer. You should see a consent entry with default and every value set to denied, followed by the GTM or GA4 entries. Accept the banner and you should see a second consent entry with update and granted values. Google Tag Assistant will also show a "Consent" tab per tag.
If the default entry comes after the GTM entry, your setup is leaking and needs reordering.