Google Maps hands you the business name, category, address, phone, rating, coordinates and website domain. It does not hand you an email address — not once in a sample of 20 Austin dental practices pulled while writing this. Scraping Maps for leads is therefore a two-stage job: collect the listings, then crawl the domains.
What a Google Maps listing actually contains
Most guides skip straight to tooling. Start instead with the record you are going to get, because it decides the rest of the pipeline. Here is the field set returned for a plain dentist in Austin TX query, checked against the first page of results:
| Field | Present on the listing | Useful for |
|---|---|---|
| Business name | Yes | Matching, dedup, personalisation |
| Category | Yes — e.g. Dentist, Cosmetic dentist, Dental clinic | Segmenting the list |
| Full address | Yes | Territory assignment, dedup |
| Phone | Yes | Calling — the channel with the fewest surprises |
| Website domain | Usually | The key to stage two |
| Rating | Yes | Weak proxy for size and maturity |
| Coordinates and place id | Yes | Stable dedup key, mapping, re-checks |
| Email address | No | — |
That last row is the whole design constraint. Every product advertising "emails from Google Maps" is doing the second stage for you, whether it says so or not: it takes the domain from the listing and fetches pages from the business's own website. Knowing that changes how you budget, how you rate-limit, and which failure you plan for — because the second stage is where coverage actually drops.
The three notes worth writing on the whiteboard before you build anything:
- The place id is your primary key. Names and addresses drift; suite numbers get typed three ways. Dedup on the place id and you can re-run the same territory next quarter and diff it.
- Category is the segmentation you already paid for. A query for one trade returns several adjacent categories. Keep the raw category string; do not flatten it into your own taxonomy at collection time.
- The phone is the highest-yield field. It is present on essentially every listing, it needs no second fetch, and in the UK and US it is the channel where the rules are clearest.
Four ways to pull the data, and what each one costs you
These are the real options, with the trade-off that actually bites rather than the one the marketing page mentions.
- The official Places API. Clean, supported, and bound by service-specific terms that restrict how long you may cache most fields and forbid using the content alongside a non-Google map. It is the right choice when you are building a product feature. It is an awkward choice for a one-off prospecting list you intend to keep in a CRM indefinitely.
- A browser extension. Fine for fifty rows. It runs at the speed of your own laptop, it dies when the DOM changes, and it gives you no re-run story, so the list you built in March cannot be diffed in June.
- A DIY headless-browser scraper. Maximum control, and you now own the two problems that consume the time: rendering the results panel reliably, and getting enough clean network egress that a few thousand requests do not all look like one machine. That second problem is why residential proxies exist as a product category at all.
- A ready-made collector. You send a semantic input — a trade and a city — and get rows back. QuanticData's Google Maps collector runs at $0.001 per delivered place, and the lead collector does both stages in one call at $0.01 per enriched lead. Failed requests are not billed, which matters more than the headline rate once you start tiling a metro area.
There is no morally superior option here. There is a maintenance budget, and the question is whether you would rather spend it on your parser or on your outreach.
Why one query is never the whole city
A single Maps query returns a bounded page of results — twenty in the sample above, with pagination beyond it. It does not return "every dentist in Austin", and no amount of scrolling makes it. Maps ranks by relevance and proximity to the map viewport, so the result set is a function of where you are looking from.
The fix is tiling, and it is unglamorous:
- Split by geography. Run the query once per neighbourhood, postcode or coordinate grid cell rather than once per city. Dense trades in dense metros need finer cells; a rural county may need one.
- Split by category vocabulary. Dentist, cosmetic dentist, dental clinic and dental implants provider all appeared in one sample. Query the synonyms, then dedup on place id.
- Set the exit condition on new-unique-rows, not on page count. Stop tiling a cell when a pass adds nothing you have not already seen. That is the only signal that correlates with coverage.
- Keep the query that produced each row. When coverage looks wrong in three weeks, provenance is the only thing that tells you which tile under-collected.
If you would rather see the shape of a target's URL space before you commit to a crawl strategy, the crawl and map endpoint does that job for websites the same way tiling does it for Maps.
The second pass: turning a domain into a contact
Stage two is a small, well-defined crawl of each business's own website. It is cheap per site and it is where the list is actually won or lost.
- Fetch a handful of pages, not the whole site. The home page, anything matching
/contact,/about,/team,/impressum, and the footer of whatever you land on. Four to six pages covers the large majority of small-business sites. - Read the structured data first. Many small-business sites ship schema.org
LocalBusinessJSON-LD with the email, phone and opening hours already parsed. It is more reliable than regexing the rendered text. - Then take
mailto:links, then text matches. In that order. Amailto:is a deliberate publication; a string that merely looks like an address in body copy is often a customer's, a former employee's, or an image caption. - Record whether the mailbox is a role or a person.
info@,contact@andhello@are role addresses in the sense of RFC 2142 — published for exactly this purpose. A named mailbox belonging to an identifiable human is personal data with a different compliance profile, and it deserves a different column, not the same one. - Store the source URL per field. When someone asks where you got their address — and under EU and UK rules they are entitled to — the answer needs to be a URL, not a shrug.
Mechanically this is a scrape-and-extract job: fetch, parse, pull fields. QuanticData's Web Scraping API does it at $0.0002 per page, or you can hand the whole stage to the site contacts collector at $0.02 per site and skip writing the parser. The same two-stage pattern underpins company data collection more generally.
Verification before outreach, not after
A scraped list is a hypothesis. Verify it before it touches a sending domain, because the cost of not doing so is not a bounce — it is your domain reputation.
Google's published sender guidelines are unusually concrete about this. Every sender needs SPF or DKIM; senders above 5,000 messages a day to personal Gmail accounts need SPF, DKIM and DMARC, with the From: domain aligned to one of them, plus one-click unsubscribe headers on marketing mail. And the number that ends campaigns: keep the spam rate reported in Postmaster Tools below 0.30%, with Google recommending you stay under 0.10%. A list assembled from unverified pattern-guessed addresses will fail that test long before it fails your open-rate target.
So: check MX records exist for the domain, drop role addresses you do not intend to mail, drop anything you inferred rather than found published, and warm the sending domain slowly. Verification is not a step you add when deliverability drops; it is the step that stops it dropping.
What you owe the people on the list
This is the section most Maps-scraping guides omit, and it is the one that carries actual liability. Three obligations attach to a list you built rather than collected from the people on it.
If anyone on the list is in the EU or UK, you have a notification duty. GDPR Article 14 covers exactly this case — personal data not obtained from the data subject. You must tell the person who you are, what you are doing with their data, the legal basis, and, specifically, the source it came from, including whether that source was publicly accessible. The deadline is a reasonable period and at the latest one month, or — if you are going to contact them — at the latest at the first communication, whichever comes first. In practice that means the disclosure belongs in your first email, not on a privacy page nobody opens.
"It was public" is not a legal basis. The UK regulator is explicit that data protection law still applies to publicly available personal information, and that you must consider whether your marketing would be unexpected to the person. It also advises against tracing new contact details for someone whose old ones stopped working, on the grounds that it takes away their control.
The B2B email carve-out is narrower than people think. Under UK PECR, the electronic-mail consent rule does not apply to corporate subscribers — a limited company, an LLP, a Scottish partnership — so you may email them without prior consent. But sole traders and ordinary partnerships are treated as individual subscribers, and they need consent or the soft opt-in. A Google Maps list of local trades is full of exactly those. The ICO's own advice when you cannot tell which is which: treat them as individuals. In the US, CAN-SPAM does not require consent, but it does require a real postal address, a working opt-out honoured within 10 business days, and truthful headers — and it treats harvesting addresses as an aggravated violation, with penalties of up to $53,088 per email.
None of this makes the list unusable. It makes the phone number the safest field on it, and it makes the first line of your first email a disclosure rather than a pitch. For the wider picture, see is lead generation legal and is web scraping legal in the US.
What a 5,000-row list actually costs
Using QuanticData's published launch pricing, and assuming you tile a metro area into enough cells to reach five thousand unique places:
| Path | Unit | 5,000 rows |
|---|---|---|
| Maps listings only (name, phone, domain) | $0.001 / place | $5 |
| Domains crawled for contacts yourself | $0.0002 / page × ~5 pages | + $5 |
| Both stages via the lead collector | $0.01 / enriched lead | $50 |
Every account gets $2 of free API usage a month, which is enough to pull a couple of thousand listings and decide whether the segment is worth the rest. Failed requests are never billed, so a tile that returns nothing costs nothing — which is the property that makes aggressive tiling affordable in the first place.
The honest summary: the data is cheap, the pipeline is a weekend, and the expensive part is the part nobody writes a tutorial about — deciding who on the list you are actually allowed to contact, and on which channel.
Sources & further reading
- GDPR Article 14 — information to be provided where personal data have not been obtained from the data subject
- ICO — Business-to-business marketing (corporate vs individual subscribers under PECR)
- ICO — Collect information and generate leads (using publicly available personal information)
- FTC — CAN-SPAM Act: A Compliance Guide for Business
- Google — Email sender guidelines (authentication, one-click unsubscribe, spam-rate thresholds)
- Google Terms of Service — automated access and machine-readable instructions
- Google Maps Platform Service Specific Terms — caching and permitted use
- RFC 2142 — mailbox names for common services, roles and functions