Is Scraping Google Maps Legal? A Practical Compliance Guide

It is the first question most people ask about scraping and the one that gets the worst answers. Search for it and you will find confident one-liners in both directions: "public data is fair game" and "scraping violates the terms of service, so it's illegal." Both are wrong in the same way. They treat a question with at least four separate legal dimensions as though it had one, and they answer it as though the answer were the same in Texas and in Bavaria.

The honest version is more useful and not much harder to hold in your head. Collecting public business listings from Google Maps is a routine, widely practised activity that courts in several jurisdictions have declined to treat as unlawful access. The risk in practice almost never sits in the act of collection. It sits in what you collected, how you got to it, and what you did next — and those three are where teams actually get into trouble.

This guide walks through the four bodies of law that matter, the distinctions that decide real cases, and a practical compliance checklist. It is written by a team that builds scraping tools and thinks about this constantly. It is not legal advice, and it cannot be: the answer genuinely depends on your jurisdiction, your data, and your purpose. If you are about to build something material on scraped data, this is the briefing to take to a lawyer, not a substitute for one.

The four questions hiding inside "is it legal"

Almost every argument about scraping legality is really an argument about one of these, with the participants each talking about a different one:

• Computer access law — did you access a computer system without authorisation? In the US this is the Computer Fraud and Abuse Act; other countries have equivalents.
• Contract law — did you agree to terms that prohibited this, and did you breach them? This is separate from access law and it is where the losses tend to happen.
• Data protection law — was any of what you collected personal data about an identifiable human being? If yes, GDPR or its equivalents apply regardless of how public it was.
• Intellectual property — copyright in the content you copied, and in Europe a separate database right in the collection itself.

They are independent. You can be entirely clear under access law and still lose a contract claim. You can collect nothing but public facts and still have a data protection obligation, because "public" and "not personal data" are different things. Sorting your situation into these four buckets is most of the analysis.

Computer access law: the narrow one

This is the question people mean when they ask whether scraping is "hacking," and it is the one that has moved most in favour of scrapers over the last several years.

In the United States, the Computer Fraud and Abuse Act criminalises accessing a computer "without authorization" or in a way that "exceeds authorized access." For years, companies argued that continuing to scrape after a cease-and-desist letter, or in breach of a site's terms, converted ordinary access into a federal computer crime.

Two developments narrowed that considerably. In Van Buren v. United States (2021) the Supreme Court read "exceeds authorized access" narrowly: it covers obtaining information from areas of a system you are not permitted to enter at all, not misusing information you were allowed to see. The Court's framing was a gate — either it is open to you or it is not — rather than a rulebook about acceptable purposes.

In hiQ Labs v. LinkedIn, the Ninth Circuit held that scraping data from public profiles, visible to anyone without logging in, was unlikely to be access "without authorization" under the CFAA. The reasoning is intuitive: a page served freely to every visitor on the open internet is not a locked door.

The part almost everybody leaves out of that story matters more than the part they tell. hiQ is routinely cited as "scraping public data is legal," and on the CFAA point that is fair. But the case did not end there. On the contract claims, the court later found that hiQ had breached LinkedIn's user agreement, and the matter resolved on terms that were not a victory for hiQ. The lesson is not "scraping won." It is that hiQ won the access argument and lost the contract argument — which is precisely why treating these as one question misleads people.

Contract law: where cases are actually decided

If computer access law is the dimension scrapers usually win, contract law is the one they usually lose. And the deciding factor is refreshingly concrete.

Terms of service bind you when you have agreed to them. Creating an account and clicking through a sign-up flow is agreement. Being served a public page by a web server, having agreed to nothing, is a much weaker basis for a contract claim — you cannot easily be held to a bargain you never entered.

This distinction drove the outcome in Meta v. Bright Data (2024), where the court found for the scraper on Meta's breach-of-contract claims in significant part because the collection happened while logged out rather than as a signed-in user. The pattern across recent cases is consistent enough to state as a working rule:

Collecting pages that any anonymous visitor can see is a substantially different legal position from collecting the same data from behind a login. Authenticated scraping imports the entire terms of service into your risk profile.

For Google Maps specifically, that maps onto a clear practical distinction. Business listings, categories, addresses, ratings, review counts and review text are served to anyone who visits. Nothing about reading them requires an account. That is the low-risk posture. Signing into a Google account and automating it is a different activity with a different risk profile, and it is also how people get accounts terminated, which is a real cost even where it is not a legal one.

Two practical notes. First, a cease-and-desist letter changes your position even if it does not create a contract: continuing after one invites claims and looks wilful, and it is the point to involve counsel rather than to dig in. Second, being polite matters — rate limiting your collection, not degrading the service for others, and staying well clear of anything that resembles a denial-of-service pattern. Aggressive volume turns a boring activity into an interesting one.

Data protection: the one that actually applies to you

Here is the part most scraping guides skip, and it is the one most likely to affect a European or UK business. "Publicly available" is not an exception to GDPR. There is no clause that says data protection stops applying once information is visible on a website. If what you collected relates to an identifiable living person, you are processing personal data and you have obligations.

