Website Privacy Scanning: Trackers, Fingerprinting, Consent

TL;DR: Website privacy scanning loads your pages in an instrumented browser and records what actually happens: every tracker request, ad pixel, session recorder, storage write, fingerprinting call, and whether a "reject all" click is honored. The output is an evidence-backed inventory of visitor data flows, which very often contradicts what the site's own privacy policy promises.

Most privacy failures on the web are not caused by malice. They are caused by drift. A marketing pixel gets added for one campaign and never removed. A tag manager quietly loads scripts nobody audited. The privacy policy describes the data practices someone believed were in place when it was written. A privacy scan describes the data practices actually running in a visitor's browser today. The gap between those two is where regulatory and reputational risk lives.

What does a website privacy scan actually do?

A privacy scan does not read your privacy policy or your cookie declarations. It loads your pages the way a real visitor would, in an instrumented browser, and observes behavior directly. The instrumentation records three streams of evidence:

• Network activity. Every request the page makes, with each third-party hostname matched against curated tracker intelligence to identify its owner and its category (advertising, analytics, or other).
• Storage activity. Every cookie set by script or by HTTP header, plus writes to localStorage, sessionStorage, and IndexedDB, and any service worker registrations.
• API activity. Calls to browser APIs associated with fingerprinting, beacons, WebSocket connections, and permission probing, attributed to the specific script that made them.

Because everything is observed from the visitor's side of the browser, the scan needs no credentials, no agent, and no access to your servers. OnScanner's privacy engine classifies this evidence into more than 40 categories, and the methodology page explains how each finding traces back to the signal that produced it.

What do tracker and ad pixel checks reveal?

The most visible layer is the tracker inventory: requests to domains owned by an organization other than the site being visited. A scan separates advertising trackers, which build cross-site behavioral profiles, from analytics and other categories.

Advertising pixels deserve special attention. Conversion and retargeting pixels report visitor actions (page views, sign-ups, purchases) back to the ad platform, frequently attaching advanced-matching parameters: hashed email addresses, phone numbers, and device identifiers that tie a real identity to behavior across sites and apps.

A thorough scan also catches the delivery channels designed to be missed:

• Beacons sent through navigator.sendBeacon, built to fire reliably as the visitor leaves the page.
• WebSocket and server-sent-event connections that stream data continuously and bypass request-based blockers.
• Server-side tagging endpoints on your own subdomains that forward conversion data to ad platforms after the browser can no longer see it.
• CNAME cloaking, where a first-party-looking subdomain resolves, through DNS, to a known tracker, letting it evade blocklists and set first-party cookies.

Each is a deliberate pattern for moving data collection out of sight; a scan that only counts cookies misses all four.

Why is session recording its own risk category?

Session replay tools record mouse movement, scrolling, clicks, and often keystrokes and form contents: in effect, a screen recording of the visit. That recording can include text a visitor typed and then deleted, or entered into a form and never submitted. If a replay script runs on a checkout page, a health questionnaire, or a support form, the site may be capturing exactly the kind of data its policy says it does not collect. Detection from the outside is straightforward, because the page makes requests to known recording services.

What about storage that outlives cookies?

Cookie banners govern cookies, but modern persistence rarely stops there. Third-party scripts write identifiers into localStorage and sessionStorage, which most cookie controls never touch. IndexedDB offers large, durable storage that visitors rarely clear. Service workers persist after the tab closes and can intercept future requests to re-seed identifiers that were deleted. A privacy scan attributes each of these writes to the script that made it, so first-party application storage is not confused with third-party tracking. Fingerprinting goes one step further and builds a device identifier with no stored state at all; see canvas, WebGL, and audio fingerprinting for how those techniques work and are detected.

How do consent checks prove a banner is real?

A consent banner is a promise, and the only way to test a promise is to take it up. Consent verification loads the page twice: once accepting all cookies and once rejecting them, then compares the tracker and cookie activity between the two passes. If advertising trackers still fire after a visitor clicks reject, the banner is decoration, and the scan records which requests ignored the choice.

The scan also detects whether a consent management platform is present at all, by polling the standard consent APIs and reading the IAB TCF and GPP consent strings. Tracking with no consent mechanism is a gap; a consent mechanism that is ignored is worse, because it documents a choice that was never honored. Under the GDPR, such violations carry fines of up to 20 million euros or 4 percent of worldwide annual turnover. Teams closing the gap between banner behavior and legal obligations can pair scan evidence with GDPR compliance consulting.

What personal data exposure can a scan catch directly?

Beyond cataloging trackers, a privacy scan inspects what actually leaves the browser:

• PII in third-party payloads. Request bodies and URLs sent to third parties are checked for email addresses, phone numbers, tokens, and payment-card patterns. That is exfiltration, not analytics.
• Form harvesting. The scanner fills form fields with unique test values, then watches outgoing requests. If those exact values appear in a request before the form was submitted, the field was harvested as the visitor typed.
• Link decoration. Outbound links carrying click identifiers pass a tracking handle to the destination site, stitching activity across domains even when cookies are blocked.

How do the findings fit together?

Each category of a privacy scan answers a different question about what happens to a visitor:

Why do sites fail their own privacy policies?

Because nobody owns the delta. Legal writes the policy at a point in time. Marketing adds tags continuously. Vendors update SDKs on their own schedule, and scripts load further scripts from hosts the site never chose. Six months later, the policy describes a site that no longer exists. A privacy policy can become a legal liability in its own right once enforcement compares its promises against observable behavior.

The remedy is not better prose. It is evidence on a schedule: scan, reconcile findings against the policy and the banner, fix or disclose, repeat. OnScanner runs this as a live, never-cached scan across more than 40 privacy and tracker categories, on demand or scheduled, alongside the security reconnaissance in what an attacker can see on your website.

Frequently asked questions

Does a privacy scan need access to my code or servers?

No. A privacy scan observes your site from the visitor's side: it loads pages in an instrumented browser and records the network requests, storage writes, and API calls any real user's browser would perform. Regulators and users experience your site the same way. Server-side data handling still needs internal review, but browser-side behavior is fully testable from outside.

Can a scan tell whether my cookie banner is compliant?

It can test the part that matters most: whether the banner's choices are honored. By scanning twice, once accepting and once rejecting, and comparing which trackers fire, a scan produces direct evidence of consent violations. Full compliance also involves policy language and lawful bases, which is legal work, but banner behavior is the piece most often broken and the easiest to verify.

How often should a privacy scan run?

On every meaningful release, and on a schedule between releases. Tracker inventories drift whenever marketing adds tags, vendors update SDKs, or a script in the supply chain changes what it loads. Monthly scanning is a reasonable baseline, and weekly suits sites with active tag management. Scheduled monitoring catches the change when it happens instead of during the next audit.