Setting up a cookie scanner on a website (CookieBot/OneTrust/CookieYes)

Cookie scanner misses half the trackers: where it breaks

A cookie scanner crawls a page like a robot: it loads the markup, waits for rendering, and collects requests to third-party domains.

The problem is that a real user moves through the page differently — opening modal windows, accepting a banner, scrolling the feed, and only then are analytics, retargeting, and chat scripts pulled in. Cookie scanning by default sees a static snapshot and misses everything that loads on action.

The most common cause is dynamic loading. A script is inserted into the DOM after a click, scroll, or timeout, and at the moment of the crawl it is not yet in the markup.

The second is third-party scripts that are launched not directly, but through a tag manager: the scanner sees one container, and inside it there are a dozen tags, each with its own cookies.

The third is hidden pixels and trackers in iframes: they do not expose themselves to the main document, and the crawl does not capture them.

Cache and CDN also distort the picture separately. The scanner receives a cached version of the page, where some tags have already been stripped out or, conversely, left over from a previous build.

If the consent banner loads asynchronously, cookie scanning may not see it at all at the moment of the check — and the report will show a "clean" page, even though the trackers are running in production.

The bottom line: the scanner shows not the real set of trackers, but what managed to execute within the time allotted to it.

That is why proper setup begins not with the "Scan" button, but with reproducing user scenarios — let's break down how this is addressed at the level of crawl configuration and the tag manager.

What proper cookie scanner configuration delivers

Configuring a cookie scanner is not a matter of "put up a banner and forget it." The scanner crawls the site using a page map, intercepts requests before and after interaction with the interface, and collects everything that is sent to the browser: proprietary scripts, third-party pixels, embedded widgets, analytics and advertising tags.

The output is a tracker registry where each element has a source, purpose, lifespan, and cookie category. If the crawl map is incomplete, some trackers remain outside the registry — and those are the ones that become a source of compliance issues during a review.

Practice shows that on a typical site with forms, chat, and embedded analytics, the initial crawl finds noticeably fewer trackers than actually exist. The reason is that some scripts load only after a user action — submitting a form, opening a map, clicking a video.

That is why the scanner is configured in scenario mode: it walks through key user paths, records changes, and adds what it finds to the registry.

After that, cookie categories stop being formal — marketing, analytics, and strictly necessary trackers are sorted into their own groups instead of being lumped together.

A separate task is linking the scanner to the consent mechanism. Until the banner receives an explicit user action, no optional tracker should start; after a refusal, it should not run at all.

This is verified not by eye but by running tests: the scanner records which requests are sent before consent, which after, and whether the actual behavior matches what is stated in the policy. A discrepancy here is the most common reason a compliance review ends with an enforcement notice.

The measurable effect of putting things in order comes down to several things. The completeness of the tracker registry reaches a level where new scripts are caught at the point of addition rather than six months later.

The share of valid consents grows because the banner stops blocking the interface and at the same time does not let trackers through too early.

The speed of passing reviews and the cookie audit takes hours instead of weeks — the registry, categories, and consent logs are exported in a single report.

The severity of claims decreases: instead of arguing about whether a data leak occurred, the discussion focuses on a procedure that is already working.

Ways to deploy a cookie scanner: comparison of options

There are three ways to deploy a scanner, and the choice determines not the "trendiness" of the tool, but who is responsible for keeping the tracker database up to date and how quickly a fix reaches production.

Below is a comparison based on real criteria: setup speed, control over data, maintenance effort, and the class of limitations you get with each option.

The key limitation of any scanner is that it only sees what it managed to load during the crawl.

Scripts that are connected after consent, on scroll, or in modal windows do not make it into the basic report, so connecting a script is almost always supplemented with a manual check of key scenarios.

A hybrid scheme is chosen when the cloud database covers 80% of typical trackers, and the remaining 20% are your own integrations that need to be controlled locally.

Then the cloud is responsible for breadth of coverage, and your own collector is responsible for depth across your scenarios.

How we implement a cookie scanner: stages of work

We start implementation not with a banner, but with an inventory: the scanner crawls the site following the map of sections and records which scripts set cookies, which domain they contact, and whether they load before or after consent is given.

