The cookies you set before anyone said yes

A cookie banner is a promise. It tells your visitor that nothing is being stored on their device, and no tracking is happening, until they choose. The trouble is that the banner and the reality are built by different people, at different times, and they drift apart quietly. The banner still says we ask first. The page has already answered for the visitor.

This is the single most common privacy problem we see, and it almost never comes from bad intent. It comes from a tag that fires on page load, a video embed that plants a cookie the moment it renders, or a plugin that sets an identifier before the consent script has even finished loading. Nobody chose it. It accumulated, one reasonable addition at a time, the same way a third-party script list grows.

Two rulebooks, not one

It helps to separate the two things people fold together as GDPR cookies.

The first rule is about the device. In the EU, storing or reading information on someone's device, which is exactly what a cookie is, needs consent first, unless it's strictly necessary to deliver the service they asked for. That's Article 5(3) of the ePrivacy Directive, carried into each member state's own statute: the electronic communications law (LEK) in Sweden, the TDDDG in Germany. The UK kept the same rule after Brexit, as regulation 6 of PECR. This is the rule a cookie set before consent breaks, regardless of what the cookie later does.

Most of the rest of the world doesn't regulate the write to the device at all, only what you do with the data afterwards. Canada's PIPEDA requires meaningful consent to collect personal information, and Quebec's Law 25 goes further by demanding that profiling and tracking technology be switched off by default. Australia's Privacy Act 1988 works through notice and the Australian Privacy Principles, with no prior-consent gate on storage. The US has no federal equivalent: California's CPRA and the state laws modelled on it are opt-out, built on a right to refuse the sale or sharing of personal information and a duty to honour the Global Privacy Control signal, rather than a right to be asked first. None of which helps if part of your audience sits in Europe, because the device rule follows the visitor, not the server.

The second rule is about the data. The GDPR governs what you then do with personal information, and consent is only one of six possible legal grounds. For plain visitor statistics, legitimate interest is often the steadier footing. The framework permits more than most teams assume. Before asking whether you need consent, ask what you're trying to learn and what the lightest way to learn it is.

Keeping these apart matters, because a cookie dropped before the click is a device-rule problem you can't reason your way out of with a legal basis. It happened before the visitor had any say.

You don't need a lawyer with a browser open to find these. Two of the checks in Webperf Audit look at exactly this, from two different angles.

The first is the privacy test in the open-source webperf_core suite, test number 31. It loads your page in a real browser through a Webbkoll engine and grades the privacy posture on a small scale: cookies, third-party requests, whether the connection is properly secured, referrer leakage, and the security headers that should be present. It's a fast, standardised read on how one page behaves, and cookies are one line of that score.

The second is the cookie audit, and its trick is almost too simple to trust at first. It visits your page in a real browser and deliberately gives no consent at all. Then it lists every cookie it finds. Because it never clicked anything, the meaning is unambiguous: each cookie in that list was set without consent. There's no interpretation to argue about.

From there it does the sorting a person would do by hand, only across every page and every visit:

One deliberate choice: the audit records that a cookie exists and what it looks like, but never its value. Cookie values are frequently unique identifiers, which is to say personal data, and a privacy tool has no business hoarding those.

Why the fix is usually less, not more

There's a temptation, once you see cookies set before consent, to reach for a bigger consent management platform and gate everything harder. Sometimes that's right. More often the better move is upstream: does this cookie need to exist at all?

This is where the analytics fear tends to surface. If we hold tracking until consent, we lose half our numbers. It's a fair worry, and roughly true: the Swedish figures we have put acceptance of statistics cookies at around half of visitors, and who accepts skews by age and topic, so what you keep isn't a clean sample. But the answer isn't to fire the tracker early and hope nobody checks. It's to measure the part that never needed a cookie in the first place. Page views, traffic sources, geography, device, search terms: all of that is available without storing anything on the device, for every visitor, with no banner in the way. You reserve consent for the things that genuinely need it, like stitching a journey together across visits.

In practice that's one setup, not two: a cookie for the visitors who consented, and for everyone else a count assembled from what the browser sent anyway. Matomo can be configured to run that way, and Plausible and Fathom work that way by default. The visit still lands in your reports — the URL, the referrer, the user agent, a truncated IP, the search term when the referrer carries one, and the whole path through the site within that visit, stitched together server-side from one session's requests.

What you lose is identity across visits. With nothing stored on the device, someone who read three pages on Monday and comes back Thursday arrives as a new visitor, so returning-visitor share, multi-visit funnels and any attribution that spans weeks are either unavailable or wrong in a direction you can't see. Worth asking how much weight that number was carrying. For a municipal site or a documentation section, the questions that get asked are which pages people land on, what they searched for, where they gave up, and whether the rewritten page does better than the old one. None of those need to know this is your fourth visit.

One caveat on the word cookieless, because it gets used as though it settled the legal question. Article 5(3) covers reading the device as much as writing to it, so a tracker that sets no cookie but fingerprints the browser sits in much the same place as one that sets a cookie; the EDPB's Guidelines 2/2023 on the technical scope of Article 5(3) say as much, and they don't leave IP-based recognition cleanly outside either. The test worth applying is whether an identifier survives. Request data your server was going to receive regardless, processed under legitimate interest, kept briefly, never hashed into something stable from one day to the next, keeps you out of the device rule. A rotating hash of IP and user agent is closer to that line than most vendor pages admit.

Done that way, your consent rate stops being a leak to plug and starts being a signal. A rate that's suspiciously high often means cookies are being set before the click. A rate near zero can mean the banner is broken and turning away data you were allowed to keep. Either way, you can only read it once you know what's firing before anyone says yes.

That's why you test for it. Not to produce a compliance certificate, but to make the invisible visible, on every page, every time it changes, so the banner's promise and the page's behaviour stay the same sentence.

The privacy test and cookie audit run on every page in every plan, and they list what fires before the click. See the plans, or write to us at hello@webperf.cloud.