Cookiebot Audit: Test Blocking, Choices and Repeat Visits

A useful Cookiebot audit follows the visitor's choices from the banner to the requests a page sends. It asks whether an optional service is blocked at the right time, starts only when appropriate and responds when permission is withdrawn. Counting cookies once cannot answer those questions.

This checklist is for a scheduled audit or release review. If you already know a script escapes blocking, go to Cookiebot not blocking cookies for troubleshooting. If you are reviewing the installation itself, start with the Cookiebot setup guide. Keep those tasks separate from the final audit so a change in settings does not quietly become a passing test.

Choose the pages that represent your website

List the homepage, a content page and the templates that introduce additional services. On a shop, a product page and checkout entry may behave differently. A contact page might embed a map or booking tool. Test only systems you are authorized to audit, and use test details if a workflow requires submitting a form.

Document exclusions. If you cannot access a logged-in area, say so. If a scan runs from only one region, do not describe it as a worldwide assessment. A small, clearly defined sample is more useful than a long URL list with no explanation of what the reviewer actually tested.

Separate existing cookies from new writes

Begin the pre-consent test with a genuinely fresh session. Opening a private tab while other private tabs remain open may preserve consent. A returning browser can also contain analytics cookies from an earlier grant. Those cookies are worth reviewing, but their mere presence does not establish that Cookiebot created them before consent in the current visit.

Record the name, domain and purpose of a suspicious entry, then correlate it with the event timeline. Avoid copying its value into a public report. If a developer needs more detail, share the smallest useful example through an approved private channel. Authentication tokens are not audit illustrations.

Check blocking mode and script ownership

Ask whether the site uses Cookiebot automatic blocking, manual script controls or a tag-manager integration. A checklist written for one installation method can send you in the wrong direction on another. Consult the Cookiebot automatic-blocking explanation before interpreting script markup.

For each observed analytics or advertising service, identify who owns its loading path. A plugin, theme option and GTM container can all install the same vendor. Do not assume that a script belongs to GTM just because GTM is present. Match the actual request with the page code or integration that initiated it.

Run the baseline and rejection scenario

1. Open the selected URL in the clean session and leave the banner untouched. Capture the initial cookies, storage keys and requests.
2. Classify the observations. Necessary functionality, an unknown script and a known advertising identifier should not receive the same explanation.
3. Choose the option that rejects optional processing. Record the visible result and the saved category state.
4. Wait through the same observation window, navigate to another selected page and reload. Look for new disallowed writes or requests.
5. Save the evidence with a timestamp and describe any blocked pages, consent-detection ambiguity or incomplete loading.

Do not stop because the popup says zero. A server response can fail, a page can block automation, or the relevant service may appear only after an interaction. Treat an incomplete observation as incomplete. Use the browser extension to investigate behavior the passive online scan cannot exercise.

Use a partial choice to test the category wiring

Reset the session again. Accept one optional category while leaving the others off, then trigger a representative action. If statistics are allowed and marketing is refused, examine whether advertising starts anyway. This is where broad conditions such as 'a preference exists' tend to show up.

A service that does not start also deserves attention. Check that it was expected on this page and that the chosen category applies to it. Avoid solving a missing conversion by moving a marketing tag into the necessary category. The mapping should reflect the service's purpose, not the desired tracking volume.

Check withdrawal without clearing the session

Start from an accepted state, reopen Cookiebot preferences and revoke the relevant permission. Continue interacting with the same page before reloading. This reveals libraries that keep running because the implementation handles start-up but never handles a later change.

Then reload and repeat the relevant action. Record the immediate result and the post-reload result separately. An integration may stop correctly after reload but continue collecting in the current document. Cookie removal alone is not proof that a loaded SDK has stopped sending events.

Interpret Google tags without mixing up requests and storage

First establish whether the intended design is basic or advanced Google Consent Mode. In basic mode, the tag is blocked before consent. Advanced mode may allow cookieless pings under denied consent. The audit should state which behavior the implementation owner expects instead of treating every Google-domain request as identical.

Use the Google Consent Mode checker for readable consent commands and Tag Assistant for the integration's tag-level state. If analytics cookies appear while analytics storage is supposed to remain denied, investigate the initialization order and duplicate installations. Record uncertainty when a command is not visible to the checker.

Write the report so the developer can reproduce it

For every finding, include the URL, session conditions, exact choice, observed entry and expected behavior. Link a recommendation to the evidence. 'Review cookie compliance' is too broad; 'investigate the analytics loader in the product template after Reject' names a place to start.

Group repeated symptoms when they share a confirmed cause, but retain the affected URL list. Mark a fix as verified only after repeating the original test. Agencies can use a redacted snapshot for engineering detail and a PDF report for the client. Review both before distribution.

Cookiebot audit FAQ

How often should we repeat the audit?

Repeat the affected scenarios after a CMP publish, tag change, theme release or new embed. For a stable site, choose a review schedule that matches the frequency and impact of changes. A scheduled scan is an early warning; it does not replace interactive withdrawal testing.

Can a Cookiebot scan and ConsentScope disagree?

Yes. Different URLs, regions, sessions and observation windows can produce different inventories. Compare the conditions and the exact cookie or request rather than treating either summary count as the final answer.

Can we automate all the checks in this guide?

ConsentScope's bulk scanner supports passive checks across submitted URLs. The choices described here still need to be exercised in the browser. Keep the automated baseline and manual scenario results together, without presenting one as the other.