TL;DR
An automated cookie scan crawls your site in a real browser, recording every cookie, script, and network connection it encounters. Run one before you configure your consent banner, after every major site change, and on a regular schedule. This guide walks through the whole process: triggering a scan, reading the results, acting on what you find, and keeping the inventory accurate over time.
Why Scanning Matters Before Anything Else
You can't build a consent banner that correctly blocks marketing trackers if you don't know which trackers your site loads. You can't write an accurate cookie policy if you haven't inventoried the cookies. And you definitely can't defend your setup to a regulator if your records don't match what's actually on the page.
A cookie scan is the foundation of everything else in consent management. It tells you what's there, who put it there, and what category it belongs in. Without it, you're guessing, and guessed consent configurations are the ones that get fined.
If you want the legal backdrop for why this matters, the GDPR cookie compliance checklist covers that. This guide focuses on the practical how: running a scan, understanding results, and keeping your inventory honest.
What an Automated Scanner Actually Does
An automated cookie scanner launches a real, headless browser (typically Chromium via Puppeteer or Playwright), visits your pages, and records everything the browser encounters:
- Cookies set via HTTP headers and JavaScript (
document.cookie,Set-Cookieheaders). - Scripts loaded from your domain and third-party domains, including inline scripts embedded in the page.
- Network connections the page makes: analytics beacons, ad pixels, font requests, CDN calls, anything that leaves the browser.
- Local storage and session storage writes, which many modern trackers use instead of (or alongside) cookies.
The scanner does this in two phases. First, a pre-consent scan loads the page without any consent given, capturing what fires before the user interacts with the banner. Second, a post-consent scan simulates accepting all categories, capturing what additional trackers appear after consent. This distinction matters because anything that fires pre-consent without being strictly necessary is a compliance violation under GDPR.
For a deep dive into how headless scanning, CDP instrumentation, and drift detection work under the hood, see how cookie scanners work.
Running Your First Scan in CookieBeam
Once you've added your site to CookieBeam and created a banner, the scanner is available from the dashboard.
Start a scan
Open the Scanner tab
Navigate to your banner's dashboard and click the Scanner tab in the left sidebar. You'll see the scan history (empty on first visit) and a Run Scan button.
Enter the URLs to scan
By default, the scanner starts from your site's homepage and follows internal links. You can add specific URLs if you want to scan pages the crawler might not reach naturally, like gated content or single-page-app routes. For most sites, the homepage is enough to start.
Trigger the scan
Click Run Scan. The scanner queues a headless browser job that typically completes in one to five minutes, depending on how many pages it crawls. You can leave the page and come back; the results will be waiting.
Review the results
When the scan finishes, you'll see three inventory tabs: Cookies, Scripts, and Connections. Each item shows its name or URL, the domain it comes from, its detected category, and whether it was seen pre-consent or post-consent.
Interpreting Your Scan Results
The scanner doesn't just list what it found. It classifies each item into a consent category using a multi-layer pipeline:
- URL and domain matching against a database of known trackers (Google Analytics, Meta Pixel, HubSpot, Hotjar, and thousands of others).
- Inline content analysis for scripts embedded directly in the HTML, matching vendor-specific code patterns.
- AI classification for items the pattern matcher doesn't recognize, using the cookie name, domain, and context to infer the category.
Each item in the inventory shows its assigned category with a confidence indicator. Items the scanner is confident about are marked automatically. Items it's less sure about are flagged for your review.
What the categories mean
| Category | Description | Consent required? |
|---|---|---|
| Necessary | Essential for the site to function: session cookies, CSRF tokens, load balancer affinity | No (exempt) |
| Analytics | Measure traffic and behavior: Google Analytics, Clarity, Hotjar | Yes |
| Marketing | Track users for advertising: Meta Pixel, Google Ads, retargeting tags | Yes |
| Preferences | Remember user choices: language, theme, dismissed banners | Yes (in most jurisdictions) |
Watch for pre-consent trackers
If the scanner shows analytics or marketing items firing in the pre-consent phase, those trackers are loading before the visitor has given consent. Under GDPR and the ePrivacy Directive, this is a violation. You'll need to configure your banner to block these scripts until consent is granted. CookieBeam's blocking engine handles this automatically once you've confirmed the item's category.
Acting on What You Find
A scan is only useful if you do something with it. Here's the workflow for turning raw results into a working consent configuration:
Post-scan action checklist
Review items flagged for manual classification
The scanner highlights anything it couldn't confidently categorize. Open each one, check the domain and purpose, and assign the right category.
Confirm or override auto-classifications
The AI classifier is accurate for known vendors but can misjudge custom or niche trackers. Skim the auto-classified list and correct anything that looks wrong.
Check for unknown inline scripts
Inline scripts from your own domain are usually first-party code (menu toggles, form handlers). If they don't set cookies or track users, mark them as necessary.
Verify pre-consent behavior
Anything in the analytics or marketing category that fires pre-consent needs blocking. CookieBeam creates blocking rules automatically, but verify the rules are active.
Update your cookie policy
Your scan results are the source of truth for your public cookie policy. If you found new trackers or removed old ones, update the policy to match.
Publish your banner
Once classifications are confirmed and blocking rules are active, publish the updated banner configuration to your site.
Setting Up Recurring Scans
A one-time scan captures a snapshot. But websites change: developers add new analytics tools, marketing teams install new pixels, third-party scripts update themselves. Without regular scanning, your consent configuration drifts out of sync with reality.
CookieBeam addresses this with two mechanisms:
- Scheduled rescans run on a cadence you set (weekly or monthly is typical). Each scan compares new findings against the existing inventory and flags anything new for review.
- Drift detection runs in the browser itself. The CookieBeam script watches for scripts and connections that weren't in the last scan's inventory and reports them back. This catches changes between scheduled scans.
Together, these mean you don't have to remember to re-audit. When something changes, you get a notification in the dashboard with the new item already classified and ready for you to confirm or override.
For guidance on how often to rescan and what triggers should prompt an immediate re-audit, see how often should you re-scan your site.
How AI Classification Works
Not every cookie or script is in a public database. When the pattern matcher doesn't recognize an item, CookieBeam's AI classifier analyzes the cookie name, the domain that set it, the path, the expiry duration, and the broader context of the page to assign a category.
A cookie named _fbp on .facebook.com is trivially identifiable as Meta marketing. But a cookie named sess_ref_v2 on your own domain could be a session identifier (necessary) or a referral tracker (analytics). The AI considers all available signals to make that call, and it explains its reasoning so you can verify.
Manual overrides always take priority over AI classifications. If you correct a classification, that correction is remembered for future scans, so you only have to make each call once.
Beyond Cookies: Scripts and Connections
Modern tracking goes well beyond Set-Cookie headers. The scanner's script and connection inventories are just as important:
- Scripts reveal what JavaScript runs on your pages. This includes tag managers, analytics libraries, chat widgets, A/B testing tools, and anything else that loads and executes. Each script can set its own cookies, write to local storage, or fire tracking beacons.
- Connections show every outbound network request the page makes. This catches tracking pixels (1x1 image requests to ad servers), beacon endpoints, and data-sharing calls that don't set cookies at all. A page might send data to a third party without ever writing a cookie, and the connection inventory is how you find that.
A complete audit considers all three inventories together. A script that loads from analytics.example.com might set cookies under your domain and fire beacons to a data collection endpoint. The cookie, the script, and the connection are three views of the same tracking behavior.
Common scanning questions
How long does a scan take?
Most scans complete in one to five minutes. The time depends on how many pages the crawler visits and how complex each page is. Single-page applications with heavy JavaScript take longer because the scanner waits for the page to settle before recording.
Does scanning affect my live site?
No. The scanner runs in an isolated headless browser in the cloud. It visits your pages like a regular user would, but it doesn't modify anything. Your real visitors won't notice.
What if my site requires login?
CookieBeam's scanner focuses on the public-facing pages that visitors see before and during the consent flow. If you have authenticated areas that load different trackers, you can add those URLs manually and provide authentication context, but for most sites the public pages are what matter for consent.
How often should I re-scan?
At minimum, after every significant site change (new analytics tool, redesign, new marketing campaign). A weekly or monthly scheduled scan catches changes you might not notice. See how often should you re-scan for a detailed answer.
Can the scanner detect server-side tracking?
The scanner detects what the browser can see: outbound network requests, cookies set via HTTP headers, and JavaScript execution. Purely server-side tracking (like server-side GTM forwarding data to a measurement endpoint) happens after the browser's request, so it won't appear in a client-side scan. For server-side tracking compliance, see our server-side consent enforcement guide.
What Comes Next
Once your scan results are reviewed and your inventory is classified, you're ready to configure your banner's blocking behavior, write your cookie policy, and publish. The scan is step one, not the end.