Your cookie banner looks fine. Does it actually work?

Written By Sonny Chadwick
Zwaddo insights · Cookie consent

A visitor clicks “Reject”. The banner disappears. But what happens behind the page?

By Zwaddo · Practical guide · 5-minute read

Cookie preference controls beside a privacy shield, with open and closed gates representing controlled data flows.
The useful question is whether the visitor’s choice changes what the website does.

Imagine a campaign page with a smart consent banner, a video embed and a booking form. The banner remembers a rejection, but the video starts its own tracking when someone presses play. The visible interface looks finished. The integration still needs attention.

This is why a consent review should follow behaviour, not stop at a screenshot. Before replacing your platform or rewriting the banner, test the gap between the choice people make and the technology that runs.

Start with the right scope

UK rules cover more than cookies. Identify the purpose of each storage or access technology and assess whether an exception applies. Some uses can qualify without consent, subject to conditions; “analytics” is not a blanket exemption. Personal-data processing also needs a separate UK GDPR assessment. See the ICO’s guidance on exceptions.

Watch what happens before the first click

A banner can arrive after another script has already started.

Start a fresh browser session and open a representative page. Have your developer record storage changes and network activity before touching the banner. Compare what appears with your technology inventory.

A request to another domain is a lead to investigate, not automatic proof of a breach. Check its purpose, what it sends and whether it stores or accesses device information. Equally, an empty cookie list does not prove that no other tracking exists.

Evidence to keep

The page, time, browser, consent state and relevant request or storage entry. Redact personal data before sharing test evidence.

Make rejection a complete journey

For technologies requiring consent, the ICO expects refusal to be as easy as acceptance, and the mechanism must respect the resulting choice. Closing a banner or continuing to browse is not an affirmative opt-in. Read the ICO’s consent expectations.

Test the rejection route on both desktop and a phone. Then use the page: open a video, follow a link and try the booking form. A control that saves a preference is only one part of this test.

Try this first

Choose rejection and repeat the same interactions used in your first-visit test. Investigate any technology that behaves identically despite requiring consent.

Try a mixture of preferences

“Accept everything” works. Individual choices tell a different story.

Choose one purpose and leave the others off. Repeat with a different combination. This can expose a single “consent granted” flag that starts integrations from several categories, or a tag assigned to the wrong group.

Use plain descriptions of the purposes and suppliers involved. The names in your settings should help the person making the choice and the person checking the implementation.

Question for your team

Can we point from each preference to the actual integrations it controls, and explain what should happen when it is off?

Test the choice, the page and the next interaction.

Change your mind after accepting

The ICO says withdrawal must be as easy as giving consent. Provide an accessible way to revisit preferences and make sure the underlying implementation responds.

Accept in a test session, use a feature, then withdraw. Check what stops, what stored information is removed where required, and what happens after reload. A toggle changing colour is not enough evidence.

Be careful with cleanup: indiscriminately deleting every cookie may break login or other necessary functions. Map the affected technologies and use the relevant integration controls.

Try this first

Ask someone unfamiliar with the site to find the preference controls after the banner has gone. Watch where they look and whether they can complete the change.

Retest when someone adds a tool

Consent behaviour can change when marketing adds a tag, a developer replaces a component or an editor embeds a new service. Give one person ownership of the inventory and make a consent check part of the release process.

Ask what the new integration does before deciding how it should load. Update the relevant information and configuration, then repeat the affected journeys. A scan from last month cannot describe a tool added yesterday.

Keep the handover simple

For every new integration: name an owner, document its purpose, record the consent or exception assessment and attach the test result.

A practical checklist for your next review

For each important page or journey, record these five states:

  1. No choice yet: capture the initial behaviour.
  2. Rejected: interact with the page and reload.
  3. Selected purposes: try at least two combinations.
  4. Accepted: confirm the intended features work.
  5. Withdrawn: check the change and the return visit.

Keep a short result for each: expected behaviour, actual behaviour, evidence and owner. Label anything unexplained as needing investigation rather than guessing that it passes.

Sources and scope

This is a practical testing guide, not a determination that a particular website complies. Requirements depend on the technologies, purposes and applicable rules. Guidance checked September 2026.

Sonny Chadwick
Previous

Your accessibility scan passed. Why are customers still getting stuck?
Next

7 Experience Cloud problems that frustrate customers—and how to fix them