Stop paying for Cookiebot: a lean GTM + Consent Mode setup that actually works

A practical guide for WordPress sites that want clean tracking without unnecessary tooling

If you build or manage WordPress websites long enough, you start to see patterns. One of the most common ones I run into as a freelance WordPress developer is this:

• A site usesCookiebot (or a similar paid CMP)
• Google Tag Manager is installed
• Tracking is flaky, incomplete, or just broken
• Nobody is really surewhy

Usually, the answer is simple:there are two systems trying to control cookies and scripts at the same time.

This article is my attempt to explain—clearly and practically—why that happens, why "auto‑blocking cookies" is often overrated, and what I recommend instead for most small to mid-sized WordPress sites:

A lightweight cookie banner + Google Tag Manager + Google Consent Mode (v2)

Not as a hack. Not as a loophole. But as a clean, modern, and maintainable setup.

I'll explain thewhyfirst (for marketers and site owners), and then thehow(for developers and advanced GTM users). Technical deep dives are clearly marked—you can skip them and still understand the story.

The problem with most cookie setups I see in the wild

Let's start with a hard truth:

Most cookie banners are not the real problem. The way they are implemented is.

On paper, tools like Cookiebot do a lot of things right:

• They provide a compliant-looking banner
• They categorise cookies
• They can automatically block scripts before consent

The issue is that thisautomatic blockingis often treated as the default, "best practice" option—without thinking about how the rest of the site is set up.

And that's where things start to break.

Auto-blocking sounds good, but it's a blunt instrument

Auto-blocking works by scanning your site and preventing scripts from running until consent is given. That includes:

• Analytics scripts
• Marketing pixels
• Sometimes embeds, A/B testing tools, chat widgets, or even essential integrations

In isolation, that sounds privacy-friendly. In reality, it often leads to:

• Tags firing inconsistently
• GTM preview behaving differently than production
• Marketers asking why conversions dropped "since nothing changed"
• Developers debugging problems that only existbefore consent

The core issue is this:

You are outsourcing script control to a tool that sitsoutsideyour tag management system.

Now you have two sources of truth:

• The CMP decides what loads
• GTM decides what should fire

They don't always agree.

GTM already has consent controls (and they're good)

This is the part many people miss.

Google Tag Manager isn't just a container that fires tags. It has built-in features for consent management:

• Consent Initialization
• Tag-level consent requirements
• Integration with Google Consent Mode

When you also enable auto-blocking in a CMP, you effectively bypass these features.

So you end up paying for:

• a heavy CMP
• anda tag manager

…but not really using either to its full potential.

Performance and maintenance matter too

On WordPress sites especially, CMP plugins often add:

• extra JavaScript
• scanning logic
• admin UI complexity
• recurring license costs

For large enterprises, that might be acceptable. For many WordPress sites, it's simply unnecessary overhead.

This is not an anti-Cookiebot rant. It's ause-the-right-tool-for-the-jobargument.

A better mental model: consent as a state, not a switch

Here's the key shift in thinking that makes everything else click.

Consent is not about loading or blocking scripts.

Consent is about:

• storing the user's choice
• communicating that choice clearly
• letting your tooling adapt behaviour accordingly

In other words:

The banner collects consent. GTM governs behaviour.

This is exactly what Google Consent Mode is designed for.

What Google Consent Mode actually does (in plain English)

Google Consent Mode allows you to tell Google tags (GA4, Google Ads, etc.) whether the user has granted consent for certain purposes.

Instead of a binaryon/off, tags can:

• adjust how they behave
• send cookieless pings when consent is denied
• switch to full tracking when consent is granted

WithConsent Mode v2, Google introduced more granular signals, such as:

• ad_user_data
• ad_personalization

Important disclaimer (and this matters):

Consent Mode is not a legal compliance solution by itself.

It's a technical framework. You still need a proper banner, clear information, and a lawful basis. But technically speaking, it's a very solid foundation.

The lean setup I recommend for most WordPress sites

Here's the architecture I keep coming back to for clients.

1. A lightweight cookie banner

The banner's job is simple:

• Inform the user
• Collect consent
• Store the choice (cookie or localStorage)
• Notify the site when consent changes

That's it.

It doesnotneed to:

• scan your site
• auto-block scripts
• manage tags

2. Google Tag Manager as the control centre

GTM becomes the single place where:

• tags are configured
• consent requirements are enforced
• debugging happens

This is crucial for maintainability.

3. Google Consent Mode for Google tags

Consent Mode ensures that:

• default consent is privacy-friendly
• Google tags behave correctly before and after consent
• measurement gaps are reduced (without ignoring consent)

This separation of concerns keeps things predictable.

Non-technical summary (feel free to skim)

If you're a marketer or site owner, this is the takeaway:

• You don't need an expensive CMP to "block everything"
• Youdoneed a banner that records consent properly
• GTM should decide what tools are allowed to run
• This setup is usually faster, cheaper, and easier to debug

If that sounds reasonable, the rest of this article explains how it works under the hood.

Technical deep dive (optional): how this is implemented

Step 1: Set default consentbeforeGTM loads

This is critical.

Before the GTM container snippet loads, you define a default consent state—usually denied for everything except security.

<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: 'denied',
    personalization_storage: 'denied',
    security_storage: 'granted',
    wait_for_update: 500
  });
