You need a cookie banner only for storage your site does not strictly need

You added a cookie banner because every other site has one. Now it sits on top of your first screen, and it is the first thing a new visitor has to deal with. The people who decline drop out of your analytics anyway. So do you need a cookie banner on your website at all? The answer depends on what your site stores on the visitor’s device, or reads from it. It does not depend on the word cookie. This site has no banner, and it still counts its visitors.

This is how I read the rules and built my own site. It is not legal advice.

The rule is about the visitor’s device, not about cookies

In the UK, the rule is regulation 6 of the Privacy and Electronic Communications Regulations, known as PECR. A site may not store information on a visitor’s device, or read information already stored there, unless a condition in Schedule A1 applies. Causing the storage or the access counts too. The main condition is consent, given after clear and comprehensive information about the purpose.

The ICO’s guidance lists what that covers: cookies, tracking pixels, link decoration, device fingerprinting, web storage, and scripts and tags. Local storage is in the list, so moving a tracker out of a cookie changes nothing. The rule covers any information, not only personal data, and it covers what the tools you embed from other companies set on your pages.

In the EU, the rule is Article 5(3) of the ePrivacy Directive. Storing or reading information on the device needs consent, after clear and comprehensive information, unless an exemption applies. The European Data Protection Board reads it widely in Guidelines 2/2023 on its technical scope, version 2.0, adopted 7 October 2024. On that reading, it covers personal and non-personal information, whoever stored it. Tracking pixels and tracking links are in scope. So is JavaScript that tells the browser to send information back to a server.

Strictly necessary storage needs no consent

Both laws exempt storage that is strictly necessary to give visitors the service they asked for. Paragraph 4 of Schedule A1 gives examples: protecting information, keeping the device secure, preventing fraud or technical faults, signing the visitor in, and keeping a record of selections they made on the site. The ICO judges strict necessity from the visitor’s point of view, and says advertising never meets it. Article 5(3) has the same exemption in its own words, and one more for storage needed only to carry a communication across the network.

So a security check, a basket or a login session needs no consent. Counting visitors is not on that list, because nobody visits a site to be counted. That is why the UK needed a new exception for it.

Since February 2026, the UK lets you count visits without consent, on conditions

Section 112 of the Data (Use and Access) Act 2025 replaced regulation 6 and added Schedule A1. It came into force on 5 February 2026, through S.I. 2026/82. Paragraph 5 of Schedule A1 now allows storage or access without consent when all of these hold:

• The sole purpose is to collect statistics on how the site is used, so you can improve it.
• The information goes to nobody else, except someone helping you make those improvements.
• The visitor gets clear and comprehensive information about the purpose.
• The visitor gets a simple, free way to object, and has not objected.

The ICO’s final guidance, published on 29 April 2026, fills in the detail. The output must be aggregate and must not identify anyone. Page visit counts, scroll depth, device types and referral sources are likely to qualify. Individual visitor logs, session recordings and anything for advertising are not. An outside tool can do the counting only as your processor, using the data for nothing else.

So in the UK, analytics no longer needs a banner, but it still needs an explanation and a way to object. The ICO’s example is a switch, on by default, that the visitor can turn off at any time. A tag that also serves advertising gets no exception.

The EU has no analytics exception yet

Article 5(3) has two exemptions only: carrying a communication, and strict necessity. The EDPB’s guidelines leave the exemptions alone on purpose. They say each case depends on the member state’s own law and its regulator’s guidance.

In November 2025 the European Commission proposed a Digital Omnibus that would, among much else, let sites count visits and measure their audience without consent pop-ups. I could not confirm that it has become law. Until it does, I work to Article 5(3) as it stands. For EU visitors, a typical analytics tag that sets a cookie or reads storage needs consent, unless your national regulator says otherwise.

This site counts visitors with nothing stored in the browser

