Cookie Banner Audit: Does It Really Block Non-Essential Scripts? 7 Common Mistakes

A Reject button does not prove that tracking stops. A practical guide to testing a banner with Network, Application, Consent Mode and repeat checks.

You open a site in a fresh browser profile, click “Reject” and watch the cookie notice disappear. From the outside everything looks fine, but a cookie banner audit begins at exactly that point: was a request already sent to an advertising platform before the click, did the response try to set an identifier that remained in browser storage, and did the tags receive the correct consent state after refusal? The button is only a control panel, and an audit has to check whether the wires underneath are really connected, because the CMP may not yet have set the default when the tag manager fires its first tag.

A visual inspection of the banner, or a green tick from an automated scanner, does not reveal what happened during the first seconds of loading. Nor does it show which script triggered the action, which consent state was available to it at the time, or whether the visible end state reflects the whole sequence of earlier events. We therefore compare the site’s behaviour on one timeline: before any choice, after all non-essential categories have been rejected, after they have been allowed, and after consent is later withdrawn. In every state we examine network requests, response headers, cookies, localStorage and other storage, the sequence of consent signals and the initiator of the particular action. Only that comparison separates a correct configuration from a banner that merely closes.

This is a technical article, not individual legal advice: it shows how to collect verifiable facts without drawing conclusions that the evidence cannot support. If a site uses Google Tag Manager, Google Analytics 4, Google Ads, Meta Pixel, embedded video, live chat or other third-party tools, the cookie list visible on a single screen will be only part of the picture. The important question is therefore not “is a banner installed?”, but “what does the site do at each stage of the user’s decision?”.

What a cookie banner audit checks — and what it does not prove

An audit examines the technical consent chain from the first page request to the change of state after the user makes a choice. That chain cannot be judged only by its end state, because the initial loading sequence may already have triggered an action that closing the banner later cannot undo. The scope includes script-loading order, network connections, cookies and other storage, signals from the Consent Management Platform (CMP), the Google Consent Mode configuration, category behaviour and the ability to change a choice later. The result is a body of evidence about the cookie and tracking layer, not a certificate that all of the organisation’s processing of personal data is legally flawless.

Two connected legal layers must be kept separate. Article 5(3) of the ePrivacy Directive covers storing information on a user’s terminal equipment and accessing information already stored there — implemented in the UK through PECR — and this technical scope is not limited to files whose name contains “cookie”. The GDPR becomes relevant where personal data is processed, and it also determines the quality of valid consent and the principles for withdrawing it, so a technical test under one regime does not replace a legal assessment under the other. We name the two layers separately in the audit report so that an observed technical fact is not presented as a broader legal conclusion.

The Information Commissioner’s Office (ICO) explains that non-essential cookies cannot be set before consent and users must have an easy way to enable or disable them. Even so, the label “necessary” does not prove anything by itself. The strictly necessary exemption must be assessed narrowly: the particular action must be essential to provide a service expressly requested by the user or to transmit a communication, rather than merely convenient for analytics, marketing or the site owner’s internal needs. The auditor must connect the action to the function that makes it necessary and check at the same time that the category does not conceal an entirely different purpose that the user-requested function cannot justify.

For this service, the search phrase “GDPR website audit” covers only cookies, tracking and consent management; it does not include the legal bases for other processing, data-subject requests, contracts or internal governance. Our cookie and tracking audit service provides the technical facts with which a lawyer or data protection specialist can make a reasoned assessment of this part of the site, but GDPR compliance is not a single switch that a technical scanner can turn on for an entire organisation. That boundary is not an attempt to avoid responsibility; it states clearly what the report proves and which questions still have to be decided outside the technical audit.

How an audit gathers evidence, not merely a scanner result

A sound test starts in a clean browser profile with no saved consent choice, site cookies or extension-generated requests. Before any click, the Network log is enabled, the Application panel is inspected and the initial state is recorded. The same sequence of actions is then repeated after refusal, after consent and after withdrawal, with every scenario starting from a documented state and the complete log preserved. Otherwise yesterday’s choice can look like today’s banner fault or, conversely, conceal the real fault.

