The Google Maps 500-Result Limit, and How We Mapped Italy Anyway

Google Maps hard-caps every search at roughly 500 results. No matter how many matching businesses actually sit inside that radius, the API stops handing results back at the ceiling, silently, with nothing in the response flagging the cut. Build a national database without designing around the Google Maps 500-result limit and you lose most of the country without knowing it.

We ran into this building for a hospitality data company that needed every hotel-type business in Italy in one database, not a sample: the product depended on completeness. A single search per city gets nowhere close: Rome and Milan alone have more hotels, hostels, and B&Bs than the cap allows. We've built database infrastructure under this kind of constraint across a few verticals now, more of it is in case studies.

Working Around the Google Maps 500-Result Limit

The fix is a six-stage pipeline: tile, subdivide on cap, dedup, enrich separately, validate the total, merge outside sources. Each stage exists because the one before it can fail quietly. The cap itself is bounded and known; what's dangerous is not knowing exactly where you hit it.

Tiling the Country and Catching the Cap

We started from 6,667 seed cells, each roughly 1km wide, tiling Italy's populated areas rather than its raw landmass. Cross each cell with the initial 12-keyword search set and you get one row in a resumable queue. Every row is an independent, checkpointed unit: a crash mid-run costs exactly one cell's worth of work, never the whole run.

Cap detection runs on every completed cell: if a cell comes back at or near 500 results, it's almost certainly hiding more, so it splits into 4 smaller cells and each of those gets searched again. This repeats recursively until a cell returns comfortably under the cap. Across the full run, 32,206 cells hit the cap and got subdivided, concentrated exactly where you'd expect: Rome, Milan, and the other dense cities.

Overlap between neighboring cells is intentional, not a flaw to fix. The same hotel can turn up in two or three adjacent cells' results, and that's fine: the next stage exists specifically to collapse it back down.

Dedup First, Enrich Second

Every result carries Google's own place_id, so dedup is a straightforward collapse on that field. Across the full run, that collapsed about 32.6 million raw result rows into roughly 825,000+ unique places, using 171,033 searches across 19 keywords in total.

Enrichment (email finding, decision-maker matching, verification) runs strictly after extraction and dedup are complete, never bundled into the same job.

Validating Against a Predicted Universe

Trusting the scrape's own total is how bad coverage hides. We validated the final count against an independently predicted universe, expected business counts per province, built without reference to what the scrape itself returned. Provinces where the actual count came in far under prediction flagged which cells needed a second look.

Why Maps Alone Was Never Going to Be Complete

Google Maps under-covers some sub-verticals badly enough that Maps data alone isn't a national database, it's a partial one. Cross-checking against a booking platform's own listings put a number on the gap: about 60% of that platform's listings matched to something on Maps overall, and 85% for hotels specifically. Vacation rentals were the weak spot: about 35% of vacation rentals in dense areas had no Google Maps presence at all.

So the pipeline pulls in more than Maps: a booking platform, a review platform, regional government registries, and niche local sites. One review platform alone contributed 32,779 listings and 24,209 direct property email addresses on its own, contact volume that either becomes a list worth mailing or a pile of bounces depending on how it's handled afterward, which is the entire subject of what a million cold emails taught us.

What This Doesn't Solve

Maps data is only as fresh as Google's own index. A business that closed last month but hasn't been flagged yet still shows up as open, phone number and hours intact, with nothing hinting it's gone. The vacation-rental side showed the same gap from the other direction: properties matched cleanly to the booking and review-platform exports, complete with a working direct email and an active listing, while carrying no Google Maps presence at all.

The grid approach isn't free either: it's paid per search, and subdividing every capped cell multiplies that cost fast. It only makes sense when the job genuinely needs the whole universe, not a representative sample. Sampling a country is cheap; mapping one completely is not.

The Takeaway

If you're building a lead database that needs to be genuinely complete rather than "big enough," the 500-result cap isn't the hard part, detecting exactly where you hit it is. Tile smaller than you think you need to, subdivide anything that caps, dedup on the source's own ID rather than a fuzzy match, and never trust a single source's own total as proof of coverage. That discipline is the same one behind building a lead list that actually converts: coverage you can verify beats coverage you assume.