So which parts of a Google Maps pull are personal data? The line is not where people assume.

Field	Usually personal data?	Why
Company name, address, coordinates	No	Identifies a business, not a person
Category, rating, review count, hours	No	Attributes of the business
info@, contact@, sales@ addresses	No	Role addresses, not tied to an individual
firstname.lastname@company.com	Yes	Identifies a specific person
A named owner, manager or contact	Yes	Identifies a specific person
Sole trader's business phone and address	Often yes	For a one-person business the business details are the person's details
Review author name, profile and review text	Yes	An identifiable individual and their expressed opinion

That last row surprises people, and it is the one worth internalising. A review dataset is not a dataset of business facts. It is a dataset of named individuals' opinions, which is personal data about the reviewer as much as it is feedback about the business. It is entirely lawful to work with — reputation monitoring and competitor research are legitimate purposes — but you have to do so knowingly rather than assuming it sits outside the rules.

What GDPR actually requires of you

Four obligations do most of the work in practice.

A lawful basis. For B2B research and prospecting this is normally legitimate interests under Article 6(1)(f), not consent — you cannot realistically obtain consent from someone before collecting their published contact details. Legitimate interests is a real basis, but it is conditional: you must actually carry out and document the three-part assessment. Is there a genuine interest? Is the processing necessary to achieve it? Does it survive a balancing test against the individual's rights and reasonable expectations? Write it down. An undocumented legitimate interests assessment is functionally the same as not having a lawful basis when a regulator asks.

Transparency. Article 14 covers data you did not obtain from the person themselves, which is exactly this situation. You must tell them you hold their data, what you are doing with it, and on what basis — within a month, or at the point of first contact if that comes sooner. In practice this means a privacy notice that honestly describes scraped-data processing, and a line in your first email that says where you got their details. The second one costs you nothing and does more for your reply rate than most people expect, because it reads as candid rather than creepy.

Data minimisation and retention. Collect the fields your purpose needs, not every field available. Delete records you are not using. A dataset from three years ago that nobody has looked at is pure liability with no offsetting value — and for business data it is also substantially wrong by now, so nothing is lost by dropping it.

Rights, especially objection. Where you rely on legitimate interests, Article 21 gives the individual an unconditional right to object to direct marketing. You must stop, and you must be able to keep stopping. That means a suppression list that survives your next data refresh — otherwise you re-import the same person next quarter and contact them again, which converts a handled request into a demonstrable compliance failure. Suppression has to be keyed on something stable and checked on every import.

Cold outreach is a separate question again

Lawfully holding a business email address does not mean you may lawfully email it. That is governed by separate marketing rules, and they vary sharply by country in ways that catch people out:

• UK (PECR) — unsolicited marketing email to a "corporate subscriber," meaning a company or LLP, does not require prior consent. Sole traders and partnerships are treated as individuals and do require it. Opt-out and sender identification are required either way.
• Germany (UWG §7) — among the strictest in Europe. Prior consent is required in practice even for B2B, and enforcement comes through competitor actions and cease-and-desist letters with cost consequences, not just regulators. If you are prospecting into Germany, this is the constraint that matters most, and it is not satisfied by anything you do at the data collection stage.
• US (CAN-SPAM) — permits cold commercial email without prior consent, but requires accurate headers, a non-deceptive subject line, an identifiable postal address, and a working opt-out honoured promptly. State laws may add to this.
• Canada (CASL) — consent-based, with a narrower set of implied-consent routes such as a conspicuously published business address relevant to the recipient's role. Stricter than CAN-SPAM, closer to the European model.

The practical consequence: segment your outreach by the recipient's country before you send, not after someone complains. The same list can be perfectly fine to email in Chicago, marginal in London and actionable in Munich.

Copyright and database rights

Facts are not copyrightable. A business's name, address, phone number, opening hours and coordinates are facts about the world; nobody owns them, and the effort of compiling them into a directory does not create ownership either — that is the holding of Feist v. Rural Telephone Service in the US, and a similar principle applies broadly.

Review text is different. A review is an original expression written by a person, and copyright in it belongs to that author. Extracting reviews to analyse them — counting themes, scoring sentiment, spotting recurring complaints — is analysis, and the output is your own work product. Republishing large volumes of review text verbatim on your own site as content is a different act with a real copyright dimension, and at scale it also tends to create the kind of derivative directory that attracts other claims. Analyse freely; think carefully before republishing.

Europe adds one more layer that has no US equivalent: the sui generis database right, from the EU Database Directive. It protects substantial investment in obtaining, verifying or presenting a database's contents, independently of copyright in the contents themselves. It is aimed at wholesale extraction of a substantial part of someone's database, not at querying a source for the records relevant to your market. Worth knowing exists; rarely the binding constraint on a normal research or prospecting pull.

The patterns that create real risk

After all of that, the risky behaviours are a short and fairly obvious list. Almost nobody gets into difficulty doing ordinary market research. Trouble concentrates here:

