CCPA and Web Scraping: A 2026 Guide for US Companies

Does the CCPA apply to web scraping?

Yes, when the scraped records contain personal information about California residents and your business meets one of the CCPA's thresholds. The law is written around what the information is and who it describes, not around how you obtained it. A name and an employer pulled off a public profile page is personal information in exactly the same way it would be if the person had typed it into your signup form.

This is the single most common misreading in engineering teams. The reasoning goes: the page was public, no login was involved, no Terms of Service prohibited it, therefore no privacy obligation attaches. The first three points can all be true and the fourth still does not follow. Whether you were allowed to access the page and whether you now have compliance duties over what you stored are two separate questions under two separate bodies of law. Our guide to whether web scraping is legal covers the access half. This piece covers the storage half.

What counts as "publicly available information" under the CCPA?

California does exempt "publicly available" information from the definition of personal information, but the statutory definition is narrow. It covers information lawfully made available from federal, state or local government records, plus information a business has a reasonable basis to believe was lawfully made available to the general public by the consumer themselves or from widely distributed media.

Read that carefully, because the gap between it and "I found it on the open web" is where most scraping programs sit. Property records from a county assessor are squarely inside the exemption. A court docket is inside it. A person's own public post is arguably inside it. But a scraped profile from a site the person did not control, a set of reviews stitched back to one reviewer, or a contact list assembled from a dozen company pages is a much harder argument, because you are relying on a consumer having made that specific information public, not on the page having been reachable.

Two further limits are worth knowing. The exemption does not cover biometric information a business collected without the consumer's knowledge. And it turns on the information, not the dataset: combining exempt fields with non-exempt ones does not make the whole record exempt. It usually works the other way, because inference and linkage are what make a profile identifying in the first place.

Do the CCPA thresholds actually apply to my company?

The CCPA reaches for-profit businesses that do business in California and meet at least one of three tests. As of the 2026 compliance year those are:

The third test is the one that surprises people, because it has no revenue minimum. A six-person company whose product is a contact database is covered while a much larger company that scrapes only product prices is not. Note also that the revenue threshold counts worldwide gross revenue, and that being headquartered outside California changes nothing if you are processing Californians' data.

What is the California DELETE Act, and does it apply to scrapers?

SB 362, the DELETE Act, is the law most likely to bite a scraping business in 2026, and it is newer than most compliance write-ups reflect. It requires data brokers to register with the California Privacy Protection Agency every January, and it created a single state-run portal, the Delete Request and Opt-out Platform (DROP), where a resident files one request that reaches every registered broker at once.

The timeline matters. DROP opened to consumers on January 1, 2026, but brokers were not obliged to act on those requests until August 1, 2026. That date has now passed. From it forward, a registered data broker must check DROP at least once every 45 days and process the deletion requests it finds within that same window. Penalties are meaningful and they accrue daily: $200 per day for failing to register by the January 31 deadline, and $200 per deletion request per day for failing to process requests once the obligation started.

There is a real operational consequence here that has little to do with lawyers. Honoring a deletion request means finding every copy of that person's record, which includes the ones that left your database months ago as an export. Teams that let analysts pull ad hoc extracts and drop them into shared drives discover at exactly the wrong moment that they cannot answer where the data went. If your pipeline routinely ends with someone exporting scraped records to a CSV, that file is in scope too, and the growing number of consumer services that submit removal requests on a person's behalf means the volume is going up rather than down.

Am I a data broker under California law?

California defines a data broker as a business that knowingly collects and sells personal information about consumers with whom it does not have a direct relationship. That last clause is the whole test, and scraping fails it almost by construction. The people in a scraped dataset have never been your customers, never visited your site and have no idea you exist, so there is no direct relationship to point at.

So the question is narrower than it looks. If you scrape personal information and sell or share it, you are very likely a data broker and should be registered. If you scrape personal information purely for internal use and never sell or share it, you are probably not a broker, though you may still be a "business" with full CCPA obligations. And if you scrape no personal information at all, prices, product specs, documentation, public filings, none of this applies to you. That last category is larger than teams assume, and moving into it deliberately is the cheapest compliance strategy available.

What do I actually have to do if I scrape personal data?

Assuming you are a covered business, the practical obligations are these:

• Disclose the collection. Your privacy policy has to say what categories you collect, where they come from, why, and how long you keep them. "Publicly available sources" is an acceptable source description; silence is not.
• Honor consumer rights. Access, deletion, correction and opt-out of sale or sharing, with a working intake channel. You cannot require someone to create an account to exercise a right.
• Register as a data broker if you sell or share. Every January, with CalPrivacy, and process DROP requests on the 45 day cycle.
• Flow obligations down by contract. Vendors that process the data on your behalf need service provider terms. That includes the tools in your scraping pipeline.
• Keep the lineage. Record which source URL and which run produced each record. Deletion and correction are close to impossible without it, and it is far cheaper to capture at write time than to reconstruct later.

How is the CCPA different from the GDPR for scraping?

The structural difference is where the burden starts. The GDPR requires a lawful basis before you process personal data at all, so scraping EU residents means arguing legitimate interests up front, running a balancing test, and dealing with a transparency duty you often cannot satisfy because you have no way to contact the people involved. The CCPA does not ask for a lawful basis. It lets you collect, then attaches disclosure duties and consumer rights afterwards.

In practice that makes California the more forgiving of the two for a scraping business, and it is why teams that build for GDPR first usually find CCPA compliance mostly covered. Going the other direction rarely works. If you have EU-facing exposure, start with GDPR and web scraping for US companies, then layer California's registration and DROP mechanics on top.

How do I keep scraped data out of CCPA scope entirely?

By not collecting personal information, which is more achievable than it sounds. Most commercial scraping targets do not require it. Price monitoring needs a product, a price and a timestamp. Documentation ingestion for a RAG system needs text. Competitive research needs company-level facts. In each case the personal fields are incidental, and the reason they end up in the database is that someone wrote "extract everything on the page" rather than naming the fields they wanted.

Schema-first extraction is the fix, and it is a technical control rather than a policy one. When you declare the exact fields you want and the extractor returns only those, personal data cannot arrive by accident, because there is no column for it. That single design choice does more for your compliance posture than any amount of policy language, and it is why structured data extraction is worth preferring over dumping raw HTML and sorting it out downstream. ClawEngine also stays on public, permitted pages only, respects robots.txt and Terms of Service, and never targets logins or paywalled content. See how we approach compliance for the full picture.

Where personal data genuinely is the point, as it is in lead generation, accept that you are in scope, register if you sell or share, and build deletion in from the start rather than bolting it on the first time a DROP batch lands. The teams that struggle are not the ones that decided to collect personal data. They are the ones that never decided at all.

This article is general information about US privacy law, not legal advice. Talk to counsel about your specific pipeline.