This site’s only analytics is a page counter I wrote into the theme. When a page loads, a few lines at its foot send one request to the site’s own server, carrying the page’s address and a signature of that address. The server printed that signature into the page when it built it. It is an HMAC, made with a secret only the server holds. It checks the signature on arrival, so nobody can count a page that never existed. If it matches, the server adds one to that page’s count for the day.

The table has three columns: day, path and views. There is no cookie, nothing written to the browser’s storage, no IP address and no identifier of any kind. Searches, 404 pages, previews and my own signed-in visits are not counted.

There is no banner, because nothing the site does by itself needs consent. The cookie policy explains why. It lists everything that can touch a visitor’s storage, and the list is short:

• The light or dark choice, saved only when someone clicks the toggle.
• The cost calculator’s figures, kept in session storage only when someone asks for the breakdown by email.
• Cloudflare, which carries every request, can set a short-lived security cookie to tell people from bots. That is strictly necessary.
• Nothing from the booking calendar. The site draws the calendar itself and asks only its own server for the free times, so the browser never loads Cal.com’s script. The booking goes to Cal.com from the server.

The server’s access log is not storage on the device. The privacy policy covers it.

The one open question is whether a beacon counts as access

My reading is that the counter stores nothing and reads nothing of the visitor’s. It sends back only the address and the signature that the server itself just put in the page.

The EDPB reads access more widely. In its view, a script that makes the browser send information back is enough, whoever stored that information first. On that reading, the beacon may be in scope in the EU. Whether page counting then fits an exemption is for each national regulator to say. The ICO has not said whether a first-party beacon like this one counts. If it does, the UK route is the statistical purposes exception, which also asks for a simple way to object. The site does not offer one for the counter today, and adding one is a small job.

That point is unsettled. I would rather tell you so than claim a certainty nobody has.

A count per page per day cannot tell you where anyone came from

A count per page per day is all the counter knows. It cannot see sessions, so it cannot tell one visitor reading five pages from five visitors reading one. It cannot see sources, so it does not know which search or which link brought anyone in. It cannot follow anyone from a guide to the contact page, so there are no conversion paths. And a script that reloads a real page can inflate its count. Stopping that would need the visitor’s address, which is the one thing the counter refuses to keep.

I took that trade on purpose. I sell to people who notice, the kind who open the developer tools on a supplier’s site before they book a call. A banner on a studio’s first screen would be the first thing they judge, and a clean storage panel says more than any claim on the page. Data I never collect cannot leak, cannot be requested and needs no retention schedule. And if I want to know what brought a buyer in, I can ask them on the call.

Find out what your site stores before you decide about the banner

1. List what each tool stores. Open the site in a fresh private window with the browser’s storage panel open. Note every cookie and storage key, and which tool set it. The ICO’s compliance chapter asks you to identify what your service uses, and which third parties set anything.
2. Drop what nobody reads. A tag from an old campaign, a pixel for an ad account nobody runs, a chat widget nobody answers. Each one is storage you have to explain, and code every visitor downloads.
3. Move what remains first-party, and cookieless where you can. Serve fonts and scripts from your own domain. Count pages on your own server. Load calendars, maps and videos only when the visitor asks for them, or draw them yourself from the provider’s API, as this site now does with its booking calendar.
4. Then decide. If everything left is strictly necessary, you need no banner, but you still owe clear information in a cookie policy. If UK analytics rests on the statistical exception, explain it and give a simple way to object. If you run advertising or cross-site tracking, or an analytics tag that sets storage for EU visitors, you need consent, and a banner is the honest way to ask.

If you would rather I went through it, the audit covers the whole site and where its data goes. The clean-up is part of web presence work.

One test this week shows what your banner is really for

Open your site in a private window. Open the developer tools and go to the Application panel, or Storage in Firefox. Load three pages, and do not touch the banner. Then write down every cookie and every storage key you see. In the Network panel, note every request to another company’s domain.

Anything on that list that is not strictly necessary was set before anyone agreed to it. Either the banner is not blocking it, or the site does not need it. Either way, you now know what the banner is really for.