Skip to main content
Scanning

Does your “Reject all” button work? A practical cookie-banner test

Clicking “Reject all” is the start of a test, not the result. The useful question is what the website does next.

Passiro Placeholder[PUBLICATION DATE: set when published]

To test a cookie banner, compare browser storage, outgoing requests and consent signals across four states: before a choice, after rejection, after acceptance and after withdrawal. Use a fresh browser session for each independent journey, and record which setup you expect to see.

This guide is for website owners and marketers working with a technical colleague. It focuses on a European opt-in setup. If you use Advanced Consent Mode, some Google requests may be expected with consent denied; a request alone does not prove a fault. Our Basic versus Advanced guide explains that distinction.

Write down the expected behaviour first

List the tools on the site: analytics, advertising pixels, embedded video, chat, booking widgets and any server-side destinations. For each, note its purpose and the choice that should control it.

Keep the test small enough to run again. Start with a landing page, a product or service page and the conversion journey. Include the page where a visitor actually submits a form or completes an order. A clean home page does not tell you what happens at checkout.

Illustration titled “Test the whole consent journey”: four steps in a row, 01 Fresh visit (no choice yet), 02 Reject (optional off), 03 Accept (selected uses on) and 04 Withdraw (future use changes).
A compact test path covers a fresh visit, rejection, acceptance and withdrawal, with storage and requests checked at every stage.

Test 1: arrive without touching the banner

Open a fresh browser profile or clear the site's stored data. Disable unrelated extensions for the baseline test. Open developer tools before loading the page, then examine the Network and Application panels.

  • Record cookies and other relevant browser storage created on arrival.
  • Inspect requests to analytics, advertising and embedded-service domains.
  • Note which request belongs to which tool rather than treating every third party as advertising.
  • Save the URL, browser, test region and the expected consent mode with the result.

Chrome documents how to inspect network activity and view cookies. Use those views together: an empty cookie list is not proof that no data left the browser.

Test 2: reject optional cookies

Reject, browse to another page and trigger an ordinary interaction, such as opening a video or viewing a product. Compare the result with your inventory.

Illustrative example: an analytics tag behaves as intended, but a remarketing pixel still sends a page-view request. The pixel was installed in the website theme, while the consent rules were configured only in Google Tag Manager. The fix is to control the theme-installed pixel too. Changing the button label will not solve it.

Use Google Tag Assistant's consent checks to inspect Google consent states. Treat this as one part of the test; it does not replace checking the rest of your stack.

Test 3: accept a specific category

Start again and allow analytics while leaving marketing off, if your banner offers that choice. Check whether each tool follows its own category.

A common implementation mistake is using one broad “accepted” event to start every tag. Granular controls in the interface are useful only if the implementation preserves the distinction.

Repeat with full acceptance. Confirm that an allowed conversion event appears once, with the correct value and currency, rather than firing both on consent update and again on the next page event.

Test 4: withdraw and revisit

After accepting, reopen cookie settings and withdraw the optional permissions. Trigger another page view and repeat the relevant interaction.

Check that future behaviour changes and that the choice survives navigation as intended. Inspect existing cookies separately: stopping future requests and removing previously stored information are different operations. A website cannot simply delete every cookie held by another domain.

Also test a fresh visit after the saved choice expires or is reset. Do not assume that the state used in your first test will always be present.

Keep an actionable record

For each failure, capture expected behaviour, observed behaviour, the affected tool, its installation location and a person responsible for the fix. Avoid saving unnecessary personal data in screenshots or network exports.

Repeat the affected tests after a repair. Add this review to launches that introduce a new plugin, pixel, checkout or chat tool. For a broader handover process, use the agency launch checklist.

Two quick questions

Does a cookie scan replace this test?

No. A scan helps find cookies and trackers in the pages and conditions it visits. Interactive journeys can reveal additional behaviour. See scanning versus blocking.

Should rejection mean zero network requests?

No. The website needs requests to work. Evaluate their purpose, payload and consent requirements. Advanced Google Consent Mode can also send cookieless measurements while relevant consent is denied.

Passiro Free includes monthly scans of up to 500 pages, automatic script blocking and Google Consent Mode v2. Use those tools alongside a tested website setup. Get Started.

Put the tools to work.

Passiro includes a cookie banner, scanning, analytics and Google Consent Mode v2 on a lasting Free plan.