Most website owners install a cookie banner, watch it appear, and consider the job done. It is an understandable conclusion. The banner is the visible part, so it feels like the deliverable.
It is also the single most common misunderstanding we see. The requirement was never "display a banner". The requirement is that tracking waits for a decision, and that the decision is a real one. A banner is just the interface for asking. If the tracking has already started by the time the question appears, the banner is documenting a choice the visitor never got to make.
This guide covers what a cookie banner actually has to do, the four ways banners fail in practice, and how to check your own without taking anyone's word for it.
Scan your website for free
The quickest way to see how your banner behaves is a free scan. It loads your site as a first-time visitor and records what happens before anything is clicked.
Scan your siteWhat the rules actually ask for
Two pieces of European law sit behind the banner, and they ask different questions.
The ePrivacy rules, written into national law in every EU country, govern storing information on a visitor's device or reading what is already there. Consent is needed first, with a narrow exception for storage that is strictly necessary for something the visitor actually asked for, such as a shopping basket or a login session. This rule is broader than cookies and is covered in more detail in our GDPR checklist for small business websites, so this guide will not repeat it.
The GDPR then defines what counts as consent. Article 4(11) sets the bar: freely given, specific, informed, and an unambiguous indication of the visitor's wishes. Article 7(3) adds that withdrawing consent must be as easy as giving it. Nothing in either article mentions a banner. The banner is simply the practical way most sites meet the standard.
Put together, the operative word is before. Consent that arrives after the tracking has started is not consent to that tracking. It is a record created afterwards.
What a compliant banner does
A short checklist. Each item is something you can verify on your own site rather than something to take on trust.
- Nothing non-essential loads until the visitor chooses. Analytics, advertising pixels, embedded media and session recording all wait. Only strictly necessary functionality runs before the choice.
- Rejecting is as easy as accepting. One click, on the first screen, with equal visual weight. If "Accept all" is a button and rejecting means opening a settings panel, the two paths are not equal.
- Nothing is pre-ticked. Optional purposes start switched off. A pre-ticked box is not an unambiguous indication of anything.
- Consent is specific. Analytics, advertising and personalisation are separable choices, not one bundled yes.
- The visitor is told who receives their data, in plain language, before they decide. Naming the categories and linking to the full list is enough at the banner stage.
- Consent can be withdrawn later, as easily as it was given. A visible link or a small persistent control is the usual solution.
- Continuing to browse is not treated as agreement. Scrolling, closing the banner and ignoring it are not consent.
A banner that does all seven is doing its job. Notice that only two of the seven are about the banner's appearance. The rest are about what your website does around it.
Where banners fail in practice
These are the four patterns we measure most often, in rough order of how frequently they show up.
1. The tags fire before the question is answered
The banner appears on schedule, and behind it the tag manager has already released the marketing and analytics tags. This is usually not a decision anyone made. It is the default behaviour of a tag setup that was configured before the consent tool was added, and nobody rechecked the order afterwards.
It is also the easiest failure to confirm. Open your site in a private window, open the browser developer tools with F12, select the Network tab, reload, and do not touch the banner. Anything from an advertising or analytics domain in that list loaded without consent.
2. The site sends "consent granted" before the visitor clicks
This one is less visible and more serious. Some sites transmit a consent signal to advertising and analytics platforms that is hardcoded to "granted", or set as a default before the visitor has interacted with anything. The receiving platform sees what looks like valid consent and begins full tracking immediately.
From the outside the banner looks normal. The visitor is still being asked. But the answer was already sent. This is the pattern we flag as fake consent, and it is worth checking specifically, because a correctly configured banner sitting on top of a hardcoded consent signal will not show any symptoms in the interface.
3. Google Consent Mode is set to grant by default
Consent Mode is Google's mechanism for telling its tags whether consent exists. Version 2 became a requirement for sites using Google advertising products with visitors in the European Economic Area. It is a genuinely useful tool, and it is also easy to install backwards.
The mechanism has a default state that applies before the visitor answers. Set that default to "denied" and the tags run in a restricted, cookieless mode until consent arrives, which is the intended design. Set it to "granted", or omit the default so the tags assume permission, and the site is telling Google that consent exists at a moment when it demonstrably does not. Our scans check the state your site actually transmits, which is not always the state the consent tool's dashboard reports.
4. Rejecting is technically possible and practically discouraged
A prominent "Accept all" button, and a faint low-contrast "Manage preferences" link that opens a panel with a dozen toggles and a second confirmation step. Nothing there is hidden, exactly. It is just built so that accepting takes one second and declining takes thirty.
The freely given standard in Article 4(11) is what this runs into. If the design makes one answer meaningfully harder than the other, the consent it collects is weaker than it looks, and this is a pattern regulators across the EU have addressed repeatedly.
How to check your own banner
Three passes, roughly ten minutes in total.
- Load the site in a private window with the Network tab open and do not touch the banner. Note every third-party domain that appears. That is your before-consent list.
- Click reject, then browse two or three pages. If tracking requests continue, the rejection did not take effect.
- Look at the banner as a stranger. Time how long it takes to accept, then how long it takes to decline. If the second number is much larger, that is the finding.
A scan automates the first two passes and reports what it observed: which services loaded before any choice, which cookies and storage entries were written, and what consent signal the site transmitted. That is measurement rather than a verdict. It tells you what your website did, and the fixes follow from the list.
If a developer or agency maintains the site, the report is the ticket. "These load before consent, please make them wait for it" is a precise instruction, and a re-scan afterwards confirms whether the change worked.
Common questions
Do I need a cookie banner at all?
Only if your site stores or reads non-essential information on visitors' devices. A genuinely static site with no analytics, no embedded media and no marketing tags does not need one, and adding a banner it does not need is its own small problem. In practice most business sites do use analytics or embeds, so most do need one.
Is a "Reject all" button mandatory?
The law describes an outcome rather than a specific button: declining must be as easy as accepting. A "Reject all" button on the first screen is simply the clearest way to demonstrate that, which is why data protection authorities across the EU keep pointing to it. Any design achieving the same balance would meet the standard, but it will be harder to show.
Who enforces cookie rules in Finland?
Two authorities share it. Traficom, the Finnish Transport and Communications Agency, supervises the storage and reading of information on devices under the Act on Electronic Communications Services. The Office of the Data Protection Ombudsman supervises the GDPR side, including whether the consent you collected was valid. For a small business the practical takeaway is that both look at the same thing: what happened before the visitor chose.
My consent tool says everything is configured correctly. Is that enough?
It is a good sign and not a confirmation. Consent tools report their own configuration, not the finished behaviour of the page, and tags added outside the tool, hardcoded in a theme or in a plugin, will not appear in its dashboard. An outside measurement checks the result rather than the intent.
Does a banner protect me if a tracker misbehaves?
Not by itself. You are responsible for what your website loads, so the practical protection is knowing the list and keeping it current. This is why a periodic re-check matters: third-party scripts change what they do over time, without telling you.
This guide and any scan result are factual measurements and general information, not legal advice. For questions about your specific obligations, a data-protection professional is the right person to ask.
Scan your website for free
See what your banner actually does. A free scan shows what loaded before consent and which consent signal your site sent, measured on your own website.
Scan your site