• Scraping from behind a login. Imports the full terms of service into your risk profile and is the single clearest difference between recent cases that went well and badly.
• Collecting personal data with no lawful basis and no documentation. The most common actual compliance failure, and entirely self-inflicted.
• Emailing into strict jurisdictions on the assumption that B2B is exempt. It is not, in several countries.
• Ignoring objections, or losing them at the next data refresh. Turns a resolved complaint into evidence of a systemic problem.
• Republishing scraped content wholesale as a competing directory or a reviews aggregator.
• Volume that degrades the source. Recreational-grade request rates turn an unremarkable activity into an adversarial one.
• Reselling a raw personal-data list. Multiplies every obligation above and removes your ability to honour any of them.

A practical compliance checklist

None of this is onerous once, and all of it is painful retrofitted. If you are collecting public business data for research or prospecting, work through this before your first significant pull:

• Collect logged out. Public pages only. No automated account activity.
• Classify your fields. Mark which ones are personal data. Know before you collect, not after a subject access request.
• Write the legitimate interests assessment. Half a page. Purpose, necessity, balancing. Date it and keep it.
• Say so in your privacy notice. That you collect business data from public sources, which categories, for what purposes.
• Disclose the source in first contact. One sentence. Both a legal requirement and, in practice, better outreach.
• Build the suppression list before you need it. Keyed on a stable identifier, checked on every import, never cleared by a refresh.
• Set a retention period and actually enforce it. Stale business data is wrong data as well as liability.
• Segment outreach by jurisdiction. Before sending, not after complaints.
• Rate limit. Be a boring visitor.
• Keep an audit trail. What you collected, from where, when, and on what basis. This is what turns a stressful enquiry into a short email.

Where a managed tool helps, and where it does not

Worth being precise about this, because vendors are frequently vague on it. Using Livescraper rather than your own scraper changes some of the picture and none of the rest.

What it does address: collection happens against public pages without any account of yours being automated, so the authenticated-scraping risk — the sharpest distinction in the case law — does not arise. The Google Maps Data Scraper returns business-level records, and you choose which fields you take, so minimisation is a setting rather than a project. Every task keeps a record of what was collected and when, which is the audit trail the checklist above asks for. And because collection is rate-managed centrally, the volume-and-aggression failure mode is not yours to get wrong.

What it does not address, and no tool can: your lawful basis is yours. Your privacy notice is yours. Whether you may email a given recipient in a given country is yours. The Email & Contact Scraper will find published addresses including personal-format ones, and the Reviews Scraper returns author names with review text — both of which are personal data you have taken on the responsibility of holding. A tool can give you clean inputs and a defensible collection story. The purpose and the outreach are the controller's job, and that is you.

A worked example

Suppose you are a UK agency selling local SEO services, and you want a prospect list of independent dental practices across three German cities and two UK ones.

The collection is unremarkable. Practices maintain public Maps listings; you pull them by category and city, logged out, at a sane rate, taking name, address, category, website, rating, review count and phone. Every one of those is business-level data. Your legitimate interests assessment is short and genuinely passes: you have a real commercial interest, a published business listing is the obvious way to identify prospects, and a practice would not be surprised to be contacted by an agency about its own online visibility.

The picture changes at enrichment. Asking for contact emails returns a mix: praxis@ addresses that are not personal data, and dr.schmidt@ addresses that plainly are. Both go in the same column, so you need to have decided in advance how you treat that column — which here means treating the whole column as personal data, because you cannot rely on the format.

And it changes again at outreach, where the German and UK halves of the same list part company. In the UK, the practices structured as limited companies can be emailed without prior consent, with identification and an opt-out; sole practitioners cannot. In Germany, prior consent is required in practice for all of them, so cold email is the wrong channel entirely — that half of the list is for research, for LinkedIn, for a phone call, or for a partner who already has a relationship. Same scrape, same day, two completely different downstream answers. That is the whole point: the legality question does not live at the collection step, which is where everyone asks it.

Conclusion

Collecting public business listings from Google Maps is a normal commercial activity, and the direction of legal travel has been favourable to it: courts have repeatedly declined to treat reading public pages as unauthorised computer access. But that is one question of four, and it is not the one most likely to bite you. The contract dimension turns on whether you logged in. The data protection dimension turns on whether any of your fields identify a person — and if you collect emails or reviews, some of them do. The outreach dimension turns on which country your recipient is in, and differs enough between the UK, Germany, the US and Canada that a single sending policy cannot be right everywhere.

Handle those four deliberately and the compliance burden is a short checklist and an afternoon of writing things down. Ignore them and the risk does not come from scraping at all; it comes from what you did with the data afterwards, which is where it has always been. Livescraper collects from public sources, logged out, with an auditable record of every task, so the collection side of that story is a straightforward one to tell — leaving you to get the purpose, the notice and the outreach right, which were always the parts that needed your judgement.

This article is general information from a scraping tools team, not legal advice. Data protection and marketing law vary by jurisdiction and change; take specific advice before building a business on scraped data.

Related reading: How to Find Businesses Missing Email Addresses Using Google Maps, Why Google Maps Is One of the Best Sources for Building a B2B Database, How to Build Better Cold Email Campaigns Using Google Maps Data.