</script>

This ensures thatnothing fires prematurely.

Step 2: Read stored consent on page load

If the user already made a choice on a previous visit, you update consent immediately.

<script>
(function() {
  var stored = localStorage.getItem('site_consent');
  if (!stored) return;

  try { stored = JSON.parse(stored); } catch(e) { return; }

  gtag('consent', 'update', {
    analytics_storage: stored.analytics ? 'granted' : 'denied',
    ad_storage: stored.marketing ? 'granted' : 'denied',
    ad_user_data: stored.marketing ? 'granted' : 'denied',
    ad_personalization: stored.marketing ? 'granted' : 'denied',
    functionality_storage: stored.functional ? 'granted' : 'denied'
  });
})();
</script>

Step 3: Update consent when the user interacts with the banner

When someone clicks "Accept" or customises preferences:

<script>
function setConsent(consent) {
  localStorage.setItem('site_consent', JSON.stringify(consent));

  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: 'consent_update',
    consent: consent
  });

  gtag('consent', 'update', {
    analytics_storage: consent.analytics ? 'granted' : 'denied',
    ad_storage: consent.marketing ? 'granted' : 'denied',
    ad_user_data: consent.marketing ? 'granted' : 'denied',
    ad_personalization: consent.marketing ? 'granted' : 'denied',
    functionality_storage: consent.functional ? 'granted' : 'denied'
  });
}
</script>

GTM can now react to theconsent_updateeventandenforce consent at tag level.

Step 4: Configure consent requirements in GTM

In GTM:

• UseConsent Initializationwhere appropriate
• Set consent requirements per tag
• Avoid trigger-based hacks where possible

This keeps everything explicit and debuggable.

Good alternatives to heavy cookie bots

Some options I've used or reviewed:

Lightweight / flexible

• Silktide Consent Manager– free, open source, GTM-friendly
• Osano CookieConsent (open source)– simple, customisable
• Klaro!– powerful if you want full control

WordPress-focused

• Complianz– if clients want a WP dashboard and documentation

The key is notwhichtool you use, buthow little responsibility you give it.

The real advantages of this setup

From real-world projects, the benefits are clear:

• One place to manage tracking
• Fewer broken tags
• Better performance
• Lower costs
• Easier collaboration between devs and marketers

And maybe the biggest one:

You actually understand what's happening.

Final thoughts (and an open invitation)

This setup won't be right for everyone. Large enterprises, complex vendor stacks, or strict audit requirements may justify heavier CMPs.

But for many WordPress sites?

A lean banner + GTM + Consent Mode is more than enough—and often better.

If you're unsure whether your current setup is helping or hurting your tracking, I'm always happy to take a look or collaborate with agencies and marketers who want to standardise this properly.

Clean consent setups are boring when they work—and that's exactly how they should be.