The rule, in one paragraph
In the EU and UK, the ePrivacy rules require consent before storing or accessing information on a user's device, unless that storage is strictly necessary to deliver a service the user explicitly requested. The GDPR then governs what you do with any personal data involved. Note what this means: the rule is about storage and access on the device, not about cookies specifically — local storage and similar techniques are covered too.
So the question is not "do I use cookies", it is "do I store or read anything on the visitor's device that is not strictly necessary".
The decision tree
1. Do you store or read anything on the visitor's device?
If genuinely nothing — no cookies, no local storage, no device fingerprinting, no third-party embeds doing it on your behalf — you do not need a consent banner. You still need a privacy policy.
2. Is everything you store strictly necessary?
Strictly necessary generally covers: session cookies that keep a user logged in, a shopping cart, a load balancing token, a security or fraud prevention token, and the cookie that records the consent choice itself. These are exempt from consent.
3. Is anything else in there?
Analytics, advertising, A/B testing, heatmaps, embedded video that sets cookies, chat widgets, social share buttons that track. All of these generally require consent before they run.
What most sites actually have
Run your own site through a browser's storage inspector in a private window and look at what appears before you click anything. The common finding is that a site has one genuinely necessary cookie, an analytics cookie, and three or four set by embeds nobody remembers adding — a font provider, a video player, a chat widget, a map.
Each of those embeds is a separate decision you are making on your visitors' behalf.
The mistakes that make a banner worthless
- Loading trackers before consent. By far the most common failure. The banner appears, but the analytics call already fired. In that configuration the banner provides no protection at all and demonstrates that you knew consent was required.
- No genuine reject option. A prominent "Accept all" and a "Manage preferences" link that leads to a maze does not meet the standard that refusal must be as easy as acceptance.
- Pre-ticked boxes. Consent must be a positive action.
- Cookie walls. Making access conditional on accepting tracking is, in most interpretations, not freely given consent.
- A banner that lies. If the text says "we use cookies to improve your experience" and the reality is twelve advertising trackers, the consent is not informed.
The option people forget
You can remove the requirement instead of managing it. If analytics is the only non-essential technology on your site, switching to a cookieless analytics tool that stores nothing on the device generally removes the need for an analytics consent banner entirely.
The side effects are pleasant: no interstitial for visitors, no consent-mode gymnastics, and complete data rather than data from the subset of people who clicked accept.
This only works if analytics really is the only thing. Audit first — the embeds are what catch people out.
Outside the EU
Requirements differ substantially by jurisdiction, and several US states have their own privacy laws with different mechanics, generally built around notice and opt-out rather than prior consent. If you have EU or UK visitors, though, EU rules are in scope regardless of where you are based.
A five-minute audit
1. Open your site in a private window with the developer tools storage panel open.
2. Note everything set before you interact with the page.
3. For each item, write down what it does and whether it is strictly necessary.
4. Remove what you do not need. This step usually deletes more than you expect.
5. Decide, for what is left, between consent and replacement.
None of this is legal advice; for a binding answer on your specific setup, consult a qualified lawyer.