Scraping Google Maps for Leads: What Breaks at Scale

Everything written about scraping Google Maps for leads is written by someone selling a scraper, and it all names the same failure: you will get blocked. That is true and it is the least interesting thing that goes wrong, because a blocked request announces itself.

The failures that cost you are silent. A run finishes, the row count looks plausible, and the data is wrong in ways you will not notice for weeks. Here are the three that matter at scale, in the order you will hit them.

A single Maps search returns roughly 120 results and then stops, no matter how many businesses match. Search restaurants in a city of three million and you get 120 of them.

So you tile. The city gets cut into neighbourhoods or a grid, and each cell is searched separately. This works, and it is what any serious index does — but understand what it costs you, because it is the decision everything else follows from:

The third one is the trap. A uniform grid feels rigorous and quietly under-samples exactly the areas with the most businesses in them — which are the areas you most wanted.

This is the one that has cost us the most, and we have never seen it mentioned anywhere.

The category label shown on a Maps listing and the category taxonomy an API returns are not the same vocabulary. A listing that reads "Sweet Shop" or "Cake Shop" to a human does not necessarily arrive as anything your pipeline recognises, and if your ingest keys on a fixed list of category names, everything unmapped is dropped on the floor.

It fails silently. The run completes, the rows are real, and a large share of what you paid to fetch never lands. The only way to catch it is to count what you discarded — log every unrecognised label, and read that log. Ours turns into a mapping table that gets extended every time a scan runs into something new.

This is the point where scraping and the official API stop being interchangeable, and it is specific to this use case.

If you only want names and addresses, discovery is cheap on any path. But the entire premise here is the website field — you are looking for businesses that do not have one. On Google's official Places API, asking for `websiteUri` alongside rating and review count moves the request onto the Enterprise field tier: $0.035 a call, about ₹3.08.

That single field is what sets the cost floor of the whole operation. And because Places bills per call rather than per result, cost tracks the *shape* of the query rather than its yield — a narrow neighbourhood query is around six calls, a broad city-wide filtered one around forty, and both can return roughly twenty usable businesses. Same output, seven times the cost.

At ₹3.08 a billed call. The lesson is not that one is wrong — it is that yield per call, not leads per hour, is the number to optimise.

Anyone quoting you a flat cost per lead for this data either has a different cost structure or has not measured theirs.

A scrape is a photograph, and the thing you photographed is the one field most likely to change. Businesses add websites. Sites die and the listing keeps the dead URL. Listings get claimed and edited. A business closes and stays on the map for months.

If your list is three months old, some meaningful share of it is now wrong in the direction that embarrasses you — you will tell someone they have no website while looking at the one they launched in March.

Which makes re-checking, not discovery, the ongoing cost of running an index. When a later check reveals a site we did not know about, we correct the record rather than leaving it, specifically so the published gap figures do not drift upward over time. Every number on this site is 285,554 businesses read that way.

Scraping Google Maps is against Google's terms of service. That is not a technical constraint and no amount of engineering resolves it — it is a business risk you are choosing to carry, and it is worth knowing you are choosing it rather than discovering it later.

The official Places API is the licensed path for exactly this data, which is why our own index is built on it and why the cost figures above are real numbers off our own bill rather than estimates. It is more expensive per call than a scraper and it is the reason we can publish the methodology at all.

None of which is an argument that you should never scrape anything. It is an argument for knowing which of the two you are doing, and for not being surprised by the bill or the terms.