A Network entry proves that the browser attempted to contact a particular address and lets us inspect the initiator, status, request and response headers and the information sent, but it does not yet prove that a cookie was stored. A Set-Cookie response header shows that the server tried to set one, but the browser may block the attempt, while JavaScript can write to document.cookie or localStorage without that header. The actual outcome must therefore be checked in the Application panel, and no single indicator can stand in for the others. A visible request to an analytics domain is evidence of an attempted data flow, not automatic proof that an analytics cookie was successfully set or that a particular set of personal data reached the server.

For every finding, we record the tested URL and user journey, time, device and browser context, chosen consent state, request initiator, destination, outcome of the request and changes in storage, so that exactly the same test can be repeated after the fix. Automated scanning provides a broad initial inventory, but it does not traverse every menu, checkout step, logged-in area, language version or dynamically loaded integration, and it cannot reliably establish purpose from a filename or domain alone. It is therefore followed by manual scenarios and a discussion with the people responsible for those tools. We establish who introduced a tool, for what purpose, in which tag container it lives and which consent signal it should obey, so that the technical finding can be connected to the intended configuration. Evidence without context is only a screenshot; context without evidence is only a promise.

1. Non-essential scripts run before the user chooses

A critical sequencing error occurs when the CMP banner appears promptly but an analytics or advertising tag has already run: the user is still reading the buttons while the browser has contacted a third party or stored an identifier. The ICO’s guidance is unambiguous on this point: non-essential cookies must not be set before the user consents, so the technical check begins with the first document load, not when the auditor finally finds and clicks “Reject”.

In Google Tag Manager, a common cause is an incorrect event sequence. The default consent state must be set before the tags, using the Consent Initialization trigger or another solution that guarantees the same order, and an update is sent only after the user acts. If the default arrives too late, a tag may briefly see an undefined or previously saved state and run. A banner that closes quickly does not fix that race, because the problem is the execution order, not the animation.

The phrase “cookies load before consent” must be broken into more precise events in an audit: the script itself may have loaded, a network request may have been made, a cookieless signal may have been sent, an attempt may have been made to set Set-Cookie, or an identifier may actually have been stored. Each action has a different evidential meaning. With Advanced Consent Mode, some Google tags may load with storage denied and send cookieless signals, so the presence of a script alone is not enough to conclude either infringement or compliance.

The fix begins with a tool map and one clear state model: which tags may operate without a choice, which require a particular category, and which event updates that state. After the configuration is changed, the test is repeated in a clean profile with the Network log preserved, paying particular attention to the first requests and their initiators. If the fault appears only occasionally, that usually indicates a race between the CMP, the tag container and the site code. It must be removed from the loading order itself, not hidden behind a banner with a faster animation.

2. “Reject” changes the interface but not the data flow

A button can close the banner, grey out an option and even save the value “denied” while third-party tags continue running as before. A refusal test is therefore not a question about text that has disappeared, but a comparison between two states. We record requests and storage before and after rejecting every non-essential category, then check that the relevant tags receive no activating event, that no new identifiers appear, and that refusal persists across later page views. An earlier session can easily spoil this test: if consent was given yesterday, today’s “Reject” button may first load the page with yesterday’s state and only then change it, after the first request has already been sent. Manually deleting cookies between the steps also creates artificial cleanliness and fails to test the real withdrawal mechanism. Initial refusal and later withdrawal are therefore separate scenarios: the first starts without a decision, the second with consent deliberately given, and their results must not be combined in one screenshot.

