Cookie Scanning & Auditing: Know What Your Website Sets

You cannot comply with cookie regulations if you do not know which cookies your website sets. This seems obvious, yet it is the single most common point of failure in cookie compliance. Websites evolve constantly — new plugins are installed, marketing tags are added, third-party scripts are updated — and each change can introduce new cookies. A cookie audit is not a one-time activity. It is an ongoing process that must keep pace with your website's evolution.

Why Cookie Scanning Matters

Every cookie compliance obligation depends on having an accurate, complete inventory of your cookies. Without it:

• Your cookie banner is incomplete. If your banner lists four categories of cookies but your site actually sets cookies in a fifth category, users cannot give informed consent. Their consent is invalid under the GDPR.
• Your cookie policy is inaccurate. Data Protection Authorities expect your cookie policy to list every cookie by name, purpose, type, and duration. An incomplete or outdated policy is a compliance failure that DPAs actively look for during audits.
• Your consent mechanism may not block all cookies. If a newly added script sets cookies that are not included in your consent management configuration, those cookies fire without consent — a direct violation of Article 5(3) of the ePrivacy Directive.
• You cannot respond to user requests. Under the GDPR, users have the right to know what data you collect about them. If you do not know which cookies your site sets, you cannot provide accurate responses to data subject access requests.

What a Cookie Scan Reveals

A thorough cookie scan identifies:

• Cookie names: The exact identifier for each cookie (e.g., _ga, _fbp, JSESSIONID).
• Origin: Whether the cookie is first-party (set by your domain) or third-party (set by an external domain).
• Type: Session cookie (deleted when the browser closes) or persistent cookie (remains for a specified duration).
• Duration: How long the cookie persists before expiring (e.g., 30 minutes, 1 year, 2 years).
• Purpose: What the cookie does — session management, analytics, advertising, personalization, or functional purposes.
• Category: The compliance category the cookie belongs to — strictly necessary, functional, analytics/performance, or marketing/advertising.
• Third-party provider: If the cookie is set by a third party, which service it belongs to (Google Analytics, Facebook, HubSpot, Hotjar, etc.).
• Data collected: What information the cookie stores or enables the collection of.

Manual Cookie Scanning with Browser DevTools

The most basic method of cookie scanning uses the developer tools built into every modern browser. While manual scanning has significant limitations, it is useful for spot-checking and understanding how cookies work on your site.

Step-by-Step: Manual Cookie Audit in Chrome

1. Open an incognito/private window. This ensures you start with a clean slate — no existing cookies from previous visits.
2. Open DevTools (press F12 or right-click and select "Inspect").
3. Navigate to the Application tab (in Chrome) or the Storage tab (in Firefox).
4. Expand the "Cookies" section in the left sidebar. You will see a list of domains.
5. Visit your website without interacting with the cookie banner. Note which cookies are set immediately — these are the cookies set before consent, which should only be strictly necessary cookies.
6. Accept all cookies on your cookie banner. Refresh the Application/Storage tab and note the new cookies that appear.
7. Navigate through key pages of your website (homepage, product pages, checkout, contact form, blog). Some cookies are only set on specific pages or after specific interactions.
8. Document each cookie: For each cookie you find, record its name, domain, path, expiration date, size, and whether it is HTTP-only or secure.
9. Check the Network tab for additional tracking. Some tracking technologies use pixels, beacons, or API calls rather than traditional cookies. The Network tab reveals all outgoing requests to third-party domains.

Limitations of Manual Scanning

Manual scanning is valuable for learning and spot-checking, but it has serious limitations for compliance purposes:

• Incomplete coverage. You can only check pages you visit manually. A large website with hundreds of pages may set different cookies on different pages. Manual scanning cannot practically cover them all.
• No categorization. DevTools show you the raw cookie data but do not categorize cookies by purpose or compliance category. You must research each cookie individually.
• Point-in-time only. Manual scanning gives you a snapshot. It does not detect new cookies added after your audit.
• No script blocking verification. Manual scanning cannot easily verify that your consent management platform is correctly blocking scripts before consent.
• Time-consuming. For a site with even 20 pages, manually checking each page and documenting each cookie takes hours.

Automated Cookie Scanning

Automated cookie scanning tools address the limitations of manual scanning by crawling your entire website, identifying all cookies, and categorizing them systematically. A good automated scanning tool provides:

• Comprehensive crawling: The scanner visits every page on your site (or a defined subset), including pages that are only accessible through navigation or search.
• Before and after consent: The scanner checks which cookies are set before consent is given, which appear after consent, and whether declined categories are properly blocked.
• Automatic categorization: Known cookies (such as Google Analytics' _ga or Facebook's _fbp) are automatically categorized based on maintained databases of cookie purposes.
• Third-party identification: All third-party domains setting cookies are identified and documented.
• Scheduled scanning: Scans run automatically on a schedule (weekly, after deployments) to catch new cookies as they appear.
• Change detection: The scanner alerts you when new cookies appear or existing cookies change, so you can update your consent mechanism and cookie policy.
• Compliance reports: Results are formatted in a way that supports your compliance documentation.

What to Look for in a Cookie Scanning Tool

When evaluating automated cookie scanning solutions, consider:

1. JavaScript rendering: Many cookies are set by JavaScript that runs after the page loads. The scanner must execute JavaScript (using a real browser engine) to detect these cookies. Simple HTTP crawlers that do not render JavaScript will miss most third-party cookies.
2. Depth of crawling: The scanner should follow internal links and crawl your entire site, not just the homepage. Cookies set by embedded videos, forms, chat widgets, or payment processors on specific pages will be missed if only the homepage is scanned.
3. First-visit simulation: The scanner should simulate a first-time visitor (no existing cookies, no consent given) to verify that no non-essential cookies are set before consent.
4. Cookie database: A maintained database of known cookies with their purposes and categories dramatically reduces the manual effort of classification.
5. Reporting: Clear, exportable reports that can be shared with legal, marketing, and development teams.
6. Scheduling and alerts: Automatic scanning on a configurable schedule with notifications when new cookies are detected.

