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.

Frequently asked questions

What must happen technically when a visitor rejects all?

No optional cookies or trackers should load, and tags that support consent mode should receive the refused state before they fire. A reject button that only closes the banner while scripts continue is a refusal recorded and ignored.

Should a rejection be logged like an acceptance?

Yes, with the same care: time, choices, and banner version. A store may need to prove it honoured refusals, and the log is also what stops the banner reappearing to ask again on every page.

Can the banner ask again later after a rejection?

Only under the rules that apply in the visitor's market and after a sensible interval or a material change, and never as a nagging loop. The settings route to change the choice should be available at all times instead.

Is hiding content after refusal acceptable?

Punishing refusal by degrading the site beyond what the refused processing genuinely requires undermines the freedom of the choice. Core content and buying should work on the essential processing alone.