How to test a cookie banner before going live

All posts

Test a cookie banner on a staging URL, in a private window, before it goes live. First check that it appears, that it holds non essential cookies back until a choice, and that the consent signal on the outgoing request matches that choice. Then check that the choice is recorded and survives a return visit and a withdrawal. The last three are where setups usually fail.

Almost every published test is a post launch audit

Search for how to test a cookie banner and the guides that come back are audits: open the site, open the developer tools, click reject, see whether the trackers stop. It is a reasonable audit and we would run it too. Reading the ones ranking today, they are written for a banner that is already live, which answers a different question from the one in the title above.

The difference matters because the two tests cost different amounts when they fail. A live banner that turns out to be broken has been collecting data it should not have, or missing data it should have, for however long it took somebody to notice. A broken staging banner has cost an afternoon.

What should you check before a cookie banner goes live?

1. Test on staging, not on the live site

   Production is not the test bench. Put the banner on a staging URL and register that domain with the consent tool, so it serves a real banner there rather than refusing to load. Most consent tools have a staging or draft mode for this.

2. Open a private window and check the banner appears at all

   A clean private window is the only honest first look. Your own browser is carrying a choice you made earlier, and an answered banner does not come back. Confirm the banner appears on first load, that the reject option is visible without scrolling, and that rejecting is no harder than accepting.

3. Reject everything, then watch what the page sends

   Open the network panel and the browser's storage panel before you touch the banner. No non essential cookie should be written yet, and no third party tag such as Meta or Hotjar should load. Google requests depend on your Consent Mode setup, covered in the next section. Then reject everything and reload, on a product page and a checkout page too, because tags are often added per template by different people.

4. Read the consent signal on the outgoing request, not the banner

   This is the check that separates a banner from a consent setup, and the one the published checklists leave out. Where Consent Mode is implemented, Google tags carry the consent state on the request itself: reject, then read that state and confirm it says denied. Finding no consent state at all is its own finding, and a different fault, because it means Consent Mode is not running rather than that the banner failed.

5. Confirm the choice was written down

   Consent you cannot produce later is not much use in an audit. Check that answering the banner creates a stored record you can retrieve, naming which categories were accepted and when. What else it holds varies by vendor, and the version of the notice shown is the field worth asking about, since without it you cannot say what the visitor agreed to.

6. Repeat it as a returning visitor, after a withdrawal, and from a second region

   All three ship broken regularly. Reload as a visitor who already answered and confirm the stored choice is still applied. Withdraw consent and confirm third party tags stop and Google tags go back to a denied state. Then check a region where your rules differ.

Is a Google request before consent a failure?

Not always. Two different tests get mixed up here. No non essential cookies before consent is a storage test: nothing beyond what is strictly necessary is written to or read from the browser until the visitor agrees. No analytics requests before consent is a stricter network test, and it only holds under Basic Consent Mode or for tags you block completely.

Under Advanced Consent Mode, Google tags load with every signal denied and send cookieless pings, which Google documents as expected behaviour. On that setup, a /g/collect request before consent passes if it carries gcs=G100 and sets no cookie. A Meta or Hotjar request in the same place fails.

Which test applies is a legal decision as well as a technical one. The EDPB's guidelines on Article 5(3) of the ePrivacy Directive read it as covering more than cookies, and some teams choose Basic mode on legal advice. Decide which setup you run, then test for that one.

What a real pass looks like

Four of those checks have a comfortable version and an honest version, and the comfortable one is what most testing guides settle for. The gap between the two columns is where setups everybody signed off on turn out to be wrong months later.

The third row is the one worth dwelling on. A consent tool reporting that it applied a choice is reporting its own internal state, which is a different thing from what your tags received. The place the question is settled is the request leaving the browser, which is why checking the Consent Mode v2 signal is a separate step rather than a detail of the reject test.

Which three states does nobody test?

First visits get tested because they are easy to reproduce. The states that ship broken are the ones that need a bit of setup to reach.

The return visit. A stored choice has to be read back and reapplied on the next visit, and that path runs through different code from the one that recorded it. When it fails, the visitor sees the banner again on every page load, or worse, the banner stays away while the stored choice is quietly ignored and the tags run on a default nobody chose.

The withdrawal. Article 7 of the GDPR requires consent to be as easy to withdraw as it was to give. The interesting part is what happens after: third party tags that were granted need to stop, and Google tags need to fall back to a denied state. A withdrawal can update the stored record and leave already loaded tags running until the next page load, which is worth knowing before launch rather than after a complaint.

The second region. Rule sets get configured for the market somebody had in mind that day, so a setup that shows a correct banner in one country can show nothing in another. The person testing is usually sitting in the first country, which is why it goes unseen.

Keep the evidence

Write down what you saw, because the test's value decays the moment the site changes again. Keep the outgoing request showing a denied state, the stored consent record, and a note of which page templates you checked. That is the difference between saying the banner was tested and being able to show it, which is the same distinction we draw in how you actually prove a visitor gave consent.

It is worth being honest about what the test protects. Consent choices hide a share of sessions from analytics, and that share varies with region, audience and banner design. Your consent tool’s accept rate tells you yours. A banner wrong in one of the ways above is not only a compliance exposure: it quietly changes what every downstream report counts, without an error message.

Velo is built so most of this list is true on the first load. The consent state is set from one snippet before your tags initialise, the choice is recorded with its categories and notice version, and a return visit behaves like the first. The mechanism is on the product page.