Does your site do what your privacy policy says?

Scan any website for the third-party trackers, analytics, session recorders, and fingerprinting scripts that actually load — then compare to what the privacy policy discloses. The gap between those two is where compliance problems live.

We fetch the public homepage only, nothing authenticated, and we don’t log your scans. This is the free, surface-level view — a full privacy audit walks every page template a real visitor hits, not just the front door.

Type in a site

Enter a public URL. We'll fetch the homepage (up to 2MB), parse it for third-party resources, categorize them, and check whether the privacy policy mentions each vendor we found.

Try:

What we look for

14 categories of third-party loads: analytics, advertising, session recording, heatmapping, tag managers, A/B testing, fingerprinting, customer support widgets, marketing automation, consent platforms, CDNs, fonts, social embeds, and CRM enrichment.

The killer check

For every vendor we find, we look at the site's privacy policy and see if it's mentioned. Undisclosed vendors are the single biggest compliance gap we see in the wild — and the one most likely to land a business in a GDPR or CPRA enforcement action.

What we can't see

Only the homepage HTML. Not: what loads after a cookie banner, scripts that fire on form submit, vendors that only run on logged-in pages, server-side data pipelines, or the vendor's own sub-processors. A full audit walks every meaningful page template as a real user.

— exposure

Scan results will appear here.

Privacy policy gap check

How this assessment works — and where it falls short

What we do. We fetch the site’s homepage and follow every link that looks like a privacy / cookie / data-protection document (plus a handful of common fallback paths like /privacy, /cookie-policy, /gdpr). We combine the main-content text of every policy document we can reach into one corpus, strip the nav / header / footer / cookie-banner chrome, and search that corpus with word-boundary matching for each vendor’s name and known aliases.

Our three categories explained.

Disclosed with context — the vendor’s name appears alongside privacy / tracking / third-party language. High confidence this is an intentional disclosure.
Mentioned without clear context — the vendor’s name appears somewhere in the policy, but nothing privacy-related is nearby. It might be a thin disclosure, or it might be incidental (a support email, a corporate-affiliate reference, a page footer link on the policy page itself). Worth a manual read either way.
Not found — no word-boundary match anywhere in the combined policy text.

Where this falls short.

Keyword matching isn’t semantic. A policy saying “we do not share data with Twitter” would count the vendor as disclosed here, even though the plain meaning is the opposite. We flag some of those cases as contradictions but we don’t catch all of them.
JavaScript-rendered policies are invisible. If the policy is a single-page app and the HTML-as-delivered is empty until JS runs, we see no policy text at all.
Sub-processor lists counted only if we can reach them. Large sites often keep their “we share data with” list in a separate document behind a consent banner or a gated page we can’t see.
Our vendor reference list has ~150 entries. Real attackers and auditors know thousands. A site can be using trackers we don’t recognize; those show up under “Unrecognized third parties” at best, and not at all at worst.
We only walked the homepage. Many of the highest-impact trackers fire only on product pages, checkouts, account dashboards, or inside the cookie-banner choice flow — we don’t see those here.

Treat this as a starting-point signal, not a verdict. If a finding matters, open the policy and read the vendor’s context yourself.

All findings by category

Each third-party domain we saw loading on the homepage, grouped by what it does. Click a row to see the specific resource URLs.

What this scan can't tell you

Anything that loads after the banner

Many trackers only fire after a visitor accepts cookies or dismisses a consent prompt. A headless fetch of the HTML doesn't click anything — so those trackers won't appear here. The ones that do appear are the ones loading before any consent is given, which is often the exact problem.

Logged-in or checkout pages

Trackers that only run on product pages, checkout, account dashboards, or email-gated content aren't visible from a public homepage scan. A full audit walks every meaningful page template as a real user.

Server-side pipelines

Server-side tag managers, reverse proxies, and first-party pixel setups hide the vendor from the HTML entirely. The data still flows to the vendor — we just can't see it from the outside. This is increasingly common and deliberately harder to detect.

Sub-processors

A tracker you find here is one vendor. That vendor may have dozens of its own sub-processors who also receive the data. GDPR and CPRA require disclosure of those too. We don't enumerate them — the privacy policy should.

A real audit walks your whole site, not just the front door.

This scan reads your public homepage. A SignumCyber privacy assessment walks every page template a real visitor hits, checks what loads before and after consent, maps every vendor to your written policy, and identifies the specific disclosure changes or configuration fixes you'd need to close the gap. If the homepage scan above flagged anything, the rest of the site almost certainly has more.

Talk to an advisor