The cookie bar is probably the most hated element on the internet. That is slightly unfair, because the bar itself is not the problem. The problem is what happens before the bar.
When we review a site, the first question is not "does the bar look nice". The first question is: does the page wait until the visitor has decided, or has it already started tracking? On most of the sites we see, it has already started.
A small warning before you read on: this article is not legal advice. We are not lawyers and we do not know your situation. It is a list of the things we see in practice on almost every site, together with how to check for them yourself.
Why the bar alone proves nothing
Consent means a person got to choose. The choice has to come before the action, not after it. If the script has already run by the moment the bar appears on screen, the bar is not asking for consent, it is announcing something after the fact.
That is also why "we have a cookie bar" is never a sufficient answer. The bar is a consequence. The question is what sits behind it.
1. Scripts load before the click
The most common mistake and the hardest to spot, because there is nothing to see on the page. Analytics, the Facebook pixel and the chat widget go into the page head, the bar goes in beside them, and the visitor is tagged before they can press anything.
How to check it yourself:
- Open your site in a fresh private window, so old cookies do not muddy the result.
- Right-click, choose "Inspect", and go to the Network tab.
- Reload the page. Do not press anything on the bar.
- Type something like
google-analytics,gtm,facebookorhotjarinto the filter.
If you see requests going out, it is broken. That is all there is to it, and it takes two minutes.
2. "Accept" only, with no way to refuse
If yes is one click on a big coloured button, and no requires opening "Settings", switching off three toggles and then pressing "Save", the choice is not free. It is an obstacle course designed to make you give up.
The rule of thumb we use: refusing has to be as easy as accepting. Two buttons of the same weight on the same bar. If your bar has one button, it is broken, however good it looks.
3. Pre-ticked boxes
When a visitor opens the settings, "marketing" and "statistics" are often already on, leaving them to switch things off. That is the same mistake in reverse: no choice was made, a choice was made for them.
By default it is worth having everything switched off except what the site genuinely cannot work without: sign-in, a basket, a language preference. Analytics are not on that list, however useful they are to you. Whether yours needs consent in your particular setup is a question for a lawyer; all we check is whether it fires before the click.
4. Consent cannot be withdrawn
Once someone has pressed accept, they should be able to change their mind, and it is something we always check for. In practice that means a permanent link or a small button in the footer that reopens the bar.
Most sites do not have one, and the reason is technical rather than malicious: the bar was built never to come back after the first click. Nobody thought about the person who reconsiders three months later.
5. The cookie list is missing or out of date
A visitor who asks what exactly is stored and for how long should be able to find the answer on the page. The typical list was written when the site launched, names tools nobody has used in years, and does not mention the chat widget that was added last month.
It is also the easiest sign of whether anyone maintains the site at all. If the list names an old version of Google Analytics and a new one is running on the page, we know what we are going to find before we look any further.
6. The choice is never recorded anywhere
The bar asks, the person answers, the bar disappears. Nothing else happens. The choice stays in the visitor's browser, in a single cookie whose contents read "true". On your side there is no trace of it.
The mistake shows up the moment somebody asks one question: what did this visitor agree to, and when? If the only answer is "well, they must have accepted", there is no evidence. There is an assumption.
How to check it yourself: the same window, the "Application" tab, "Cookies". Find the entry with consent in its name: does it hold a time and the categories? The word "true" on its own reconstructs nothing later.
7. The bar is on one site, the scripts run on several
The bar went on the marketing site. But bookings run in a separate system, the shop is on another platform and the campaign page sits on an address of its own. Each of them loads its own scripts, and none of them was part of the job the bar was bought for.
A subdomain is technically a separate site, perhaps even in different hosting. To the visitor it is still yours.
How to check it yourself: write down every address a customer ends up on, and walk point 1 on each of them. Start with the one where payments are taken.
What is strictly necessary and what is not
Strictly necessary is not a judgement about importance. It means: without this, the visitor cannot do the thing they came to do. On one side:
- The sign-in session, without which the site throws the person out.
- The basket and the language preference.
- The consent record itself. If you were not allowed to remember that somebody refused, you would have to ask again on every page.
On the other side are the things that are useful to you but that nothing the visitor is doing depends on: analytics, including on your own server, heatmaps, the chat widget, advertising pixels and video.
The last one surprises almost everybody. An ordinary YouTube embed sets its cookies when the page opens, not when somebody presses play. The fix is cheap: use the address with nocookie in the domain, or an image that loads the player only on click.
Three things we see people assume
We are not going to tell you what is lawful, because that is not our competence. We will tell you what we check ourselves.
"We have a privacy policy link"
The assumption: a link in the footer covers it. What we check: the policy explains what happens, the bar asks whether it may. An explanation is not a question.
"We bought a ready-made banner, so we are covered"
The assumption: installing it fixes the matter. What we check: whether the bar is wired to anything. A bought banner has a setting that holds the scripts back until an answer arrives, and in our experience it is off by default.
"Our analytics are anonymised, so no consent is needed"
The assumption: if there are no names in the report, there is no question. What we check: whether that setting is genuinely on, because "anonymised" is a toggle rather than a property of the product; whether the tool still writes an identifier into the device; whether the data flows on to the advertising side. Which way that comes out for you, we will not say. But it is assumed far more often than it is checked.
If you are running Google Analytics
And you almost certainly are. In our experience it sits inside Google Tag Manager, in the theme header, or in the WordPress functions.php file. The bar and Tag Manager are separate worlds that know nothing about each other.
"But ours is anonymised" does not end the question, because the analytics still write their own cookie into the browser. Look in half a minute: private window, "Application", "Cookies", the entries whose names begin with _ga. If they are there before your click, the analytics fired before the answer. If only afterwards, the foundation is fine. Then check the advertising-related features too.
What actually happens when somebody complains
In our experience it does not start with an official at the door. It starts with a person writing: where did you get my email address.
The expensive part is not the fix. The expensive part is that there is no answer to be had: the email goes unanswered, and the second one is angrier.
We do not tell scare stories and we do not invent numbers. But two things are worth settling before that day: who answers, and whether anybody in the building knows what runs on the site. Ask sooner rather than later, us included.
What actually surprises us most
Not that sites are broken. That the owner does not know. Almost every time the answer is the same: "but the site was built for us and we were told everything was fine."
And usually it was fine. Then a chat widget was added. Then a new advertising pixel went on. Then the analytics were swapped. Each change was made on its own, each seemed trivial at the time, and nobody went back to check what now runs through the bar. Compliance is not a project that finishes. It is a thing that drifts.
The ten-minute self-check
Every check in this article in one sequence. On a computer, not a phone.
- Open the site in a fresh private window.
- Developer tools, "Network", reload the page. Press nothing on the bar.
- Filter for
google-analytics,gtm,facebook,hotjar. - The "Application" tab: are
_gaor_fbpalready there? - Is refusing the same size and the same distance away as accepting?
- Open the settings: is everything except the strictly necessary switched off?
- Press accept, then look in the footer for a link that brings the bar back.
- Look at what got saved into the consent record. Is there a time in it?
- Open the cookie list and compare it with what you saw in steps 3 and 4.
- Repeat steps 1 to 4 on the shop, the booking system and the subdomain. And find the video.
Points 2, 3 and 4 are usually an hour's work. Points 1, 6 and 7 depend on what sits underneath your site, and nobody can estimate those without looking. Five means nobody has looked at this site since it launched.
What to do about it
Most of these mistakes are invisible on the page, so start by measuring rather than guessing.
- The compliance audit is free and does points 1, 3 and 5 of this article by machine: which scripts fire before the click and which cookies land underneath them. Points 2, 4 and 6 you still have to look at yourself, because a machine cannot see the shape of the bar or what went into the consent record.
- If more than one thing needs fixing, that is work that belongs under web management. The whole point there is that somebody looks at these things regularly rather than once.
- And if your privacy policy has not been touched since launch, there is a good chance it describes an old situation too.
- The rest of the questions about how we work are answered on our frequently asked questions page.
One thing we always say: do not try to solve this by adding another bar to the page. Most of the problem lives in the order the scripts load, not in the bar itself.
Frequently asked questions
The bar is a consequence, and the question is what sits behind it. Consent means a person got to choose, and the choice has to come before the action, not after it. If the script has already run by the moment the bar appears on screen, the bar is not asking for consent, it is announcing something after the fact. That is why “we have a cookie bar” is never a sufficient answer: the first question is not whether the bar looks nice, but whether the page waits until the visitor has decided.
The rule of thumb we use: refusing has to be as easy as accepting, meaning two buttons of the same weight on the same bar. If yes is one click on a big coloured button, and no requires opening “Settings”, switching off three toggles and then pressing “Save”, the choice is not free. It is an obstacle course designed to make a person give up. If the bar has one button, it is broken, however good it looks.
Open your site in a fresh private window, so old cookies do not muddy the result. Right-click, choose “Inspect”, and go to the Network tab. Reload the page without pressing anything on the bar, then filter for google-analytics, gtm, facebook or hotjar. If you see requests going out, it is broken, and the check takes two minutes. The “Application” tab shows the same thing from the cookie side: whether _ga or _fbp are already there before your click.
Strictly necessary is not a judgement about importance. It means the visitor cannot do what they came for without it: the sign-in session, the basket, the language preference and the consent record itself. On the other side are things useful to you that nothing the visitor is doing depends on: analytics even on your own server, heatmaps, the chat widget, advertising pixels and video. The last surprises almost everybody: an ordinary YouTube embed sets its cookies when the page opens, not when somebody presses play.
Whether analytics need consent in your particular setup is a question for a lawyer, and not one we will decide for you. All we check is whether they fire before the click. “Anonymised” is a toggle rather than a property of the product, and the analytics still write their own cookie into the browser. Look in half a minute: private window, “Application”, “Cookies”, the entries whose names begin with _ga. If they are there before your click, the analytics fired before the answer.
Read next
Somebody filled in your contact form. A name, a phone number, an email and one box where people write more than you asked for. Most owners can say where that message landed. Far fewer can say who else got a copy of it, and how long it stays.