Even after refusal, a site may perform actions genuinely necessary for a security, basket or other function expressly requested by the user, so “every request after rejection is bad” would be as inaccurate as the banner’s green tick. The purpose, initiator and storage action of every remaining connection must be established. The CMP should then be configured so that refusal first updates the consent state and the tags use built-in or explicitly specified consent checks; a functional button is one that predictably changes the data flow connected beneath it across several pages. If refusal stops an advertising tag but leaves a first-party session cookie, that may be the expected result. If one category silently activates another, the configuration is not reliable, and after the fix refusal must be repeatable across several pages without manually clearing storage, producing the same reproducible and provable state every time.

3. The categories and cookie policy do not match the real inventory

A banner can be technically sound and still mislead if its categories or policy describe a different site, as often happens after a template is copied, a tag container is inherited or a new tool is added without updating the documentation. The policy may retain a cookie that is no longer used while omitting a video player, chat widget or advertising conversion tag, leaving the user to make a choice on incomplete information. In that situation the organisation cannot substantiate which recipient receives the data, for what purpose or how long the identifier remains.

The ICO’s cookie guidance ties the policy to the real inventory: it should identify the purpose, service provider or recipient and retention period, rather than repeat only what a CMP catalogue has recognised automatically. A cookie with the same name may be used differently in different configurations, while a custom first-party identifier may have no description in any public database. An audit therefore connects the technical object to the site owner’s actual purpose and the responsible tool. Its task is not to copy a catalogue guess, but to check whether the configuration, recipient and duration match what the organisation really uses and can explain.

The inventory does not end in the Cookies pane. It must cover localStorage, sessionStorage, IndexedDB, pixel requests and server-side requests, as well as identifiers used in URLs or form flows where they take part in tracking. The EDPB’s technical guidance explains that ePrivacy’s scope is not tied to one storage technology, so a policy that promises “we do not use cookies” still does not answer whether the site accesses information on terminal equipment by another method or sends measurement signals. A list of cookie names is therefore the start of an inventory, not a complete account of the technologies that may store, read or transmit identifiers.

The practical remedy is a single source-of-truth register used to maintain the CMP classification, the policy’s technical table and the audit scenarios. Each entry records the tool owner within the organisation, vendor, purpose, activating consent state, storage used, recipient and duration. Adding a tag then ceases to be merely a task in a Google Tag Manager container and becomes a controlled change that must update the information given to users and the test cases before release. After the change, the same register gives a repeatable test its starting point and shows who in the organisation is responsible for correcting a discrepancy.

4. One Network request is mistaken for proof of a cookie

An analytics domain in the Network panel is an important finding, but it does not by itself support the conclusion “a cookie was set”. The entry proves an attempted connection and shows what the browser added to the URL, headers or request body, but a failed, blocked or cancelled request is not the same thing as data successfully received by the server. For the cookie itself, the auditor must check whether the request contained a Cookie header, whether the response contained Set-Cookie, whether the browser blocked it and whether the entry actually reached storage. A request may be blocked or cancelled before the server receives data, and that limit of the evidence must appear in the wording of the finding rather than merging the connection attempt, transmission outcome and storage into one claim.

The opposite conclusion is no safer. A cookieless request may contain the consent state and other parameters, while the site may use a localStorage identifier, a URL parameter or another technical method; the absence of a cookie does not automatically make the connection anonymous or empty. A Set-Cookie header, in turn, is an instruction from the server to the browser, not a guarantee that an entry was stored, because the browser may reject it on account of the domain, security attributes, third-party restrictions or another policy. A first-party cookie set by JavaScript can also appear without that response header. DevTools shows blocking reasons too, so the presence of Set-Cookie must be read alongside the browser’s decision and the actual Application state. If there is no new row in the Cookies pane, we do not relabel the signal “no data”; we inspect the URL, headers, parameters and other storage.

The safest method joins three views on one timeline: what initiated the request, what the server asked the browser to do, and what was then actually stored in that particular browser profile. The audit report deliberately names only what has been proved. We write “a request was sent to domain X before a choice”, “the response contained an attempt to set a cookie” or “identifier Y remained in the Application panel after rejection”, because a developer can repeat that step, a lawyer can see the limits of the technical fact, and the result can be compared objectively after the fix. We do not infer the entire data-processing chain from one screenshot, because it can prove only the particular action, state and time at which it was captured.

