Scraping Google Maps Is Legal — The Part That Gets You in Trouble Is Everything After

Every few months someone in a sales Slack asks whether scraping Google Maps is legal, and forty replies arrive with the confidence of people who have never read a court opinion. Half say it is obviously fine because the data is public. The other half say it is obviously illegal because Google's terms forbid it. Both are answering a question narrow enough to be useless.

The interesting risk in a local-business sourcing pipeline is almost never the act of collection. It is the twelve decisions you make in the ninety seconds after the data lands: which fields you keep, which you discard, whether you retain the owner's name that appeared in a review, how long the record lives if nobody ever contacts it, and whether the same dentist in Bonn enters your pipeline four times under three spellings.

Those decisions determine both your legal exposure and whether the list is worth calling. They are also the ones nobody argues about on Slack.

Three Separate Legal Questions Wearing One Coat

"Is scraping legal" collapses three unrelated bodies of law into one question. They have different answers, different enforcers, and different consequences, and conflating them is how teams end up simultaneously over-cautious and genuinely exposed.

Computer-crime law — largely settled, and in your favour. The line of US cases running from hiQ v. LinkedIn through Meta v. Bright Data in 2024 has consistently held that accessing publicly available data, without circumventing a login or an authentication barrier, does not violate the Computer Fraud and Abuse Act. Nothing in 2026 has disturbed this for ordinary business-listing data. If your scraper reads what an anonymous browser can read, you are not committing a computer crime.

Contract law — unsettled, and not in your favour. Google's Maps Additional Terms prohibit bulk extraction, and its January 2026 update added more specific examples of prohibited conduct. Courts declining to treat scraping as a crime have been notably less willing to say it is not a breach of contract. The realistic consequence is not damages; it is being blocked, having an API key revoked, or receiving a letter. That is a business risk to price in, not a criminal one to lose sleep over.

Data-protection law — the one that actually bites, and the one everyone skips. GDPR does not care that a phone number was publicly visible. It cares whether the number identifies a natural person. "Dr. Meier's dental practice, +49…" is personal data whether you scraped it or copied it off a shop window. This is the body of law with a regulator, a complaint mechanism, and fines that scale with your revenue.

The pattern worth internalising: the question people argue about is the one that is settled, and the question nobody asks is the one with the enforcement teeth.

What Is Actually Worth Keeping

Once you accept that the legal weight sits in retention rather than collection, field selection stops being a storage decision and becomes a risk decision. Every field you keep is a field you must justify, secure, disclose on request and eventually delete.

Business identity — keep all of it. Trading name, address, category, opening hours, website URL, the main business phone. This is the record. A Zahnarztpraxis in Bonn is an organisation, and organisational data carries the lightest load.

Named individuals — keep almost none of it. Google Maps surfaces owner names, reviewer names and occasionally personal mobile numbers. A reviewer's name has no conceivable sales purpose and is unambiguously personal data belonging to someone who has no relationship with you. Discard it at parse time, before it ever reaches your database. Data you never stored is data you cannot leak, cannot be asked to produce, and cannot be fined over.

Reviews — quote sparingly, store almost never. Review text is authored content that may carry copyright, and review authors are private individuals. An aggregate rating and a review count give you everything a sales conversation needs. The full text of a one-star rant gives you a liability with a quotation mark on each end.

Anything you cannot name a use for — do not keep it. This sounds like a platitude until you apply it honestly to a scraper's default output, which will happily hand you thirty fields when your pipeline uses nine. The default output of a tool is not a specification.

Why the List Is Worse Than You Think

Legal correctness gets you a list you are allowed to own. It does not get you a list worth working, and the gap between the two is wider than most teams discover before their first hundred calls.

The same business arrives repeatedly, spelled differently. Run two identical searches a week apart and you will not get identical results. Google returns different sets, businesses update their listings, and the same practice appears as "Zahnarztpraxis Dr. Meier", "Dr. Meier Zahnarzt" and "Praxis Dr. med. dent. Meier". Name matching will not save you. Domain and phone number are the only fields stable enough to dedupe on with confidence.

Two runs that look identical are not proof of anything. When we ran the same Google Maps source twice against dentists in Bonn, twenty places each, the result was twenty-four leads with zero duplicate domains or phone numbers. Fifteen of the second run's twenty merged into existing records. The five that imported were genuinely different practices Google surfaced the second time — not duplicates that slipped through. That distinction only became visible because dedupe ran on domain and phone rather than on name, and because the import kept provenance for every merge.

Volume feels like progress and usually is not. A thousand scraped records with 40% duplication, no website on a third of them, and no way to tell which were already contacted last quarter is not a better starting position than two hundred clean ones. It is a worse one, because it takes longer to work and it burns the suppression list you have not built yet.

The listing is a snapshot with a short shelf life. Local businesses close, move, rebrand and change numbers constantly. A sourcing record with no capture timestamp is a record you cannot age out, and a list nobody ages out becomes a list nobody trusts.

Building the Pipeline So the Hard Parts Are Automatic

The practices that keep a sourcing operation both legal and useful are structural. They work because they are enforced by the pipeline rather than remembered by the person running it.

Filter at parse time, not at review time. Drop personal names, reviewer identities and review bodies in the parser, before the first write. A field that never enters the database cannot be forgotten in a later cleanup, and cleanup passes are where good intentions go to die.

Dedupe on domain and phone, and record why records merged. Normalise both aggressively — strip www, unify country-code formats, lowercase everything — then match. When two records merge, keep the provenance: which source run, which fields came from where. When someone asks in three months why a lead has two conflicting phone numbers, provenance answers it and memory does not.

Give every record a source, a timestamp and a retention horizon at creation. Not later, not in a migration. A lead nobody has touched in twelve months is not a lead; it is a GDPR liability with a name attached. Automatic expiry is far easier to defend to a regulator than a policy document nobody has run.

Build the suppression list before the first campaign, not after the first complaint. A do-not-contact obligation attaches to the person, not to the campaign, and it must survive re-imports. If a fresh scrape can resurrect someone who opted out last spring, you do not have a suppression list — you have a filter that works until the next import.

Write down why you are collecting, once, before you start. A legitimate-interest assessment is a page of prose stating what you collect, why, and why it does not override the recipient's rights. It takes an afternoon. Written before collection it is a defence; written after a complaint it is an exhibit.

What This Separates

Teams that treat sourcing as a data-acquisition problem end up with large lists, high duplication and an uncomfortable inability to answer basic questions about where any given record came from. Teams that treat it as a data-retention problem end up with smaller lists that are safe to work, cheap to maintain, and defensible on a bad day.

The second group is not more cautious. They are usually calling more businesses, because their list is not 40% noise and they are not re-litigating the same lead three times under different spellings.

The legality question that dominates the discussion has been answered by several courts and is unlikely to change. The question that determines whether your pipeline is a liability is what you kept, why you kept it, and whether anything in your system will ever delete it. Decide that at the parser, where it costs a line of code, rather than at the audit, where it costs considerably more.