When the General Data Protection Regulation (GDPR) took effect on 25 May 2018, a lot of people assumed it either banned web scraping or had nothing to do with it. Neither is true. GDPR doesn't mention scraping at all — but it governs personal data, and the moment your crawler collects a name, an email address, or even an IP address tied to a person in the EU, you are "processing personal data" and the regulation applies to you.
This guide explains, in practical terms, how GDPR and scraping intersect in 2026: when scraping personal data is lawful, the obligations that catch scrapers off guard, and a concrete checklist for running GDPR-compliant scraping projects. It's general guidance, not legal advice — for a specific project, talk to a qualified data-protection lawyer or your DPO.
Does GDPR apply to your scraping?
Two questions decide it.
1. Are you collecting personal data? Under GDPR, personal data is any information relating to an identified or identifiable natural person. That's broad: names, emails, phone numbers, physical and IP addresses, cookie and device identifiers, location, photos, and social profiles all qualify. Purely non-personal data — product prices, stock levels, specifications, weather, aggregate market figures — generally falls outside GDPR entirely. If your project only needs that kind of data (most price and catalog monitoring does), you largely sidestep the regulation. Scoping personal fields out is the single most effective compliance move there is.
2. Does it involve people in the EU/EEA? GDPR has extraterritorial reach (Article 3). It's not about where your company or servers sit — it's about whose data you process. If you're scraping personal data about individuals in the EU or EEA, GDPR can apply even if your business is in the US, UK, Australia, or anywhere else. (The UK enforces its own near-identical UK GDPR post-Brexit.)
If you answered "yes" to both, keep reading. If you're new to the mechanics of collection itself, our primer on what is web scraping sets the scene.
"It's public" is not a free pass
The most common myth is that public data is fair game under GDPR. It isn't. GDPR draws no exemption for personal data merely because it's publicly visible on a website. A public LinkedIn-style profile, a name on a company page, or an email in a forum signature is still personal data, and scraping it is still processing that needs a lawful basis. Public availability may influence a balancing test (below), but it does not remove your obligations.
This is exactly where US and EU thinking diverge, and why people get confused. In the US, cases like hiQ Labs v. LinkedIn found that scraping publicly accessible data likely doesn't violate the Computer Fraud and Abuse Act — a computer-access question. But that same case ended with hiQ found to have breached LinkedIn's user agreement, and it says nothing about EU privacy law. "Legal to access" under US computer-crime law is a completely different question from "lawful to process" under GDPR. For the broader legal picture across jurisdictions, see our guide to web scraping legality.
Finding a lawful basis for scraping personal data
GDPR requires a lawful basis (Article 6) for every processing activity. There are six, but only two are realistic for scraping, and one of those barely works:
- Consent is almost never feasible for scraping. You'd have to obtain freely given, specific, informed consent from each person before collecting their data — impossible when you're harvesting from third-party sites.
- Legitimate interests (Article 6(1)(f)) is the basis most scraping relies on. It permits processing that's necessary for your legitimate interests provided those interests aren't overridden by the individual's rights and freedoms. Using it correctly means documenting a Legitimate Interests Assessment (LIA) — a three-part test: (1) is there a genuine, lawful interest? (2) is scraping necessary to achieve it? (3) does a balancing test show your interest isn't outweighed by the intrusion on the individual? People generally don't expect their data to be mass-collected and repurposed, so the balancing test is where many aggressive projects fail.
Whichever basis you pick, decide and document it before you start, not after a complaint arrives.
Special category data: the hard stop
Some data is off-limits without meeting stricter conditions (Article 9): information revealing racial or ethnic origin, political opinions, religious beliefs, trade-union membership, health, sex life or sexual orientation, and genetic or biometric data. Scraping this "special category" data — including building biometric datasets from scraped faces — is high-risk and usually unlawful without explicit consent or another narrow legal condition. The Clearview AI enforcement wave is the cautionary tale: for scraping billions of facial images from the open web and social media to build a biometric search tool, it drew €20 million fines from regulators in Italy, France, and Greece, and a €30.5 million penalty from the Dutch DPA. (The UK ICO's £7.5 million fine was later overturned on jurisdictional grounds — a reminder that scope, not just conduct, is contested.) The pattern is clear: scraping sensitive personal data at scale attracts the biggest penalties.
The obligation scrapers forget: Article 14 transparency
Here's the one that surprises people. When you collect personal data directly from someone (a signup form), you tell them what you're doing under Article 13. When you obtain it indirectly — which is exactly what scraping is — Article 14 requires you to inform each individual anyway: who you are, what data you hold, why, your lawful basis, how long you'll keep it, and their rights. You must do so within a reasonable period, at most one month.
That's genuinely hard when you've scraped thousands of people who never gave you their contact details. GDPR allows a narrow exemption where providing notice would involve "disproportionate effort" (Article 14(5)(b)), but you can't just assume it applies — you have to assess and document it, and regulators read it narrowly. A well-known Polish enforcement action fined a data broker that scraped business contact data from public registers and then, citing cost, emailed only some people while merely posting a notice on its website for the rest — the regulator held that failing to individually inform people it had contact details for breached Article 14. Plan your transparency approach up front; it's often the deciding factor in whether a project is defensible.
Data subject rights you must honor
Anyone whose data you hold can exercise GDPR rights, and you need a working process to answer them:
- Access — tell them what you hold about them.
- Rectification — correct inaccurate data.
- Erasure ("right to be forgotten") — delete on valid request.
- Objection — stop processing based on legitimate interests if they object and you can't show overriding grounds.
- Restriction and portability in defined cases.
If you scrape personal data but have no way to find and delete one person's records on request, you're not compliant — full stop.
GDPR and email scraping
Scraping email addresses deserves its own warning because it's so common and so risky. An email address is personal data, so harvesting it is processing that needs a lawful basis and Article 14 notice like anything else. But email scraping usually has a second purpose bolted on — sending marketing — and that engages the ePrivacy rules (the ePrivacy Directive, implemented nationally, e.g. PECR in the UK; the long-proposed ePrivacy Regulation is still not adopted as of 2026). For electronic marketing to consumers, those rules generally require prior consent, with only a narrow "soft opt-in" for a business's own existing customers. Scraping a list of consumer emails and cold-mailing them typically fails on both counts: no GDPR lawful basis or notice, and no ePrivacy consent. B2B rules are more permissive in some member states, but "scrape addresses, then blast them" is one of the fastest routes to a complaint. If you build contact datasets, treat lawful outreach as a separate problem from collection. (Our write-up on email scraping with Python covers the technical side; the sending side is where the legal exposure lives.)
A GDPR-compliant scraping checklist
Bring these together into a repeatable process:
- Scope out personal data where you can. If prices, stock, and specs are all you need, don't collect names and emails "just in case." No personal data, far less GDPR.
- Establish and document a lawful basis — usually legitimate interests, backed by a written LIA and balancing test.
- Minimize. Collect only the fields your purpose actually requires; anonymize or pseudonymize as early as possible.
- Avoid special-category data unless you have specialist advice and an Article 9 condition.
- Plan Article 14 transparency — a clear privacy notice, and a defensible approach to informing individuals (or a documented exemption).
- Build data-subject-rights handling — a real process to find, export, and delete a person's records.
- Keep records and assess risk — maintain a Record of Processing Activities, and run a Data Protection Impact Assessment (DPIA) for large-scale scraping of personal data.
- Secure the data — encryption, access controls, retention limits; don't hoard.
- Mind downstream use, especially marketing (ePrivacy/PECR consent) and profiling.
- Respect robots.txt and terms of service — not a GDPR requirement, but it lowers your overall legal risk (contract, computer-access) and signals good faith.
- Watch international transfers — moving EU personal data outside the EEA needs a valid mechanism (adequacy decision or Standard Contractual Clauses).
Penalties make the effort worthwhile: the top tier reaches €20 million or 4% of global annual turnover, whichever is higher.
Where a service helps
Getting this right is as much process as code — deciding what not to collect, documenting a lawful basis, and honoring erasure requests. When scraping.pro delivers a project as a managed web scraping service, that discipline is built in: scoping data to what's actually needed, minimizing personal fields, and structuring collection so the output is useful without dragging in liability you didn't intend to take on. For many commercial use cases — competitor pricing, catalog and availability monitoring — the valuable data isn't personal at all, which is the cleanest position to be in under GDPR.
Verdict
GDPR doesn't forbid web scraping — but it firmly governs the scraping of personal data, and "it's public" is not a defense. The projects that get into trouble are the ones that hoover up personal (or worse, sensitive) data with no lawful basis, no transparency, and no way to honor deletion requests. The projects that stay clean minimize personal data, document a legitimate-interests basis, plan for Article 14 notice and data-subject rights, and keep marketing use behind proper consent. Do that, and GDPR-compliant scraping is entirely achievable.
FAQ
Does GDPR allow web scraping? Yes, when it's done lawfully. GDPR doesn't ban scraping; it requires that any scraping of personal data about people in the EU/EEA has a lawful basis, meets transparency duties, and respects individuals' rights.
Is scraping public personal data legal under GDPR? Public availability doesn't exempt personal data from GDPR. You still need a lawful basis (usually legitimate interests) and must meet your obligations; it's simply one factor in the balancing test.
Is scraping non-personal data covered by GDPR? No. Prices, product specs, stock levels, and other non-personal data fall outside GDPR. Scoping your project to non-personal data is the simplest way to avoid the regulation.
Can I scrape emails and send marketing under GDPR? Rarely without consent. The emails are personal data (GDPR), and marketing to them engages ePrivacy rules that generally require prior consent for consumers. Cold-emailing scraped consumer lists is high-risk on both fronts.