# How the Cookiequiet scanner works (and what it cannot see)

> The scanner reads up to 50 pages, their scripts, iframes, beacons and Set-Cookie headers, and names about 80 providers. It runs no JavaScript, so infers some.

Source: https://cookiequiet.com/blog/how-the-cookiequiet-scanner-works
Published: 2026-10-20
Publisher: Cookiequiet

The Cookiequiet scanner is a crawler that fetches your pages the way a browser would request them, without running their JavaScript, and reads the HTML and the response headers for everything that can store or read data on a visitor's device: script tags, iframes, stylesheets and preconnect hints, tracking pixels, and the Set-Cookie headers your server sends. It names what it finds with a database of about 80 providers, from Google Analytics 4 to Hotjar, Stripe and Intercom, and turns the result into a cookie table, a processors list and the auto-blocker's host list. Because it does not execute scripts, a cookie that only appears when a script runs is listed from the provider database, not observed. That limit, and a few others, are the reason this article exists.

## Step 1: crawling

The scan starts at `https://yourdomain/` (falling back to `http://` if the secure site does not answer) and follows links to pages on the same site, breadth-first, a few pages at a time, until the page budget is spent: 5 pages for the free public scanner, 10 pages per scan on the Free plan, 50 on Starter and Pro. "Same site" means the same registrable domain, so `shop.example.com` and `www.example.com` are both crawled from `example.com`. Links to files (PDF, images, CSS, JavaScript, fonts), `mailto:` and `tel:` links and anchors are skipped. Each page is given 10 seconds and read up to 2 MB; only HTML responses are kept. The crawler identifies itself as `CookiequietBot/1.0` in its user agent; a slow or blocked page is recorded as an error rather than retried indefinitely.

The crawl reaches only what is linked from the pages it visits, within the budget. A page behind a login, a checkout step that needs a cart, or a landing page nobody links to is not scanned.

## Step 2: reading each page

For every page the scanner reads:

- **Script tags.** External scripts by their URL, matched against the provider database's hosts (for example `googletagmanager.com/gtag/js` means Google Analytics 4, `connect.facebook.net` means Meta Pixel). Inline scripts by their content: provider signatures, measurement identifiers (`GTM-`, `G-`, `AW-` and Meta Pixel ids), and the presence of a Consent Mode default call, which tells us whether consent mode is already set up.
- **Iframes**, by their `src` or `data-src`: YouTube, Vimeo, Google Maps, Spotify, Calendly, payment forms.
- **Stylesheets and resource hints** (`preconnect`, `dns-prefetch`): Google Fonts and Adobe Fonts show up here.
- **Image beacons** to known advertising hosts (Meta, Google Ads, DoubleClick, Microsoft Advertising, LinkedIn, Pinterest, X).
- **Set-Cookie headers** in the response: cookie name, domain, and duration computed from `Max-Age` or `Expires` (shown as "Session", "30 minutes", "13 months", "2 years").
- **The platform**, from the generator meta tag and well-known markers: WordPress, Shopify, Wix, Squarespace, Webflow, Framer, HubSpot CMS, Ghost, Hugo, Astro, Nuxt, Next.js and others, which feeds the install instructions we show you.
- **Other consent tools** already installed, and whether Consent Mode is present.

Third-party hosts that are not in the database are listed too, as unknown hosts, so you can see what the database missed.

## Step 3: naming and classifying

Each provider in the database carries a company, a category (necessary, functional, analytics or marketing), the cookies it sets with their typical duration and purpose, where the data goes, and a note for the privacy policy's processors table. When a script from Google Analytics is found, its cookies (`_ga`, `_ga_*`, `_gid`, `_gat`) are added to the table as "declared by provider", because the scanner knows the tool sets them even though it did not see them being set.

Cookies seen in Set-Cookie headers are matched against the database by name, then against generic patterns (session identifiers, CSRF tokens, load balancer cookies). What remains is "unclassified". When an AI key is configured, up to 25 unclassified cookies per scan are sent to Claude (Anthropic) with their names, hosts and the detected platform, and it proposes a category and a one-sentence purpose, with instructions to prefer "necessary" for session and security cookies and to say so. These are informed guesses, shown as such and editable; a cookie you named `promo_seen` is a guess until you confirm it.

