Auto-scanner

The CookieBeam scanner crawls your site with a real browser and builds an inventory of the cookies, scripts, and network connections it finds. Review cookies in the Discovered tab of Cookies. Review scripts and connections in the Discovered tab of Scripts & Connections. Nothing reaches your banner until you publish.

What a scan detects

• Cookies — first- and third-party, with name, domain, path, and lifetime.
• Scripts — external scripts by URL, plus inline script blocks. Framework noise (hydration payloads, JSON-LD, server-rendered data blobs) is filtered out before it reaches your inventory, and first-party config blobs are suppressed rather than flagged for review.
• Network connections — every outbound request the page makes, captured at the network level. This catches pixels and beacons that never set a cookie.

After the baseline scan, the published banner keeps watching: connections that appear in production but weren't in the scan are reported as drift, and recurring drift is promoted into your inventory for review — so a tag added by a colleague last week doesn't stay invisible.

How findings are classified

Detected items pass through layered classification, strongest evidence first:

1. Manual overrides — your own classifications always win. A cookie you reclassify keeps your category through later scans.
2. AI-assisted and curated database matches — cookie names and domains are checked against a curated cookie database and saved AI classifications.
3. URL and domain rules — scripts and connections match exact and pattern-based domain rules with path heuristics (a large built-in dictionary of known vendors and sources).
4. Inline content patterns — inline scripts are matched on their source text against vendor fingerprints (tag managers, pixels, session recorders, and similar).

Every finding lands in a category — necessary, analytics, marketing, preferences, or unknown — with a vendor name where the classifier recognized one, and an origin marker telling you whether the item came from a scan or from live production traffic (drift). Anything in unknown is your review queue. Inventory rows may also carry a friendly source label ("Google Analytics", a plugin or theme name) — that label is display grouping to make a long inventory readable; it is not a classification layer, and no numeric confidence score or classifier-layer identifier is stored on findings.

What the inventory feeds — and what it does not

Classified findings feed two things:

• Blocking — categorized scripts and connections compile into the published bundle's blocking tables (see Blocking), so enforcement tracks what the scanner actually found.
• Cookie and tracking disclosures — detected cookies, scripts, and connections populate the inventory, drift, and tracking data your cookie declarations and policy tables draw from.

The inventory does not build your banner's categories or services. The categories and per-service toggles shown in the preferences panel come from your banner's own configuration — the Categories section of the banner designer — and a scan does not create or modify them. A completed scan marks the banner as having unpublished changes, but the category and service list stays exactly as you configured it. Use the inventory as the reference when you edit categories and services by hand: reclassify unknowns, then mirror the vendors you want to disclose into your banner configuration.

Running a scan and publishing the results

1. Open Dashboard → Scanner and start a scan for the site or page you want covered.
2. When it completes, open Cookies and Scripts & Connections from the scanner page. Work through each Discovered tab: reclassify anything in unknown, and correct wrong categories or vendors — your overrides win over every classifier layer on later scans.
3. Where disclosure needs it, edit the banner's categories and services by hand to mirror the reviewed inventory (designer Categories section). The blocking tables pick up the reviewed inventory automatically — no separate rule editing needed for scanner-detected resources. Engine-level blocking overrides, if you need them, live under Scanner → Settings.
4. Click Publish in the banner header. Only the published bundle enforces and discloses the new configuration.
5. Verify on a clean browser profile: denied-category scripts and connections stay blocked, and allowed ones execute after consent.

Scan limits

Starter, Professional, and Business include fixed monthly manual-scan limits and enforce them as hard caps. When a team reaches its limit, further scans are refused with an upgrade prompt until the counter resets or the limit changes. These plans do not bill pay-as-you-go scan overages. The seeded Enterprise entitlement has unlimited manual scans. The backend also supports an entitlement override that disables hard-limit enforcement, but that capability does not establish a generally available overage plan.