What Happens After “Reject All”? A Practical Cookie Banner Test

Practical testing guide · Published 27 September 2026 · By John Cookie

A Reject All button can look reassuring while leaving important questions unanswered. The useful test is what changes after the click, whether the choice survives navigation, and whether the visitor can change it later.

Start with a clean, documented test

Use a dedicated browser profile so previous consent and extensions do not confuse the result. Record the browser and version, device, date, tested URL, region and whether you are logged in. Note privacy settings that might block requests independently of the banner. A phone-sized desktop window helps check layout; it does not replace a test in a real mobile browser.

List the pages and interactions you will cover. A sensible first pass includes the homepage, a contact or lead form, a page with embedded media and any booking or checkout route. Avoid submitting real orders or enquiries as part of a routine check.

Test the visitor journey in four stages

1. Before making a choice

Open Chrome DevTools and its Network panel before reloading the page. This records requests from the start of that visit. Review request destinations and timing. In Application → Storage → Cookies, inspect the listed origins and record relevant cookie names and domains. Keep a screenshot of the untouched banner alongside the technical observations. Google documents the Network panel and cookie inspection controls.

Do not classify a request from its name alone. Identify the supplier and purpose, then compare what you observed with the intended configuration. Include an “unresolved” status when you cannot establish the purpose.

2. Immediately after Reject All

Select the rejection control and record the time. Check the saved preference, new requests and any new or changed storage. Navigate to another page and reload it. Does the choice remain in effect? Does the banner’s wording match what was actually disabled?

A cookie used to remember the rejection is a different observation from an advertising identifier. Similarly, a request to a Google domain needs interpretation; it is not, by itself, proof that the banner failed.

3. After acceptance in a separate clean run

Start another clean test and choose acceptance. Compare the same pages and interactions. This helps establish whether consent produces a meaningful change. Keep each run’s notes separate so you do not mistake a cookie from an earlier accepted session for a cookie created after rejection.

4. After withdrawing consent

In the accepted session, reopen the preferences and withdraw the relevant choices. Check that the saved setting changes and subsequent behaviour responds. Navigate and reload again. Record what happens to existing cookies as well as new activity; the continued presence of a stored value is not enough to establish whether it is being read or used.

The ICO explains that withdrawal should be as easy as giving consent and that people should be able to exercise it through the consent mechanism. Read its practical consent guidance.

Why Google requests need closer inspection

Google distinguishes basic Consent Mode, where Google tags are blocked when consent is not granted, from advanced Consent Mode, where denied states can still produce measurements without cookies. Therefore “a request exists” and “an analytics cookie was written” are different findings. Check the consent state, request contents, timing and intended implementation before drawing a conclusion. Google’s technical documentation does not itself establish that a particular deployment meets UK law. Google’s Consent Mode overview.

Where you have authorised access, use Tag Assistant and the tag configuration to investigate the sequence of consent defaults and updates. Read our Consent Mode guide for background, or discuss the scope of a Consent Mode audit.

Write findings your developer can reproduce

Use consistent labels: observed, needs investigation and not tested. State the tested pages and conditions. A reproducible narrow finding is more useful than a site-wide “compliant” badge based on one visit.

Start with the free checklist and read what scanners can and cannot tell you. If you are reconsidering which controls your site needs, see the September 2026 UK cookie rules review.

About the author: John Cookie is the pen name of a digital marketer with 20 years’ experience. These articles explain practical website observations and testing methods; they are not legal advice or compliance certification. Read about John and the review approach.