Since March 2024, Google has required Consent Mode v2 for websites with visitors in the European Economic Area — otherwise features like remarketing and conversion tracking stop working. At the same time, practice shows: many WordPress sites bring in a full consent management platform for this, even though the mechanism itself is surprisingly lean. This guide explains what Consent Mode v2 technically does and how to set it up in WordPress — without plugin bloat.
Note: this article describes the technical setup and is not legal advice. If in doubt, check with a specialist which services on your website require consent.
What Consent Mode v2 does
Consent Mode is a signalling channel between your cookie banner and the Google tags on the page. Instead of blocking Google scripts entirely, you load them with a default state of "everything denied". The tags then run in a restricted mode: they only send anonymous, cookieless pings until the visitor consents — then they switch to normal measurement.
Version 2 introduced two additional signals compared to v1. In total, your banner communicates these states:
- ad_storage — cookies/measurement for advertising purposes
- ad_user_data — passing user data to Google for advertising purposes (new in v2)
- ad_personalization — personalized advertising / remarketing (new in v2)
- analytics_storage — analytics cookies (GA4)
- functionality_storage — functional storage (e.g. language settings)
- security_storage — security-related storage
The difference between Basic and Advanced Consent Mode matters: with Basic, Google tags are blocked entirely before consent (no ping, no load). With Advanced, the tags load immediately in the "denied" state and send modeled, anonymous pings. Which one you choose is also a legal assessment — Advanced means Google servers are contacted before consent is given.
The three options in WordPress
1. Consent management platform (CMP) with Consent Mode support
Plugins like Cookiebot, Complianz or Borlabs Cookie ship with Consent Mode built in. The convenience is real — but you get a complete consent framework with admin interfaces, external rule sets and often a SaaS connection. For a single WordPress site with a manageable set of services, that is frequently oversized: you install a framework to produce two lines of JavaScript.
2. Manual integration
The core is two steps: set the default before the Google tag, and update the state when the visitor decides. The default goes into the <head>, strictly before the actual gtag/GTM snippet:
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', {
ad_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
analytics_storage: 'denied',
functionality_storage: 'granted',
security_storage: 'granted',
wait_for_update: 500
});
</script>After consent, your banner (or your code) fires the update:
gtag('consent', 'update', {
ad_storage: 'granted',
ad_user_data: 'granted',
ad_personalization: 'granted',
analytics_storage: 'granted'
});That is the entire mechanism. The rest — banner UI, blockers for YouTube & co., consent records, a way to revoke — is legwork, not magic.
3. A lean consent plugin
The third option sits in between: a plugin that encapsulates exactly this mechanism, without an external platform. Disclosure: Skit Consent is our own plugin — it renders the default server-side into the <head>, performs updates per category and blocks embedded services until consent is given. If you prefer building it yourself, option 2 has everything you need.
Integration via Google Tag Manager vs. gtag.js
If you use GTM, the principle stays the same: the default snippet still belongs directly in the <head> before the GTM container — not as a tag inside the container itself, because that would fire too late. In the GTM console, enable "Consent Overview" under Admin → Container Settings → Additional Settings. GA4 tags respect the consent signals automatically; for your own tags, check each tag's Consent Settings to see whether "Built-in Consent Checks" or additional checks are required.
If you use gtag.js directly (without GTM), set the default and update as shown above — the integration needs nothing more.
Verifying that it works
- Tag Assistant: open
tagassistant.google.comwith your URL — under "Consent" you see the default and update states per signal. - DevTools: print
dataLayerin the console — theconsentevents withdefaultand laterupdatemust appear. - Network tab: before consent, GA4 requests must not carry a
gcsflag with granted values; after "Accept" the parameters change. - Private window: always test incognito — otherwise your stored consent kicks in and you see nothing.
The most common mistakes
- Default too late: the consent snippet sits after the GTM/GA tag — the signals are ignored.
- Duplicate default calls: a plugin sets one default, your own snippet sets a second — the last one wins, not always the right one.
- Update without category logic: "Reject all" still fires
update: grantedbecause the event is wired incorrectly. - Missing revoke option: technically trivial (another consent call with
denied), but legally required — a small consent button or footer link is enough.
Conclusion
Consent Mode v2 is no rocket science: default before the tag, update after the decision, verify cleanly. The real work is in the rest — banner, blockers, records, revocation. That is exactly what we build Skit Consent for: the mechanism above is fully implemented in it, with no external services and no subscription.
Waitlist: sign up if you want to be there at launch — early access info and the launch price arrive by email.
Newsletter
Updates zu neuen Releases, Features und Divi-5-Tipps — kein Spam.
Fast geschafft!
Fast geschafft! Bitte bestätige deine Anmeldung über den Link in der E-Mail, die wir dir gerade gesendet haben.