TL;DR:
- Installing a cookie consent banner does not make you compliant – it’s the starting point, not the finish line.
- Most consent plugins don’t actually block tracking scripts before a visitor clicks “Accept.” This leaves the site owner open to a lawsuit.
- Hard-coded scripts in your website’s theme or page builder fire before consent tools can stop them.
- Running two consent plugins at the same time causes conflicts – one will lose.
- Not having a “Decline” or “Reject” button is not okay.
- The correct architecture is a consent platform managing Google Consent Mode v2, with Google Tag Manager (GTM) handling only what it should.
Your cookie banner is probably not doing what you think it’s doing.
I don’t say that to alarm you. I say it because I spent months migrating my own sites to a setup that actually works – and in the process, audited enough client sites to know that “we have a banner” and “we are compliant” are two completely different things.
What Most Cookie Consent Plugins Actually Do
When you install a consent plugin – any of them – it puts a banner on your site. Visitors see it. Some click “Accept.” Some click “Decline.” You have documentation. It feels done.
Here’s what most plugins don’t do: block tracking scripts from firing before someone gives consent.
Tracking scripts are the pieces of code that feed Google Analytics, Meta Pixel, and other tools. They’re supposed to wait until a visitor says yes. In practice, many sites load those scripts the moment a page opens – banner or no banner. The consent tool is purely cosmetic. The tracking is already running.
That’s the compliance gap. The banner is visible. The violation is invisible.
Why Hard-Coded Scripts Are the Real Problem
Most website builds include tracking scripts that are placed directly in the site’s theme files, header, or page builder – not through a tag manager. These are called hard-coded scripts.
Consent plugins in WordPress work by intercepting scripts and holding them back until consent is given. But they can only intercept what they know about. A hard-coded script sitting in your theme’s header.php loads before the consent tool has a chance to do anything. The plugin sees the visitor. The script has already fired.
This is the scenario I see most often on sites that appear compliant but aren’t. The banner runs. The pixel runs too. Both happened before the visitor made a choice.
Two Plugins, One Problem
Here’s a situation I’ve seen more than once: a site with two consent plugins running at the same time.
It happens when someone installs a new compliance tool without removing the old one, or when a hosting provider or theme auto-installs one and the business owner adds another. Both plugins try to manage consent. They conflict. Banners behave unpredictably. Scripts load at random. Neither plugin can vouch for what the other is doing.
One consent tool. That’s the rule. Two is not better coverage – it’s a broken setup.
The Architecture That Actually Works
Cookie compliance is not a plugin decision. It’s a technical architecture decision.
The correct setup:
- One consent management platform (CMP) handles all consent collection and storage.
- That platform natively supports Google Consent Mode v2 – the standard Google uses to determine whether your tags are allowed to fire. Without this, Google’s own tools won’t respect the consent signals your site is sending.
- Google Tag Manager (GTM) – the tool that manages marketing and analytics scripts – is configured so that tags only fire based on the consent signals the CMP sends. No consent, no fire.
- Hard-coded scripts are audited and moved into GTM so they can be controlled.
When we migrated Webmaster For Hire from one consent platform to another – one that handles Google Consent Mode v2 natively – GTM stayed in place for WooCommerce ecommerce event tracking. That’s the right use for it. But consent management moved to one tool, doing one job cleanly.
What “Configured Wrong” Looks Like
Even with the right tool, configuration errors are common:
- Default mode vs. denied mode. Google Consent Mode v2 has two signal states: granted and denied. If your CMP isn’t explicitly sending a “denied” signal before consent, some tags treat the absence of a signal as permission to fire.
- Tag triggers not updated. If your GTM tags weren’t reconfigured to check consent signals after you installed a new CMP, they may still be firing on page load regardless of what the visitor chose.
- Banner without script blocking. Some CMPs show a banner and log consent but don’t actually block scripts. They’re consent loggers, not consent enforcers.
Installing the right tool is step one. Configuring it correctly is a different task entirely.
“Cancel” Is Not the Same as “Reject”
Some cookie banners give visitors two buttons: Accept/OK and Cancel – or worse, just an X to close the window.
That’s not a rejection option. That’s the absence of one.
Several privacy regulations – including GDPR in the EU and the UK – require that declining consent be as easy as accepting it. A clearly labeled “Reject” or “Decline” button, equal in prominence to the “Accept” button. Not buried in a settings menu. Not hidden behind a second click. Right there, same level, same visibility.
But the legal problem is only half of it.
On the technical side, closing a banner without clicking a button doesn’t send a denied consent signal to Google Consent Mode v2. From a script-control standpoint, no signal and a granted signal can behave the same way – meaning tags fire anyway. The visitor thought they opted out by closing the window. The tracking kept running.
A real rejection path does two things: it satisfies the legal requirement for equal-prominence opt-out, and it sends an explicit denied signal that actually stops scripts from loading. Cancel does neither.
Is Your Banner Actually Working?
The fastest way to check is to open your site in a private/incognito browser window. Open your browser’s developer tools (right-click anywhere on the page, click “Inspect,” then go to the Network tab). Reload the page before clicking anything on the banner.
Watch what loads.
If you see requests to Google Analytics, Meta, or other ad platforms before you’ve clicked Accept – those scripts fired without consent. The banner is there. The compliance isn’t.
Not Sure If Your Cookie Consent Is Actually Working? Let’s Check.
Cookie consent compliance is one of those things where the appearance of doing it right and actually doing it right doesn’t look the same from the outside. One is a banner. The other is architecture.
Schedule a consultation and we’ll pull back the curtain on what’s actually running on your site before consent is given.