At this step, "forgotten" counters, embedded widgets, and pixels set by third-party contractors surface — these are the ones that most often break the banner's correctness.

Next, we sort what we find into categories (strictly necessary, analytical, marketing, functional) and configure the platform's behavior: blocking before consent, re-requesting when the policy is updated, the retention period for the choice, and geo-rules for different regions.

We cross-check the categories against the text of the cookie policy and the list within it — a discrepancy between the banner and the document is the first thing auditors find.

1. Page audit and script inventory: crawling sections, recording cookie sources and their purpose.
2. Cross-check with the privacy policy: bringing the cookie list and categories into a consistent form.
3. Configuring categories and triggers: what is blocked before consent, what loads immediately, how refusal works.
4. Connecting the consent management platform and linking it to tags and analytics systems.
5. Testing on live traffic: test sessions, refusal and repeated consent, mobile browsers, page refresh.
6. Resolving discrepancies: scripts that set cookies bypassing the banner are brought under consent management.
7. Handing over documentation and a maintenance procedure: how to add new scripts and when to review categories.

After launch, we leave a procedure in place: any new counter or widget goes through the same control, and the cookie list is updated whenever the policy changes. This way the scanner doesn't turn into a one-time setup — it remains a working tool that keeps consents up to date.

Consent policies and tracker blocking rules

A consent policy is not text on a page but an executable configuration: cookie categories, the conditions under which the banner triggers, and the rules by which scripts either load immediately or wait for an explicit user action. Below is what the client receives and the points we walk through together during acceptance.

• Tracker map. A complete list of scripts, pixels, and tags across all templates: name, purpose, category, load timing. We verify against actual traffic, not the contractors' documentation — discrepancies surface almost always.
• Cookie categories. Strictly necessary, analytical, functional, marketing. The boundaries are defined so that a disputed tag cannot be classified as "necessary" by default.
• Banner trigger rules. Geography, language, repeat visit, consent withdrawal. The banner does not overlap content and does not block the interface before consent where that breaks the scenario.
• Exception list. Tags that load before consent: bot protection, anti-fraud, load balancing. Each exception is justified and documented in writing.
• Consent log. What and when the user selected, with which version of the policy, with the ability to export. This is proof during an audit and the basis for re-requesting consent when the policy changes.
• Update procedure. Who adds a new tracker and how, and how it gets into the map and category before rollout to production.

Separately, we define the behavior on refusal: which scripts do not start, what is deleted from browser storage, and how consent withdrawal rolls back already-loaded tags. Without this, the policy remains a declaration, and tracker blocking is incomplete.

Case: Cookie scanner on a site with dozens of third-party scripts

What it was before

The client came with a typical picture: the site had more than a dozen third-party scripts — analytics, ad pixels, support chat, maps, review widgets — while the consent banner showed the user three categories and collected checkmarks "by eye." An automatic scanner running in basic mode found 6-7 trackers: it only saw those that load immediately when the page opens.

The rest connected later — after scrolling, clicking a button, or through a chain: one script pulled in a second, that one pulled in a third. The scanner did not record such trackers, and they simply were not in the registry.

At the same time, some of them set cookies before the user had clicked anything at all in the banner — meaning consent was not formally collected, but the data was already being sent.

What was changed

We switched the scanner to scenario-walking mode: it went through the pages like a real user — opening menus, scrolling down, submitting forms — and at each step recorded new requests and storages.

We set up periodic restarts to catch scripts that do not connect every time, and consolidated the findings into a single tracker registry indicating category, purpose, and trigger moment.

Next, we rebuilt the banner logic: consent categories were tied to real tracker groups from the registry, and the loading of each script was made dependent on the consent received.

Technically, this is blocking until explicit permission — no tracker starts before the user has confirmed the corresponding category. The tool is CookieBot, but the approach transfers to any scanner with support for blocking until consent.

What it became

The registry stopped being incomplete: new scripts that marketers add now get into it on the next walkthrough, rather than after a complaint. Compliance checking boiled down to comparing the registry against actual requests — there are no discrepancies.

