# The Reject Button That Does Not Survive Navigation

Source: https://cookiebastion.com/blog/2026-11-11-reject-choice-lost-navigation.html

[Home](../index.md) / [Blog](index.md) / The Reject Button That Does Not Survive Navigation


Published 2026-11-11

A visitor rejects tracking on the homepage, clicks to a product page, and the banner pops up again. They reject again. They click to the cart, and the banner pops up a third time. The site recorded the rejection each time. It just never read it back. The visitor did everything right, and the site asked them the same question three times in one visit.

A consent choice that does not survive navigation is not a choice. It is a form the visitor fills in and the site throws away. The usual cause is boring and fixable: the consent cookie is scoped to one path or one subdomain, so the next page cannot see it, or the consent platform re-initializes on every page load and overwrites the stored state with a blank one.

## Where the choice gets lost

The first failure is cookie scope. A consent cookie set with a path of /blog is invisible to /shop, and a cookie set on www.example.com is invisible to example.com. The visitor rejects on the blog, the shop sees no cookie, and the banner appears again. The fix is to set the consent cookie on the parent domain with a root path, so every page on every subdomain can read it. The SecurePrivacy audit guide lists cookie scope as one of the first things an audit checks, because a consent record that only exists on one page is not a record the site honors.

The second failure is re-initialization. Some consent platforms, when they load on a new page, write a fresh default state before reading the stored one. The stored rejection is there, in the cookie, but the platform overwrites it with denied-by-default and then treats the visitor as unasked. The banner appears, the visitor rejects again, and the log records two rejections for one visit. The CookieYes troubleshooting guide describes this pattern as a configuration error: the platform must read the stored state before it writes anything, and any tag that fires in between is running on a blank state.

## The test that finds it

Reject everything on the homepage, then navigate to three other pages: a product page, a different subdomain if the site has one, and the checkout. The banner should not appear again. The network tab should show no new consent cookie being written. If the banner reappears, or a second consent cookie is set, the choice is not surviving navigation, and the site is re-asking visitors who already answered.

Run the same test with the back button, because the back-forward cache is a separate failure. A page restored from the cache can show a stale banner state, or re-run the consent script as if the visit were new. The bfcache behavior varies by browser, which is why the test has to be run in more than one. A consent system that works in Chrome and fails in Safari is not a consent system. It is a Chrome feature.

## What the fix looks like

Set the consent cookie on the parent domain with path /. That one change fixes most cases. Then check the platform configuration for a read-before-write order: on every page load, the platform reads the stored state first, applies it, and only prompts if no stored state exists. If the platform has a setting for cross-subdomain consent, turn it on, and test it on the subdomain the team forgot about, because there is always one.

Finally, check the log. A healthy consent log shows one choice per visitor per version, with a timestamp and a banner version. A log that shows the same visitor rejecting three times in five minutes is telling you the choice is not sticking. The log is the diagnostic. Read it before the next audit does.

Keep reading: [the back-button consent recheck](https://cookiebastion.com/blog/2026-11-09-bfcache-back-button-consent-recheck.md), [how long consent lasts](https://cookiebastion.com/blog/2026-11-07-consent-renewal-12-months.md), and [the denied-state tag test](https://cookiebastion.com/blog/2026-11-05-tag-manager-denied-state-test.md) cover the nearby cases in this series.

## Frequently asked questions

### Why does the banner keep appearing after I reject?

Usually the consent cookie is scoped too narrowly, so the next page cannot read it, or the consent platform overwrites the stored choice when it loads. The choice is recorded but never read back. Set the cookie on the parent domain with a root path and check that the platform reads the stored state before writing anything.

### Does the back button break consent?

It can. A page restored from the back-forward cache can show a stale banner or re-run the consent script as if the visit were new. Test the back button in more than one browser, because the behavior varies and a system that works in Chrome and fails in Safari is not a working system.

### How do I test whether a rejection survives navigation?

Reject everything on the homepage, then visit three other pages, including a different subdomain if the site has one. The banner should not appear again and no new consent cookie should be written. If either happens, the choice is not surviving navigation.

### What should the consent log show for one visit?

One choice per visitor per banner version, with a timestamp. A log showing the same visitor rejecting three times in five minutes is telling you the choice is not sticking.