The gap between having a cookie banner and being compliant
Adding a cookie consent banner is now close to universal among businesses with an EU or UK audience; what is far less consistent is whether the scripts that banner is supposed to gate actually wait for consent before they run. A cookie banner that renders correctly but sits alongside analytics and advertising scripts that were already loaded and already fired before the visitor made any choice at all satisfies none of the underlying legal requirement, informed consent has to happen before the processing it covers, not alongside or after it. This is the single most common gap this tool is built to surface: not the absence of a banner, but a banner that exists without actually controlling script execution.
Where the consent requirement actually comes from
The EU's ePrivacy Directive (2002/58/EC), often called the "cookie law" though it covers more than cookies, requires informed consent before storing or accessing information on a user's device, with a narrow exemption for cookies "strictly necessary" for a service the user explicitly requested. GDPR layers on top of this: where the cookie or tracking technology processes personal data (and an identifier used for analytics or advertising almost always does), GDPR's own consent standard, freely given, specific, informed, and unambiguous, per Article 4(11), applies as well. In the UK, the same underlying requirement is implemented through the Privacy and Electronic Communications Regulations (PECR), enforced by the Information Commissioner's Office. None of these frameworks specify a particular technical implementation, a specific banner vendor, or exact wording, which is exactly why so much variation exists in how sites implement consent, and why so many implementations have gaps that are invisible without actually inspecting what the page does.
Why script placement in the raw HTML is a meaningful, if imperfect, signal
A script tag sitting in a page's <head> with a plain src= attribute and no surrounding conditional logic will, in the overwhelming majority of real-world implementations, execute immediately as the page parses, well before any consent banner rendered later in the body has had a chance to receive user interaction. This is why this tool treats head-placement of a tracking script as a pre-consent risk signal. It is a signal, not a certainty: a script can be placed in <head> and still be correctly gated through JavaScript-level conditional execution invisible to a static HTML scan (checking a consent cookie before actually initializing the tracker, for example), which is exactly why this tool's "pre-consent risk" flag is framed as something to verify, not an automatic finding of non-compliance.
The most common real-world failure pattern
Across implementations reviewed while building this tool's detection rules, the single most common gap is not a missing banner, it's an "unclassified" script inside a real, properly installed consent-management platform. Every major CMP (Cookiebot, OneTrust, Termly, and others) requires each tracking script to be manually assigned to a consent category, necessary, analytics, marketing, so the platform knows which scripts to block until the corresponding category is accepted. A script added to the site after the CMP was initially configured, a new retargeting pixel a marketing team added directly through a tag manager, for example, frequently never gets assigned to a category and defaults to loading unconditionally, silently defeating the consent gate the business believes is protecting it. This is precisely the "partial" verdict category this tool's diagnosis logic is built to catch: a real CMP detected, but a tracking script still showing signs of loading pre-consent.
What a genuinely compliant setup looks like
A compliant implementation gates every non-essential script behind the visitor's actual, specific consent choice, using either the CMP's native script-blocking mechanism (commonly a type="text/plain" placeholder with a data-category attribute the CMP swaps to a real script tag only after consent) or a framework-level conditional load, in a Next.js app, wrapping the script in a component that only renders after checking the stored consent state, using a lazy loading strategy so it never executes during the initial page render regardless of consent timing. Necessary cookies, session management, security tokens, load balancing, are exempt from this gating entirely and can load immediately, which is also why this tool never flags a bare session cookie or CSRF token as an issue, only recognized analytics and marketing vendor scripts.
Session-replay and CDP tools carry the same obligation as ad pixels
Founders auditing their own cookie compliance often think only about advertising pixels, Meta, TikTok, LinkedIn, and overlook session-replay tools (Hotjar, FullStory) and customer-data-platform trackers (Segment, Amplitude) as if they were purely internal, low-risk analytics. They are not treated that way under GDPR or the ePrivacy Directive: any technology that sets an identifier on a visitor's device to track their behavior, whether the output is a heatmap, a session recording, or an event stream fed into a CDP, falls under the same "non-essential, requires consent" bucket as an advertising pixel. Session-replay tools carry an additional wrinkle worth flagging separately, they frequently capture form input and on-page text by default unless specifically configured not to, which raises its own data-minimization question under GDPR Article 5(1)(c) independent of the consent question this tool checks.
What "partial" compliance actually means for your risk exposure
A "partial" verdict, a real consent tool detected alongside at least one script still showing pre-consent risk, is arguably the most common real-world state among small and mid-size businesses, more common than either clean extreme. It typically reflects a genuine, good-faith consent implementation that has simply drifted: a marketing team added a new pixel through Google Tag Manager without looping in whoever manages the CMP's category assignments, and the new script inherited no consent gating by default. This is a materially different risk profile than "non-compliant" (no consent mechanism at all), but it is not a risk-free state either, an unclassified script firing pre-consent is functionally identical, from a regulator's perspective, to having no consent mechanism at all for that specific script, since the banner's presence elsewhere on the page does not retroactively cover data already collected before consent was given.
How to fix a script that this tool flags
The fix depends on which layer the script was added at. If it was added directly as a hardcoded<script> tag in your site's template, the most reliable fix is to replace it with your CMP's placeholder pattern, typically type="text/plain" with a data-category attribute the CMP's own script swaps to a real, executable tag only after the matching consent category is accepted. If it was added through Google Tag Manager, the fix lives in GTM's own trigger configuration: most CMPs ship a GTM integration that exposes a consent-state variable you can gate the relevant tag's firing trigger on, rather than having it fire on every page load unconditionally. In a Next.js codebase specifically, wrapping the script in a small client component that reads your stored consent state before rendering a next/script tag with strategy="lazyOnload" keeps the gating logic in one auditable place instead of scattered inline script tags.
Why a generic "cookie scanner" result can disagree with your CMP's own scan
Most commercial CMPs ship their own periodic site scanner that crawls your pages and reports which cookies it observed being set during a real browser session, including a full click-through of the consent flow. That is a fundamentally different measurement than what this tool performs: a CMP's scanner drives an actual browser, executes JavaScript, and observes real cookie-jar state before and after consent; this tool inspects the static HTML source of a single fetch, which cannot execute client-side JavaScript or observe runtime cookie behavior at all. The two will usually agree on the broad strokes, whether analytics/marketing scripts are present at all, and whether a CMP is installed, but a CMP's own scan is the more authoritative source for exactly which cookies fire before and after consent on your specific site, precisely because it observes real browser execution rather than inferring risk from source-code placement. Use this tool as a fast, no-login first pass, and your CMP's own dashboard scan (or a manual browser DevTools check with Application → Cookies open before and after clicking "Accept") as the authoritative verification.
Mobile apps and server-side tagging are outside this tool's scope
This checker only sees what a public web page serves in its raw HTML on first request. Two increasingly common tracking architectures fall entirely outside that visibility: mobile app SDKs (a native iOS or Android app's tracking, governed by its own consent framework, Apple's App Tracking Transparency and Google Play's equivalent, is a separate compliance surface with no relationship to a website's robots- visible HTML), and server-side tagging (where a site sends browsing data to a server-side Google Tag Manager container or a similar first-party endpoint, which then forwards it to third-party vendors entirely outside the browser). Server-side tagging in particular is becoming a popular way to route analytics data around ad-blockers and cookie restrictions, and it deserves its own separate compliance review, since data can be captured and forwarded without any client-side script ever appearing in the page source this tool inspects at all.
Frequently asked questions
Why does loading order (head vs. body) matter for cookie compliance?
It is a practical proxy, not a legal test on its own, for whether a script executes before a visitor has had any chance to interact with a consent banner. A script placed in <head> typically begins executing before the page body, and any consent banner rendered inside it, has even loaded, which is why templates and page builders that drop analytics snippets directly into <head> are a common, unintentional source of pre-consent tracking. A script correctly gated behind a real consent mechanism, using a CMP's script-blocking category or a conditional loader triggered by the user's actual consent choice, does not fire regardless of where its tag physically sits in the HTML, which is why this tool treats head-placement as a risk signal to investigate, not an automatic violation.
Does this tool see what happens after I click "Accept" on my own cookie banner?
No — this is a static HTML fetch of your homepage, the same single request a crawler would make, not a full headless-browser simulation that clicks buttons and observes what happens after. It can tell you that a tracking script is present in the raw HTML and roughly where, and whether a recognized consent-management tool's signature is present on the page, but it cannot click "Accept" or "Reject" and observe the before/after behavior a real compliance audit or an EU regulator's technical review would perform. Treat a "compliant" result here as a reasonable first-pass signal, not a substitute for testing your actual banner interaction in a real browser with network inspection open.
What counts as "necessary" versus "non-essential" for cookie consent purposes?
Strictly necessary cookies, session identifiers, load balancing, security/CSRF tokens, are exempt from consent requirements under both the EU's ePrivacy Directive and the UK's PECR, because the site genuinely cannot function without them and the visitor has an obvious expectation they'll be set. Everything this tool flags, analytics, advertising pixels, session-replay tools, customer-data-platform trackers, falls outside that narrow exemption and requires informed consent before being set, regardless of how "harmless" the specific use case feels to the business running it.
I use Google Consent Mode. Does that make pre-consent script loading okay?
Google Consent Mode changes what data Google's tags send, not whether they load. In its default configuration, Google's own tags still load on every page visit; Consent Mode adjusts what signals those tags are permitted to send back to Google based on the visitor's consent state, sending anonymized, cookieless pings before consent and full, cookie-based data after. This is a meaningfully different compliance posture than not loading the script at all, and whether Consent Mode's specific configuration on your site satisfies your jurisdiction's consent requirements is a legal question this tool cannot answer; it is exactly the kind of nuance a static HTML scan cannot fully evaluate, since a script present in <head> could be running in either a compliant Consent-Mode configuration or a non-compliant unconditional-tracking configuration, and both look identical to a source-code scan.
Which vendors does this tool actually detect?
Google Analytics (both GA4 and Universal Analytics tags) and Google Tag Manager, Meta Pixel, LinkedIn Insight Tag, TikTok Pixel, Hotjar, FullStory, Segment, Amplitude, and PostHog, on the tracking side; and Cookiebot, OneTrust, Termly, Iubenda, Osano, CookieYes, and Complianz, plus a generic pattern match for self-hosted "cookie consent"-labeled banners, on the consent-management side. This list covers the large majority of tools seen on small-to-mid-size business sites, but it is not exhaustive; a vendor or a custom-built consent solution not on this list will not be detected, which is a real scope limitation, not a claim of universal coverage.
My site has zero third-party scripts. Why does the tool still say "compliant"?
That's the correct result, not a false positive. Consent requirements only apply to non-essential cookies and tracking technologies that are actually present; a site with no analytics, no advertising pixels, and no session-replay tools genuinely has nothing to gate behind a consent banner for that specific concern (though other GDPR obligations around any personal data you do collect, through a contact form, for example, still apply and are outside this specific tool's scope).
Need the full privacy documentation too?
Pair this with the GDPR Privacy Policy Generator below to generate the matching cookie policy your consent banner should actually link to.
Primary sources: UK ICO — Guide to PECR: cookies and similar technologies; European Data Protection Board — Guidelines 05/2020 on consent; Google — Consent Mode developer documentation; EUR-Lex — ePrivacy Directive 2002/58/EC, official text.