Cookie consent compliance fix
A consent banner is only doing its job if nothing non-essential runs until a visitor agrees. On most sites it does not work that way: the banner appears, and the analytics, the pixels and the embedded video have already set their cookies underneath it. Our Baltic web audit measured this on the sites that had actually installed a consent-management tool, so these are owners who paid for the software and believe they are compliant. Cookies were still being set before any consent on 90% of them in Latvia, 91% in Estonia and 89% in Lithuania, a median of four cookies each. We test what your site actually does, fix the loading order so the tags wait for the answer, and re-test to prove it.
The banner is not the control, and that is the whole problem
A consent tool can only gate what it has been wired to gate. A tag hardcoded into the theme, a plugin that loads its own tracker, a chat widget dropped in by a marketing agency: none of those pass through the consent tool, so the banner asks the question and the script ignores the answer. This is why the failure rate among sites that installed a tool is around 90%. The software is fine. It was never connected to most of what runs on the page.
Consent Mode is where most setups stop half-finished
Google Analytics and Google Ads expect consent signals rather than simply being switched off, and a setup that only blocks the script loses the modelled conversions that Consent Mode v2 exists to preserve. Done properly you keep usable measurement and still set nothing before the visitor agrees. Done as an afterthought you get the worst of both: gaps in the data and cookies you promised not to set.
Measured before and after, not asserted
We check from a clean profile with no prior consent stored, record every cookie and third-party request that fires before a single click, then do the same again after the fix. That is the same method the audit used across the region, and it is the only version of this claim worth making, because a banner that looks correct and a banner that behaves correctly are routinely different things.
- A measured test of what your site sets before any consent is given, from a clean browser profile
- A map of every tag, pixel, embed and plugin that fires on load, and which of them the banner is actually controlling
- Script loading reordered so non-essential tags wait for a real consent signal
- Google Consent Mode v2 wired up correctly for Analytics and Ads
- Embedded video, maps and social widgets switched to click-to-load or a privacy-preserving mode
- Google Fonts moved to self-hosted, removing a third-party request that happens before consent
- Reject and withdraw made as easy as accept, which is where most banners fail
- A re-test after the work, with the before and after side by side
Who this is forFor companies that already bought a consent tool, ticked the compliance box, and have never checked whether the thing is actually blocking anything.
Because installing the tool and connecting it to everything on your site are two different jobs, and the second one usually did not happen. The tool blocks what it knows about. Anything hardcoded into the theme, loaded by another plugin or added later by an agency runs regardless. Nine in ten Baltic sites that installed one of these tools still set cookies before consent, so if this is your situation you are in the majority, not the exception.
Open your homepage in a fresh private window, open the browser developer tools, go to the storage or application panel and look at the cookies before you click anything on the banner. If the list is not close to empty, the banner is not gating them. Doing this yourself first is worth it, and we would rather you did than take our word for it.
It reduces it, and anyone who says otherwise is selling. What a correct Consent Mode v2 setup does is keep the measurement usable: consented visitors are tracked normally, and the rest are modelled rather than lost entirely. You end up with less data than a site that ignores the law and considerably more than a site that just switches the tag off.
The requirement itself is not theoretical: non-essential cookies need consent before they are set, and that is the rule regardless of whether anyone has knocked yet. In practice the trigger is usually a complaint or a customer asking, rather than a routine inspection. Our position is that the fix is small enough that arguing about enforcement odds costs more than doing it.
We produce the cookie inventory the policy has to be based on, which is the part most policies get wrong because they were copied from another site. Turning that into final legal wording is a lawyer’s job, and we will say so rather than quietly drafting it.
Loading fonts from Google’s CDN sends every visitor’s IP address to Google before the page has drawn anything, which happens before any consent could be given. A German court ruled in 2022 that this breaches the GDPR. It shows up on 36 to 45% of Baltic sites, it takes very little work to self-host instead, and since it appears in the same crawl as the cookie problem it makes sense to fix both at once.