The Cookie Scanning Process

A thorough cookie scan follows five steps, whether performed manually or with automated tools:

Step 1: Crawl All Pages

Start by building a complete map of your website. This includes all public pages, authenticated pages (if applicable), landing pages, thank-you pages, error pages, and any page that a visitor might access. Do not limit your scan to the homepage — cookies are frequently set by third-party scripts that only load on specific pages (e.g., a YouTube embed on a blog post, a payment processor on the checkout page, or a chat widget that only appears on support pages).

Step 2: Identify All Cookies

For each page, record every cookie that is set. This includes both HTTP cookies (visible in the Set-Cookie header and the browser's cookie storage) and client-side storage mechanisms (localStorage, sessionStorage, IndexedDB) that may function as tracking technologies even though they are not technically cookies.

Step 3: Determine Cookie Origin

For each cookie, identify whether it is first-party (set by your own domain) or third-party (set by an external domain). Third-party cookies are particularly important for compliance because they typically involve sharing data with external organizations, which requires disclosure in your cookie policy and, in many cases, a data processing agreement.

Step 4: Classify Cookies by Category

Assign each cookie to a compliance category:

• Strictly necessary: Required for the website to function. Cannot be disabled by the user. Examples: session cookies, CSRF tokens, load-balancing cookies, cookie consent preference cookies.
• Functional: Enable enhanced functionality and personalization. Examples: language preferences, region selection, recently viewed items (when not used for advertising).
• Analytics/Performance: Collect information about how visitors use the website. Examples: Google Analytics, Hotjar, Matomo cookies.
• Marketing/Advertising: Track visitors across websites for advertising purposes. Examples: Facebook Pixel, Google Ads cookies, retargeting cookies, affiliate tracking cookies.

Step 5: Document Purpose, Duration, and Type

For each cookie, document its purpose in plain language that a non-technical person can understand, its duration (session or persistent, and if persistent, how long), and its type (HTTP cookie, localStorage, etc.). This documentation forms the basis of your cookie policy and the information provided in your cookie banner.

Ongoing Monitoring

A cookie scan is only valid at the moment it is performed. Your website is not static — it evolves with every deployment, plugin update, and marketing campaign. Ongoing monitoring is essential because:

• New scripts introduce new cookies. When a developer adds a new analytics tool, a marketing team installs a new tracking pixel, or a plugin is updated, new cookies may appear on your site without anyone explicitly deciding to add them.
• Third-party scripts change. Even if you do not change your website, the third-party services you use may update their scripts and introduce new cookies. A Google Analytics update, a social media widget change, or a CDN configuration update can all affect the cookies on your site.
• Compliance is continuous. DPAs expect your cookie policy and consent mechanism to reflect the current state of your website. A policy that was accurate six months ago but does not include cookies added since then is non-compliant today.

Best practice is to run automated scans after every deployment and at a minimum monthly. Set up alerts for new cookies so that your team can evaluate, categorize, and add them to your consent mechanism before they become a compliance issue.

Cookie Scanning and Your Cookie Policy

Your cookie policy and your cookie scan results must stay in sync. Every cookie identified in a scan should be documented in your policy, and every cookie listed in your policy should actually be present on your site. A mismatch in either direction is a problem:

• Cookies on site but not in policy: This means users are not informed about all tracking on your site. Their consent, even if given, may not cover undisclosed cookies.
• Cookies in policy but not on site: While less serious, listing cookies that do not exist creates confusion and undermines trust in your documentation's accuracy.

The most efficient approach is to integrate your scanning tool with your cookie policy, so that the policy is automatically updated when new cookies are detected. This eliminates the manual step of updating the policy after each scan and reduces the risk of the two falling out of sync.

How Passiro Handles Cookie Scanning

Passiro's scanner uses a headless browser engine to visit every page of your website, executing JavaScript exactly as a real visitor's browser would. This ensures that cookies set by dynamically loaded scripts, embedded content, and single-page application frameworks are all detected. The scanner runs before and after simulated consent to verify that your consent management is working correctly — that non-essential cookies are truly blocked until consent is given.

Scan results are categorized automatically using a continuously updated database of known cookies, with the option to manually classify or reclassify any cookie. Scheduled scans run on a configurable basis, and you receive alerts when new cookies appear on your site so you can take action before they become a compliance risk.

How Often Should You Scan?

The right scanning frequency depends on how often your website changes:

• After every deployment: Any code change has the potential to introduce new cookies. Integrate cookie scanning into your CI/CD pipeline or run a scan after each release.
• After adding third-party services: Whenever you add a new analytics tool, marketing platform, chat widget, payment processor, or any third-party script, scan immediately.
• Monthly at minimum: Even if you make no changes, third-party scripts on your site may update and introduce new cookies. A monthly scan catches these changes.
• After CMP updates: If you update your Consent Management Platform or change your cookie categories, scan to verify that the changes work as expected.
• Quarterly review: Beyond automated scanning, conduct a quarterly manual review of your cookie inventory to verify that categorizations are still accurate, that third-party providers are still necessary, and that your cookie policy reflects reality.

The organizations that treat cookie scanning as routine maintenance rather than a periodic audit are the ones that maintain continuous compliance — and avoid the unpleasant surprise of discovering undocumented tracking cookies during a DPA investigation.