What should a consent banner do when a visitor rejects all cookies?
Reject-all is the consent choice most banners mishandle: the button exists, but optional scripts load anyway, or the choice quietly expires. Honoring rejection means loading nothing optional, suppressing all non-essential trackers and pixels, and keeping the refusal effective until the visitor changes it. It also means making that change easy, because a refusal that cannot be reversed is not a real choice.
Load nothing optional, and mean it
The test is simple: open a fresh session, reject all, and watch the network tab. Every analytics call, ad pixel, and third-party script that fires after a rejection is a failure, regardless of what the banner promised. The most common leaks are tag managers that fire their containers before reading the consent state, social embeds that load with the page, and "strictly necessary" categories stuffed with tools that are merely convenient. Run this test in a clean browser profile, not your own, where stored state can mask the leaks.
Fix this with prior blocking: no optional script executes until consent state is known, and a rejection keeps them blocked. This has to be enforced in the loading logic, not documented in the cookie policy. Policies do not block network requests.
Keep the refusal effective
A rejection should persist. Store the consent state with a reasonable lifetime, commonly six to twelve months, and respect it on every return visit without re-prompting. Re-showing the banner to someone who already rejected is not just annoying; in several jurisdictions it reads as pressuring the visitor to change a valid choice.
The exception is a genuine state reset: cleared cookies, a new device, or a material change to what you collect. In those cases a fresh prompt is legitimate. Document why the re-prompt happened so the logic is defensible.
Make changing the choice easy
Consent is not a one-time event. A visitor who rejects today may want analytics tomorrow, and a visitor who accepts may change their mind. Provide a persistent, visible way to revisit the choice: a "cookie settings" link in the footer is the standard pattern. It should open the same preference center the banner used, with the current choices pre-selected.
Test the reversal in both directions. Accept after rejecting should enable the optional tools. Reject after accepting should disable them and, where feasible, delete the cookies the tools already set. A preference center that only works in one direction is a dark pattern with a settings page.
Do not punish the refusal
Some sites degrade the experience after a rejection: nagging re-prompts, blocked content, or a visibly worse site. This is both hostile and legally fragile. Regulators in several markets have been explicit that refusing consent must not lead to a detriment, and consent walls that block content until acceptance are restricted or banned in a growing list of jurisdictions.
The store must work fully for the visitor who rejects everything. Analytics will have a gap; that is the cost of the choice, and it is a cost the business bears, not one it passes to the visitor.
Log the rejection like any other choice
Keep a consent log that records rejections with the same care as acceptances: timestamp, the exact choices, the banner version shown, and the policy version in effect. If a regulator or a customer ever asks what happened, "we have a complete record" ends the conversation. Rejections are the choices most likely to be scrutinized, because they are the ones businesses are tempted to ignore. Export the log on a schedule so it survives a tag manager mishap or a vendor change.