How is a cookie scanner different from a consent manager?

A cookie scanner is a discovery tool. It crawls the site's pages like an ordinary visitor, records which trackers manage to fire before and after interacting with the banner, and sorts them into categories: strictly necessary, analytical, marketing.

The output is an inventory — a list of scripts with their source, domain, lifespan, and purpose. This list then needs to be maintained: add a new form, embed a chat, or connect an advertising pixel — and the inventory becomes outdated until a scan is run again.

A consent manager solves a different problem — it manages the banner and the storage of choices.

It is the one that shows the visitor a window with categories, blocks trackers until consent is obtained, records what and when a person allowed or withdrew, and passes this data onward — to analytics and to the proof log.

A scanner by itself does not draw a banner and does not store consent; a manager without a scanner does not know the full list of what it must block.

This is the difference between the tools: one answers the question "what do we have on the site," the other — "what did the visitor allow and how do we prove it."

In practice, they work in tandem, and the order matters. First, scanning produces a complete map of trackers, then this data is transferred into the consent manager's settings — categories, blocking rules, banner texts.

After that, scanning is run again, now with the banner active: this is how you verify that nothing extra leaks before consent, and that after consent exactly what is allowed gets connected. A regular scheduled run catches trackers that were added bypassing the process.

For the client, this means a simple division of responsibility: the scanner covers the completeness and currency of the inventory, the manager — the correctness of banner management and the safekeeping of choices.

When both are configured and connected, the check shows that no tracker starts before consent, and the choice log is ready for a request at any moment.

Common technical concerns about scanner configuration

A cookie scanner behaves predictably only on static pages with server-side rendering.

As soon as single-page applications, deferred script loading, and aggressive CDN caching appear, the picture changes: some scripts are installed after the first pass, and the scanner does not see them. Below is a breakdown of the situations we encounter most often.

A single-page application — the scanner does not see all scripts. What should we do?

The problem is that the scanner crawls URLs, while the application loads modules as navigation happens. We configure crawling by real routes rather than by a single entry point, and add manual markup for scripts that are installed by user action.

After that, we run scenarios: navigating through sections, opening forms, authorization — and verify that every script found has landed in the right category.

CDN and cache serve an old version of the banner. How do we synchronize?

The scanner and the banner must be updated in the same wave. We purge the CDN cache after publishing the configuration, version the banner script itself, and verify that the current build is served on all nodes.

Otherwise a gap appears: the scanner already knows about the new script, but the visitor receives the old markup without the required category.

How often should rescanning be run?

Continuously, not as a one-off. We set up a regular crawl on a schedule and additionally after every release, because new code almost always brings a new script with it.

We compare the result of each pass with the previous one: unmarked cookies appear — they go straight into work, not a month later when it surfaces during a review.

Let's discuss your cookie scanner task

We don't start the conversation with a presentation, but with your website: how many domains and subdomains, what the frontend is built on, how consent collection is organized, and what is already configured in your current scanner. That's enough to understand the scope and avoid guessing from screenshots.

From there, the work proceeds in stages, and at each one you see a result, not a report about how busy we are:

• Analysis of the current state — which scripts and trackers actually load, which of them fire before user consent, and where the scanner misses third-party embeds.
• Comparison with requirements — which consent categories are needed for your jurisdiction and data-handling model, what is already covered, and what is not.
• Scope estimate — the volume of changes in markup and tags, integration points with the scanner, and effort for each block.
• Implementation plan — the sequence of steps, what we do in the test environment, what we roll out to production, and in what order.
• Configuration and connection — the banner, categories, blocking rules before consent, and synchronization with analytics and advertising systems.
• Verification — a scanner run, manual testing of key scenarios, and cross-checking the consent log against the actual behavior of scripts.
• Handover and support — access, configuration documentation, and the update procedure for when new services are added.

Scanner support is a separate part of the work: rules and categories become outdated when a new service is added to the site or the markup changes. We define who makes changes and how, so the banner doesn't diverge from the actual set of scripts.

Describe your task: the website address, your current scanner, and what concerns you — missed scripts, an outdated banner, or a missing consent log. We'll come back with an estimate and a work plan.