Fixing Cookie Consent Banners
A cookie banner is the first thing most visitors meet on your site, and it is also the part of data protection that anyone can check in seconds.
Banners fail for predictable reasons: an Accept button with no matching Reject, optional boxes already switched on, vague wording, no way to change a choice later, or no record of what was agreed. This guide covers the design and behaviour of the banner itself: what it must offer, how to configure the common tools, and how to prove it works. It is general information, not legal advice.
- What the rules actually ask of a banner
- What the Data (Use and Access) Act 2025 changes
- Banner patterns that fail, and what to use instead
- Setting it up on common platforms
- Cookie walls and "consent or pay"
- The fix, step by step
- Consent records: what to keep and for how long
- Keeping the banner compliant
- Questions and answers
What the rules actually ask of a banner
Two pieces of UK law meet on your banner. The Privacy and Electronic Communications Regulations, PECR, say you may only store information on someone's device, or read information from it, if they have agreed, unless an exemption applies. That covers cookies, but also local storage, pixels and similar technologies. The UK GDPR then defines what agreement means: consent must be freely given, specific, informed and unambiguous, given by a clear positive action, and as easy to withdraw as to give.
Put together, the ICO's guidance on storage and access technologies turns those words into practical tests a banner either passes or fails:
- Positive action. Scrolling, continuing to browse or closing the banner is not consent. The visitor must click something that clearly means yes.
- Genuine choice. Refusing must be as easy as agreeing. A one-click Accept with a Reject hidden behind "Manage settings" does not give an equal choice.
- Nothing pre-selected. Optional categories start switched off. A toggle that is already on is not consent, even if the visitor could turn it off.
- Informed. The visitor can see what each category does and which third parties are involved before choosing.
- Granular. Different purposes, such as analytics and advertising, can be accepted or refused separately.
- Reversible. A choice can be changed later without hunting for it.
This guide is not legal advice. It describes common, practical ways of meeting the ICO's published guidance. If your site targets children, uses cookies for sensitive purposes, or you are unsure how a rule applies, take advice from a solicitor or data protection specialist.
What the Data (Use and Access) Act 2025 changes
The Data (Use and Access) Act 2025 amends PECR. Among other things, it widens the list of purposes where storage or access does not need consent. As the government and the ICO describe it, the new exemptions cover some low-risk uses, such as collecting statistics to improve a site or service, remembering a visitor's chosen appearance or functions, security, and locating someone in an emergency, each with conditions attached. For the statistics exemption, the conditions include telling people clearly what happens and giving them a simple, free way to object.
Be careful with this in practice:
- The Act's provisions are being brought into force in stages. Check the ICO's current guidance for whether, and in what form, an exemption applies on the day you rely on it.
- The analytics exemption is about first-party statistics used to improve your own service. It is not a general exemption for every analytics product, and it is unlikely to cover tools that share data with a vendor for its own purposes or combine it with advertising.
- Advertising, retargeting, cross-site profiling and social media pixels still need consent.
- Where you rely on an exemption, you still need to explain it, usually in the banner's details layer and in your cookie policy, and offer the opt-out where the conditions require one.
The Act also raises the maximum penalties under PECR to the same level as the UK GDPR, which makes cookie compliance a larger risk than it used to be for sites that ignore it.
Banner patterns that fail, and what to use instead
| Pattern found | Why it fails | Replace it with |
|---|---|---|
| "By using this site you agree to cookies" with an OK button | No choice at all, and continued use is not a positive action. | Accept all and Reject all buttons on the first layer. |
| Large coloured Accept, grey text link for Settings | Refusing takes more clicks and is visually downplayed. | Two buttons of the same size, weight and contrast. |
| Toggles for Analytics and Marketing already on | Pre-ticked options are not valid consent. | All optional toggles off until the visitor switches them on. |
| Closing the banner with the X counts as Accept | Dismissing is not a clear yes. | Treat closing as no choice or as refusal, and set nothing optional. |
| "Legitimate interest" switches on by default inside settings | PECR consent cannot be replaced by legitimate interests for cookies that need consent. | Remove the legitimate interest toggles for storage and access, or set them off. |
| Banner covers the page and blocks reading until Accept | A cookie wall can make consent not freely given. | Let people read after refusing; see the section on cookie walls. |
| No link to change settings after the first visit | Withdrawing is harder than giving consent. | A persistent footer link or floating button that reopens the preferences. |
Wording matters too. Buttons labelled "Yes, I'm happy" and "Let me choose" read as unequal choices. Plain labels such as Accept all, Reject all and Manage preferences are clear and hard to argue with.
Setting it up on common platforms
WordPress
Most WordPress sites use a consent plugin that both shows the banner and blocks scripts by category. Whichever plugin you choose, check four settings after installing it: that the Reject button is enabled on the first layer, that no optional category defaults to on, that the plugin's script blocking is switched on rather than only the banner, and that caching plugins are not serving a cached page with the banner state baked in. Clear the page cache after every change to the banner.
Shopify
Shopify has its own customer privacy settings and a customer privacy API that apps and themes can
read. You can use Shopify's own cookie banner or an app from the App Store that integrates with that
API. The important check is that marketing and analytics apps respect the consent signal. Apps and pixels
added through Shopify's customer events settings can be tied to consent categories; code pasted into
theme.liquid cannot, and needs moving.
Custom and static sites
For a hand-built site, a hosted consent management platform, known as a CMP, is usually quicker and
more reliable than writing your own. You add one script as high as possible in the <head>,
configure the categories and banner in the CMP's dashboard, and mark your other scripts so they wait
for consent. If you do write your own, it must at least store the choice, show the banner again when
the categories change, and never load optional scripts before a choice is made.
Sites using Google Tag Manager
Many CMPs offer a Tag Manager template that sets default consent states and updates them after the visitor chooses. The banner and the tags then share one source of truth. The details of making tags wait are covered in our guide to fixing tracking before consent, so this guide stays with the banner itself.
Cookie walls and "consent or pay"
A cookie wall blocks access to content unless the visitor accepts cookies. The ICO's view is that making access conditional on accepting non-essential cookies is unlikely to give valid consent in most cases, because the visitor has no real choice.
Some publishers offer a different model: accept advertising cookies, or pay a small fee for an ad-free version without tracking. The ICO has published guidance on this "consent or pay" approach. It indicates the model can be lawful in some circumstances, depending on factors such as the balance of power between the site and its users, whether the fee is reasonable, and whether the choice is presented fairly. It is not a simple design tweak, and a small business thinking about it should read that guidance in full and consider advice first.
For most small sites, the answer is simpler: let everyone use the site whatever they choose on the banner, and accept that some visitors will refuse.
The fix, step by step
Step 1
List every cookie and storage item
Open the site in a fresh private window, accept everything on the banner, then browse a normal journey: home page, a content page, a form, the basket or account area. In the developer tools Application panel, copy each cookie, local storage key and session storage key into a spreadsheet with its name, domain, lifetime and the script that set it. Include items set by embedded video, maps, chat widgets and fonts, which are easy to miss.
Step 2
Sort them into necessary, exempt and consent-only
Mark each item as strictly necessary for something the visitor asked for, such as a login session, basket, load balancing or remembering the consent choice itself; possibly exempt under the newer PECR exemptions, only after checking the ICO's current guidance and conditions; or consent needed, which covers advertising, social pixels and most third-party analytics. When an item is borderline, put it in the consent group rather than assuming an exemption.
Step 3
Choose or reconfigure your consent tool
Pick one consent management platform or plugin and remove any other banner code from the
theme, header scripts and Tag Manager. Load its script first in the <head>, before
any analytics or advertising code. Create categories that match your spreadsheet, for example necessary,
statistics, preferences and marketing, and assign each cookie to one. Switch on the tool's script blocking
or Tag Manager integration, not just the visible banner, and clear all page caches.
Step 4
Rebuild the first layer of the banner
Put Accept all, Reject all and Manage preferences on the first screen, with Accept and Reject the same size, colour weight and contrast. Write a two-sentence summary saying what the optional cookies are for and who sets them. Make closing the banner set nothing optional. Check the buttons work by keyboard, are announced properly by a screen reader, and do not push the Reject button off the screen on a small phone.
Step 5
Write clear category descriptions and a cookie policy
In the preferences layer, give each category a plain description of its purpose, the providers involved and whether data leaves the UK, with every optional toggle switched off. Then publish a cookie policy listing each cookie from your spreadsheet with its provider, purpose and lifetime, and explaining any exemption you rely on together with the way to object. Link the policy from the banner, the footer and the privacy policy so visitors can find it.
Step 6
Add a permanent way to change or withdraw consent
Add a Cookie settings link to the site footer, or a small floating button, that reopens the preferences layer on every page. When a visitor withdraws consent, the tool should stop the scripts and, where it can, delete the cookies those scripts set. Set the banner to ask again when you add a new category or provider, and at a sensible interval such as every six to twelve months rather than on every visit.
Step 7
Record consent and test every path
Make sure the tool keeps a consent record for each choice: an identifier, the date and time, the categories accepted, and the banner version shown. Then test three journeys in separate private windows: reject all, accept all, and accept only statistics. After each, check the cookies and network requests match the choice, then run the GDPR Audit again and confirm the banner finding has cleared.
Consent records: what to keep and for how long
Under the UK GDPR you must be able to show that someone consented. For cookies, that does not mean storing a name or email address. A good consent record holds just enough to prove what happened:
- A random consent identifier, stored in the visitor's own consent cookie so the record can be matched later.
- The date and time of the choice.
- The categories accepted and refused.
- The version of the banner and cookie policy shown at the time.
- How the choice was made, for example the Reject all button or the preferences screen.
Most hosted CMPs keep this log for you and let you export it. If you build your own, store the record on the server rather than only in the browser, and keep it for a defined period that you state in your cookie policy. Avoid putting full IP addresses in the log unless you need them; a truncated address or none at all is usually enough.
Keeping the banner compliant
- Treat new tools as banner changes. Adding a chat widget, heatmap, video host or advertising pixel should always include a step to update the cookie inventory, category and policy.
- Scan after every release. Theme updates and plugin updates can add scripts outside your consent tool. Run the GDPR Audit after significant changes.
- Test on mobile. Many banners are compliant on desktop and broken on a phone, where the Reject button falls below the fold or the preferences layer cannot scroll.
- Keep the cookie policy dated. Show when it was last reviewed, and review it at least once a year.
- Watch the rules. The PECR changes from the Data (Use and Access) Act 2025 are arriving in stages, and the ICO updates its guidance as they do.
1. Do I need a Reject all button on the first layer of my cookie banner?
The ICO's guidance says refusing should be as easy as accepting, and it has written to many website operators whose banners made rejecting harder. In practice that means putting Reject all on the first layer next to Accept all, at the same size and prominence. A banner that offers one-click acceptance but makes people open a settings panel and switch off categories one by one is very likely to be treated as not offering a genuine choice.
2. Can I show a cookie banner that just says "OK" or "Got it"?
Not if your site sets any cookies that need consent. A banner with a single acknowledgement button gives visitors no choice, and continuing to use the site is not a clear positive action. If your site genuinely sets only strictly necessary cookies, you do not need a consent banner at all, though you should still explain those cookies in a cookie policy. Most sites with analytics or advertising need a real Accept and Reject choice.
3. Do strictly necessary cookies need consent?
No. Cookies that are strictly necessary to provide something the visitor has asked for are exempt from the consent requirement under PECR. Typical examples are a login session, a shopping basket, security cookies, load balancing and the cookie that remembers the visitor's consent choice. You must still tell people about them, usually in the cookie policy. Something being useful to you, such as analytics or advertising, does not make it strictly necessary for the visitor.
4. Are analytics cookies now exempt from consent in the UK?
Some may be. The Data (Use and Access) Act 2025 adds exemptions to PECR, including one for collecting statistics to improve a website or service, subject to conditions such as clear information and a simple, free way to object. The provisions are coming into force in stages, and the exemption is narrow. Check the ICO's current guidance before relying on it, and keep analytics that share data for a vendor's own purposes, or feed advertising, behind consent.
5. How often should the cookie banner ask returning visitors again?
There is no single fixed period in the law. Common practice is to remember the choice for somewhere between six and twelve months, then ask again, and to ask sooner whenever you add a new category or a new third party that the original choice did not cover. Asking on every visit is annoying and unnecessary, while remembering a choice indefinitely risks relying on consent to things the visitor never saw described.
6. Is a free cookie banner plugin good enough?
It can be, if it is configured properly. What matters is behaviour, not price: a Reject all button on the first layer, optional categories off by default, script blocking that really stops tags until consent, a settings link for changing the choice later, and a consent record. Many free plugins offer these features but do not switch them all on by default, so check each setting and test the result in a private window.
7. Can I stop people using my site if they reject cookies?
Generally that is a cookie wall, and the ICO's view is that making access depend on accepting non-essential cookies is unlikely to produce valid consent in most cases. The ICO has published separate guidance on consent or pay models, where visitors can pay for a version without tracking, which may be acceptable in some circumstances. For a typical small business site, the safest approach is to let everyone use the site whatever they choose.
The GDPR Audit checks what a visitor can see, including the cookie banner and the scripts that load before consent, and lists each finding with the guide that fixes it.
Open GDPR Fixes →