Categories you set by hand are kept across rescans.

## Step 4: what comes out

The scan summary lists the providers found and on which page each was first seen, the cookies by category with their source (observed in a header or declared by a provider), the third-party hosts, the measurement ids, the platform, any other consent tool, the Consent Mode flag, the pages crawled and the errors. A `needsConsent` verdict is true when any non-necessary provider or cookie was found. From there the dashboard builds the banner's cookie table, the auto-blocker's host list and the policies' processors table, and the free public tool at [/tools/cookie-scanner](/tools/cookie-scanner) shows a shorter version of the same report for up to 5 pages, without an account.

## What the scanner cannot see

- **Cookies set by JavaScript.** Without running scripts, the scanner cannot watch `document.cookie` being written. It infers those cookies from the providers it recognises. A rendered-HTML option exists (through a headless rendering service, when configured) that shows the page after scripts ran, including tags injected by a tag manager; in that mode the Set-Cookie headers of the original response are not available, so the two modes see different things.
- **What a tag manager loads.** A Google Tag Manager container is recognised by its id, but its contents live in Google's servers and are only visible when the page is rendered.
- **Pages that need a session.** Logged-in areas, carts, checkouts and member pages are not crawled.
- **Unlinked and distant pages.** The budget is 5, 10 or 50 pages; a site with 3,000 pages is sampled, not exhausted.
- **What a script actually does.** The scanner tells you a script comes from Hotjar; it cannot tell you which Hotjar features you enabled.
- **Behaviour after consent.** The scan reads pages as a first-time visitor without a choice. It does not click Accept, so it cannot verify that marked tags activate correctly; the developer tools do that.
- **Variations.** A/B tests, geo-specific pages and personalised content may show the scanner a different page from the one your visitors see.

## How to use it well

Scan after every change to your tags, your theme or your plugins (Starter and Pro rescan weekly; Free monthly or on demand). Treat the cookie table as a draft: confirm the categories of unclassified cookies, add the reason for every cookie you call necessary, since the EDPB taskforce made clear that owners must be able to demonstrate why, and remove entries for tools you no longer use. Then do the one thing the scanner cannot: open the site in a private browser window, before any click, after Reject all, after Accept all, and compare what you see with the table. The [cookie audit checklist](/guides/cookie-audit-checklist) walks through it. A scanner that reads HTML will always be faster than you and less complete than your own eyes; used together, they cover the site.

## Questions

### Why does the scanner list cookies I do not see in my browser?

Because it infers them from the providers it recognises: when it finds the Google Analytics script, it lists the cookies Google Analytics sets, marked as declared by the provider rather than observed. If you configured the tool not to set some of them, remove those rows.

### Why did the scanner miss a tag that is in my Google Tag Manager container?

The container's contents live on Google's servers and only appear when the page's JavaScript runs. The default scan reads the HTML without running scripts; the rendered-HTML option, when configured, shows the tags the container injected.

### Can it scan a staging site behind a password?

No. The crawler fetches pages as an anonymous visitor and does not log in. Scan the public production site, or a staging copy that is reachable without authentication.

### How reliable is the AI classification of unknown cookies?

It is a guess from the cookie's name, its host and the detected platform, written to prefer the necessary category for session and security cookies and to say why. Treat it as a draft to confirm, especially for cookies your own code sets.

## Sources

- [EDPB, Report of the work undertaken by the Cookie Banner Taskforce, paragraphs 26 to 30 on essential cookies and scanning tools (PDF)](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf)
- [Directive 2002/58/EC (ePrivacy Directive), article 5(3)](https://eur-lex.europa.eu/eli/dir/2002/58/oj)
- [CNIL, Recommandation « cookies et autres traceurs » (PDF), on the list of parties using trackers](https://www.cnil.fr/sites/cnil/files/atoms/files/recommandation-cookies-et-autres-traceurs.pdf)
- [ICO, Guidance on the use of storage and access technologies: how do we manage consent in practice?](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/how-do-we-manage-consent-in-practice/)
