CPRA Requirements for Websites

A lot of teams think they are “mostly fine” on California privacy because they already added a footer link years ago that says something like Do Not Sell My Personal Information. Then somebody opens DevTools, sees ad tags firing across half the page, and the whole story starts to wobble.

That is the practical difference with the CPRA. It pushes website privacy out of the abstract policy bucket and into the visible product experience. The question is no longer just whether you published a policy. It is whether the site, the disclosures, the tracking setup, and the user choice flow tell the same story.

In theory, that should be easy. In practice, marketing tools, analytics vendors, embedded widgets, and consent logic drift apart all the time. A privacy page gets updated in January, a new tag goes into Google Tag Manager in March, and by June the website is saying one thing while the browser is doing another.

The CPRA becomes visible in ordinary website details. It shows up in the privacy policy, of course, but also in the cookie banner, the privacy choices link, the categories of trackers you load, and the way your site responds when a user tries to opt out. Buyers, regulators, and privacy-conscious users do not need access to your internal systems to get a first impression. They can learn a lot from the front end alone.

This is why public websites matter so much during reviews. If a homepage is stuffed with advertising pixels, replay tools, and third-party marketing widgets, reviewers will reasonably ask whether the underlying governance is just as loose. A clean-looking policy does not rescue a page that still broadcasts data everywhere.

One useful mindset is this: your website is your privacy program’s storefront window. People can only judge what they can see, so they will use those visible signals as a proxy for everything else.

The part many teams underestimate is how much clearer the CPRA expects you to be about rights. Users should be able to understand what they can ask for, what they can limit, and where to go to make that request. If the policy buries this in dense paragraphs or splits it awkwardly across multiple pages, the experience starts to feel performative.

Sensitive personal information is where this becomes even more obvious. You do not need to be a healthcare company to bump into it. Location data, account credentials, financial details, government identifiers, and a surprising amount of support or onboarding information can fall into more sensitive buckets depending on what the site does. A simple example: if your site collects exact location for service availability, that deserves direct language. Do not hide it behind a vague sentence about “improving the user experience.”

Another common issue is pretending the marketing site is separate from everything else. It rarely is. Newsletter signups, webinar forms, demo request forms, event pages, pricing pages, and customer testimonials can all create data flows that belong in the same privacy story. If the site feeds Salesforce, HubSpot, support tooling, and ad platforms, your policy needs to be honest about that chain.

Good CPRA writing sounds more like a product manager explaining how the system works and less like a template generator trying to sound safe. People should be able to tell what data you collect, why, who gets it, and what the user can do about it without reading the same sentence three times.

Once ad tech enters the picture, the CPRA conversation gets much more concrete. California does not only care about a narrow idea of “sale.” The law also made businesses pay closer attention to the idea of sharing, especially when personal information is used for cross-context behavioral advertising. That matters because many sites do not think of pixels and ad networks as data sharing. They think of them as routine growth tooling.

Browsers do not care what your growth team calls it. They just see requests leaving the page.

This is where website trackers, third-party requests, and the exact placement of your privacy controls start to matter. A footer link that promises choice is not very convincing if the network tab shows marketing calls being made before the user can make that choice. The same goes for a banner that looks polished but does not actually change anything.

Global Privacy Control adds another useful test because it forces the site to respond to a browser-level signal rather than waiting for a user to hunt down a page element. Mature teams like GPC for a simple reason: it exposes whether opt-out logic is built into the system or just bolted onto the interface.

One more thing that comes up often in practice: companies say they do not “sell data,” but the site still includes enough advertising infrastructure that people keep asking the question. If you want fewer awkward conversations, reduce ambiguity. Trim unnecessary vendors, explain what remains, and make the opt-out path feel real.

If you want a realistic first-pass review, do not start by reading the privacy policy in isolation. Open the site like a skeptical outsider.

First, look at the visible experience. Is there a clear privacy link in the footer? Does the site explain user rights in plain language? Can you tell what kind of tracking is happening without guessing? If there is a banner or preference tool, does it feel like something built to help the user or something built to get a quick accept click?

Then open DevTools. Check the Network tab and Application tab. Watch what fires on load, which third-party domains appear, and whether any cookies or requests suggest advertising, analytics, or replay behavior that the policy barely mentions. This step changes the tone of the review fast because it replaces assumptions with evidence.

After that, compare the technical behavior against the written disclosures. Does the policy mention categories that actually match the tools on the page? Does it talk about rights with enough precision? Does the site offer a practical way to act on those rights? If not, you have your gap list.

That is also why automated tools are useful here. A scan is not legal advice, but it is very good at catching the awkward stuff humans miss on a quick pass, like a surprise analytics endpoint, a privacy choices page that is hard to find, or a vendor that was added quietly through a tag manager.

Start with the surface area users can actually see. Tighten the privacy choices link, make sure rights language is readable, and review whether your disclosures match the tracker reality on the page. Then go deeper into sensitive personal information language and browser-level opt-out behavior.

If you want a clean first step, run the free CCPA / CPRA checker, then follow it with a full site scan. That gives you something more useful than a legal memo: a list of visible mismatches you can actually fix.