Site Watch

Site Watch scans your own website in a real browser and records what it sends to third parties. It then compares that traffic with your published privacy policy and with your vendors’ own terms.

It exists because demand letters built on recorded network traffic from public websites are a growing genre: a visitor opens a site, saves what it transmits to advertising and analytics tools, and sends the log back as evidence. Site Watch lets you see what that scan would show before someone else runs it.

Site Watch is included in every business plan: on its own at $49/month or $490/year for one domain, in Business ($79/month or $790/year), and in Enterprise ($2,999/year, up to 5 domains). Extra domains are $150/year each on any plan.

The free scan

Before you sign up, you can run one free scan at pryvc.com/free-scan. Enter your work email and your website; the email must be at the same domain you scan (you@yourcompany.com for yourcompany.com), and free email providers are not accepted. Ticking “I work for…” records your authorization as a PRYVC consent certificate — our own certified consent, issued into PRYVC’s account — and you can verify it at the link we show you. We email you a link — nothing runs until you open it and press Start my scan. The scan is the same one the portal runs, and the report stays available through your link for 30 days. During those 30 days someone at PRYVC may email you about your results; after them, the report and your email address are deleted. Each domain, and each email address, gets one free scan.

Run a scan

1. Verify your domain. Site Watch only scans domains you have proven you own — see Verify your domain in the business guide.
2. Open Site Watch in the business portal.
3. Enter a URL on a verified domain.
4. Select Run scan.
5. Open the report when the scan finishes.

You can run a scan whenever you like — after a tag change, a new consent banner, or a privacy policy edit. From any finished report you can also turn on Re-scan weekly + email me: that page is then scanned every week, so there is a record even when nobody remembers to ask for one, and the business’s owners get an email when a weekly scan finds something the previous scan of the same page did not — new high, medium, or review findings. The email lists the findings by title and links to the report; it never includes the captured requests themselves. Scans you run by hand do not send email, and neither does the first weekly scan of a page, since it has nothing to compare against.

What a scan does

A real browser visits up to 8 pages of your site, in three consent states:

State	What it represents
Before any choice	A fresh visitor who has not touched the consent banner.
After rejecting	The visitor declined.
After accepting	The visitor agreed.

The consent banner is handled automatically for common consent tools. Where Site Watch cannot operate your banner, the scan covers the before any choice state only, and the report says so — it does not imply coverage it does not have.

In each state it records:

• Every third-party request — who received it (the vendor, and its category: advertising, analytics, marketing automation, and so on).
• The page address and page title sent along with the request.
• The identifiers attached to it.
• Google consent signals — the consent state your tags reported to Google on that request.
• Cookies, and how long each one lasts.

What it compares the traffic with

Your privacy policy. Site Watch reads the policy you publish and reports:

• vendors that received requests but are not named in the policy, and
• policy statements the observed traffic appears to sit against. These are pattern matches on the published text, quoted word for word; read each one in the context of your full policy.

If your site publishes a health-information notice (a HIPAA-style Notice of Privacy Practices) as well as a website privacy policy, Site Watch reads both and keeps them apart: vendors are checked against the website policy, and a promise in the health-information notice is shown as an item to review with counsel rather than as a conflict.

Your vendors’ terms. Vendors publish their own rules about how their tools may be used. Where a vendor’s terms restrict the kind of use observed — for example, health-related pages feeding analytics or marketing tools — Site Watch flags it as an item to review and links to the vendor’s page.

How to read a finding

Every finding has the same parts:

• What was observed — the request itself, attached in raw form: where it went, in which consent state, on which page.
• What it is set against — for a policy finding, the sentence from your privacy policy, quoted; for a vendor-terms finding, a link to the vendor’s page.
• Why it was raised — the rule that matched.

Findings are produced by deterministic rules. None are generated by AI, so the same traffic always yields the same finding, and anyone can check a finding against the request attached to it.

A finding is not a verdict. It tells you that your site did something, and that it differs from something you published or agreed to. Whether that is a legal problem — and what to do about it — is a question for you and your counsel. Vendor-terms findings in particular are labeled as items to review: read the linked terms as they stand today.

The recommended fix: hold trackers until consent

From any finished report in the portal you can build a consent gate — a small script, generated from that scan, that you paste into your own pages. It keeps the trackers the scan found from loading until a visitor accepts, shows an accept/decline prompt with equal weight on both choices, and treats a browser’s Global Privacy Control signal as a decline. It is pasted inline; nothing is loaded from PRYVC or anyone else.

It is a recommendation, not a guaranteed fix. It holds back the trackers found in that scan; it does not make a site compliant with any law. Have a developer test it on your site and have your legal counsel review it before you rely on it.

How to use it:

1. Paste the snippet as the first thing inside <head> on every page, above every other script.
2. For each tracker tag written directly in your HTML, mark it inert: <script type="text/plain" data-gate-src="https://vendor.example/tag.js"></script>. Tags added by a tag manager need no change.
3. Add a “Privacy choices” link that calls pryvcGate.reset().
4. Test every page type, then run a new scan to see what still leaves before a choice.

What it cannot do, from our own testing on live sites:

• A tracker tag already in your page HTML is stopped from running, but the browser may already have fetched the file, so the vendor can still see the visit. Marking the tag inert (step 2) prevents that.
• Trackers that run inside an iframe or a web worker are out of reach. Shopify runs its marketing pixels that way: on a Shopify store, set consent in Shopify’s Customer privacy settings as well — the snippet alone is not enough.
• Data your own servers send to a vendor never passes through the page, so neither the snippet nor a scan can see it.
• The list of trackers is fixed when you build the snippet. A tracker added later is not held until you build it again from a newer scan — the weekly re-scan tells you when that happens.
• If your site already runs a consent tool, configure that tool to hold trackers before a choice rather than adding a second prompt.

The report as a record

• Scope statement. Every report states the pages visited, the date, the browser, and which consent states were covered.
• SHA-256 hash. Every report carries a hash of its contents, so a copy can be checked against the original.
• History. Scans are kept. You can show what your site did on a given date, and when a fix landed.

Limits

Read these before relying on a report:

• Site Watch never certifies a site as “compliant”. It reports findings with evidence. A report with no findings means the rules matched nothing on the pages scanned — not that the site meets any law.
• It is not legal advice.
• It cannot see server-to-server sharing. A browser scan observes what leaves the browser. Data your own systems send directly to a vendor is outside its view.
• A scan reflects the pages visited, at that time, from that location. Pages outside the scan, tags that fire only for some visitors or regions, and changes made after the scan are not covered.