5. Withdrawing consent is hidden or technically incomplete

Consent is not a one-off click that a site may forget. Article 7(3) of the GDPR gives people the right to withdraw it at any time and requires withdrawal to be as easy as giving consent, as the ICO also explains in practical terms. If consent can be given on the first screen of the home page but withdrawal requires a search through a subsection of the privacy policy, an email or clearing browser settings, the mechanism is not equally accessible; a common solution is a permanent preferences link in the site footer. We test whether it can be found from every page and when the banner is no longer visible, because that is precisely the state in which a user tries to change an earlier decision.

The technical test begins with consent deliberately given and tags genuinely activated. The auditor then opens the preference manager, withdraws the non-essential categories and continues through the site, without creating an artificial starting point by manually clearing storage. The test must establish whether the CMP sends the updated state and the tags receive it, whether any new consent-based data flows begin, and what happens to identifiers stored locally. This is how we uncover a button that saves the new choice but does not tell the tags already loaded. At the same time, we record the sequence of the change event to distinguish a correctly saved choice from a situation in which a dependent tag receives the update too late or not at all.

Withdrawal operates prospectively; by itself it does not rewrite the past or delete all data processed lawfully beforehand. Further processing based on that consent must stop, but retaining or deleting data previously received by a server may require a separate assessment. The audit report therefore separates stopping future data flows from the question of retaining earlier data, without promising that a technical preference change resolves both. The remedy must connect the interface to the integration: the link must be findable from every page, the CMP must show the current state, the change must reach every dependent tag, and the test must be repeated with several combinations of categories, because “reject all” may work while turning off a single marketing switch has no effect. Deleting browser identifiers must likewise be assessed according to their function, rather than promising that one click in a CMP will automatically clean every third-party system.

6. Basic and Advanced Consent Mode are confused, or modelled data is promised

Basic and Advanced Consent Mode are not two designs for the same switch. In Basic mode, Google tags do not load before consent and Google receives no measurement data from those tags until then; after consent, the tags can begin ordinary measurement. In Advanced mode, they load with storage initially denied and may send cookieless signals while consent has not been given, so the mode must not be described as one in which “nothing is sent”, and Basic is not automatically the poorer analytics configuration. The difference lies in the tags’ actual behaviour before the choice, not in the banner’s appearance or the name of one setting.

The choice should follow the organisation’s legal assessment and analytics needs, not an assumption that the name of a Google product resolves ePrivacy or GDPR requirements by itself. Google’s Consent Mode documentation distinguishes tag blocking in Basic mode from cookieless signals in Advanced mode, but the audit examines the actual configuration: whether defaults take effect before the tags, which update is sent after the click, and which requests really appear in each state. The name of a product mode is not a legal conclusion, so the report describes the tested flow and the configuration chosen by the organisation rather than applying an automatic compliance label.

“Cookieless” does not mean “information-free”, so the name of a signal must not replace an assessment of its content and purpose in the report. The Network panel should be used to inspect the destination, parameters, consent state and initiator, while Google Tag Assistant or Consent Mode debugging tools help verify the default and updated states. These views complement one another: the first reveals the data flow in a particular attempt, while the second reveals the configuration logic. If they disagree, the tidier screen should not be trusted by default; the auditor must find where the default or update event failed to reach the tag in the intended sequence.

Nor is modelled data a guaranteed reward for enabling Advanced mode. The availability of Google Analytics 4 behavioural modelling depends on Google’s conditions for the property, data volume and data quality, and the feature may be unavailable or may disappear if those conditions cease to be met. Modelling does not reconstruct the sessions of individual users who refused consent. Our proposal therefore promises a correct configuration and a verifiable signal sequence, not a particular volume of modelled data determined by Google’s system and the eligibility of the property concerned. The audit outcome is consequently a reproducible configuration and signal test, not a promise about a volume of data that the service provider cannot control.

