How to test your cookie banner’s Accept and Reject buttons

To test your cookie banner, open your website in a private browser window with the developer tools showing. Click Reject and check that no tracking requests or cookies appear. Start again, click Accept and check that they do. Then change your choice and reload to make sure the new setting sticks.

Your banner makes a promise every time someone clicks it. If a visitor clicks Reject and your site still sends their visit to Google or Meta, the banner is telling them something that isn’t true. People notice this more than you might think: in the OAIC’s Australian Community Attitudes to Privacy Survey 2026, 65% of people said sharing their information rarely or never feels like a real choice. A short test tells you whether yours is a real choice.

What does a cookie banner test check?

A cookie banner test checks three things: that Reject stops tracking, that Accept starts it, and that a changed choice is respected.

• Reject blocks tags. After someone clicks Reject, analytics and advertising tags should not send data or set cookies.

• Accept loads tags. After someone clicks Accept, the tags you rely on should load and work as normal.

• Changed preferences stick. If someone changes their mind later, the site should follow the new choice on every page, and remember it when they come back.

The first one gets most of the attention, but the second matters too. A banner that blocks everything, even after Accept, quietly breaks your analytics and ad reporting.

What you need before you start

You need a desktop browser, a list of the tags on your site, and somewhere to save screenshots. Chrome is used in the steps below. Edge and Firefox have the same tools under similar names.

If you’re not sure which tags your site runs, start with the Savira website privacy scanner so you know what to look for. These are the common ones and how they show up:

• Google Analytics 4: requests to google-analytics.com, usually with /g/collect in the address, and cookies starting with _ga.

• Google Ads: requests to googleadservices.com or doubleclick.net, and a _gcl_au cookie.

• Meta Pixel: requests to connect.facebook.net and facebook.com/tr, and a _fbp cookie.

• LinkedIn Insight Tag: requests to snap.licdn.com or px.ads.linkedin.com.

• TikTok Pixel: requests to analytics.tiktok.com.

If you work in health, pay extra attention to pixels on booking and contact pages. Our guide to tracking pixels on health websites explains why.

How to test that Reject blocks tracking

Testing Reject means making a fresh visit, clicking Reject, and watching what the page sends afterwards.

1. Close any open private windows, then open a new one. A private window starts with no saved cookies or banner choices.

2. Open the developer tools (F12 on Windows, Cmd + Option + I on a Mac) and choose the Network tab. Tick Preserve log so requests stay listed when you move between pages.

3. Load your homepage, but don’t touch the banner yet. Type collect, facebook or tiktok into the filter box and note anything that has already fired. Tags that send data before anyone has chosen are worth raising with whoever built your site.

4. Click the clear button in the Network tab so the list is empty, then click Reject.

5. Visit two or three other pages, including any form or booking page. Filter again for each tag on your list. You should see no requests sending data to them.

6. Open the Application tab, then Cookies, then your domain. Check for _ga, _gcl_au, _fbp and the others on your list. They should not be there.

7. Take a screenshot of the empty Network filter and the cookie list for your records.

One complication: if your site uses Google Consent Mode, some Google requests can still appear after Reject in a restricted form. Ask whoever set it up what should happen, so you know what a pass looks like.

How to test that Accept loads your tags

Testing Accept is the same routine in reverse: a fresh visit, a click on Accept, and a check that your tags come to life.

1. Close every private window and open a new one, so the Reject choice is gone.

2. Open the Network tab with Preserve log ticked, load your homepage and click Accept.

3. Visit a few pages and filter for each tag. You should now see requests going to them.

4. Check the cookie list again. The cookies you expect, such as _ga or _fbp, should now be set.

5. Screenshot the results.

If nothing loads after Accept, your banner may be blocking tags it shouldn’t, or the tags may not be connected to it properly. Either way, your reports are probably missing data.

How to check that changed choices stick

Checking changed choices means switching your answer after the first click and making sure the site follows along.

1. Straight after the Accept test, reopen your banner settings. This is usually a link in the footer or a small icon in a corner of the page.

2. Turn off analytics and marketing, then save.

3. Clear the Network tab, reload, and visit a few pages. New tracking requests should stop. Cookies set earlier may stay in the browser until they expire, so focus on whether new data is being sent.

4. Now do the opposite: start a fresh private window, click Reject, then open the settings and switch to accepting everything. Tags should start loading.

5. Finally, test memory in a normal (not private) window. Make a choice, close the tab, come back later and check that the banner remembers it rather than asking again or reverting.

What to do if your banner fails a test

If a test fails, the cause is usually a tag that sits outside the banner’s control. Common culprits:

• Tags added directly to the site. A plugin, theme setting or marketing tool may insert a tag that never checks the banner. This is common on WordPress, where several plugins can each add their own tracking. Our WordPress cookie consent plugin page covers how Savira works on WordPress sites.

• Tag manager triggers. In Google Tag Manager, a tag can fire on every page view unless its trigger waits for consent.

• Load order. If the banner script loads after your tags, the tags may fire first.

Fix the cause, then run all three tests again. Our guide to tracking pixels and your privacy obligations is a good next read if pixels are the problem, and if you’re still deciding what your banner needs to do, start with whether you need a cookie banner in Australia. For the banner itself, see Savira cookie consent.

Keep a record and test again

Keep your screenshots and a note of the date, the browser you used and what passed or failed. Store them with your other privacy records.

Then test again whenever something changes: a new plugin, a new marketing tool, a theme update or a new agency touching the site. Tags have a way of creeping back in, and a quick retest catches them before your visitors do.

This is general information, not legal advice. Every business handles information a bit differently, so if you’re not sure how this applies to yours, it’s worth checking with a lawyer or privacy adviser.