7. The test ends on the first page and the first day

The home page rarely covers the complete tracking inventory: a video tag may load only after playback begins, a map integration on the contact page, an advertising conversion after a form is submitted, a payment tool at the final basket step, and a chat or personalisation script after a delay. An auditor who opens one URL, waits a few seconds and closes the scanner may write a technically accurate report about that single view and a dangerously incomplete one about the site as a whole. Each of these states must be reached through the action that actually activates the integration, rather than assuming that the home-page inventory automatically represents every template and user journey.

We build scenarios around real user journeys and site templates, covering a public page, an article, a contact form, an account area, the purchase process, embedded content and every material language or regional version. The mobile layout must be tested too: CMP buttons may overlap or the preferences link may become unreachable even though everything works on desktop. An automated crawl provides breadth, while manual testing reaches states that a crawler without an account or user interaction will never see. Language and regional versions, like the mobile layout, are not decorative duplicates if they change which integrations load or which choices the user can reach.

A one-off audit does not cover change over time. A new marketing tag, a replaced CMP template or an imported Google Tag Manager container can break a previously correct sequence without any visible change to the banner, so every new tool needs a pre-release test and a repeated comparison. This discipline is worth planning in the web-development contract itself, as we explained in our article on 10 mistakes when commissioning a website. Our audit process includes a repeat scan 30 and 180 days after implementation, using the same scenarios and evidence fields to see whether the fix survives the normal publishing cycle and whether new tools or configuration drift have appeared later. The first interval shows whether the implementation has survived day-to-day publishing; the second reveals later changes. In the repeat test we compare a particular request, storage entry and consent state with the original finding, rather than settling for the impression that it “looks better now”.

What you receive in a technical cookie and tracking audit

The first audit deliverable is a verified inventory of cookies, storage, tags and third-party requests. Every finding is connected to a page, user action and consent state, with the evidence and its limits recorded alongside it: a Network entry, a Set-Cookie attempt, an actual cookie in the Application panel, a localStorage entry or a CMP event. The developer receives a reproducible defect rather than a vague instruction to “fix GDPR”, while the person responsible for privacy can see which facts still require a legal decision. Every finding also records the steps needed to reproduce it, so that the same page, choice, request and storage result can be tested after implementation.

The second part is implementation. We put the CMP categories and Google Tag Manager default and update sequence in order, configure the consent checks for Google Analytics 4, Google Ads, Meta Pixel and other tools, and prepare the cookie declaration and privacy-policy text. We choose Basic or Advanced Consent Mode according to your legal assessment and analytics needs, without presenting Advanced as the universally correct option or promising modelled data where the particular Google property does not meet Google’s conditions. We test the implementation result in the same consent states in which the original finding was recorded, so that the configuration change can be supported by comparable evidence.

The service starts at €800, with a delivery time of 1–4 weeks, depending on the size of the site, the number of languages and templates, the complexity of the CMP and tag containers, and the number of integrations required. Before work begins, the price and schedule clearly separate audit evidence, technical fixes and questions that must be decided by the organisation’s lawyer or data protection specialist. After 30 and 180 days, we run another scan against the recorded scenarios. The price and timing therefore relate to a clearly named technical scope, not an undefined promise to put all of the organisation’s data protection in order.

If you need a “GDPR website audit”, we first agree that here this means the cookie, tracking, CMP and Consent Mode scope, not a complete review of the organisation’s compliance with the GDPR. We therefore promise only what we can prove technically: the site’s behaviour before a choice, after refusal, after consent and after withdrawal; the signals sent to tools; and the places where the evidence is not yet sufficient for a legal conclusion. This distinction allows the technical work to end with a verifiable result and the legal questions to be handed to the person responsible for the wider processing of personal data. You can book a cookie and tracking audit by sending us the site address and the name of the CMP or tag manager you use.