Search “dentist” in a city of two million people and Google Maps will show you about 120 businesses. Scroll to the bottom and the list simply ends. There is no page two.
This is the single most common reason a Google Maps extraction job produces a disappointing list, and almost every article about it gets the explanation wrong. It is not a bug, it is not an anti-scraping measure aimed at you specifically, and no browser extension is going to talk Google out of it.
The ceiling belongs to the query, not to Maps
Google Maps paginates search results in batches of twenty. It will serve you roughly six of those batches and then stop. The exact cutoff drifts a little by region and category, which is why you will see the number quoted as 120, 100, or “about 6 pages” depending on who is writing.
The important detail is what the limit applies to. It is a per-query ceiling. Google is not saying “there are 120 dentists in Manchester”. It is saying “for this one query, in this one viewport, here are the 120 results I ranked highest”.
Change the query and you get a different 120.
That distinction is the whole game. If the ceiling applied to the city, extraction past it would be impossible. Because it applies to the query, the ceiling is an inconvenience rather than a wall.
Why Google does this
Two reasons, neither of them about scraping.
The first is relevance. Maps is a consumer product, and no human scrolling for a dentist wants result 340. Ranking quality collapses well before then, so serving deeper results costs Google money and helps nobody.
The second is cost. Every additional page of results is more index work per query. Capping depth bounds that cost across billions of searches. This is ordinary product engineering, and essentially every search interface does some version of it.
The side effect is that anyone who needs coverage rather than relevance is using the product against its grain.
The grid method
If one query returns at most 120 results, run more queries.
Instead of searching “dentist, Manchester” once, divide Manchester into a grid of smaller geographic cells and search each cell separately. A query bounded to two square kilometres returns the businesses in those two square kilometres. If there are thirty, you get thirty. The 120 ceiling never comes into play because you never approach it.
Total coverage then scales with the number of cells rather than being fixed:
- One query over the whole metro: about 120 results.
- Thirty-six cells at 120 each: a ceiling of about 4,320, and in practice you get the true count because no individual cell is dense enough to hit its own limit.
The method is not clever. It is just arithmetic applied to a constraint that most people assume is immovable.
What makes it fiddly in practice
Three things, and they are why the naive version disappoints people who try it by hand.
Cells overlap. Google returns results near a cell boundary for both adjacent cells. Run a nine-cell grid without de-duplication and your row count is inflated by fifteen to thirty percent with the same businesses repeated. You need to key on a stable identifier, not the business name, because names have inconsistent punctuation and suffixes across listings.
Density is uneven. A uniform grid wastes queries on farmland and still saturates the city centre. Downtown cells can genuinely hit 120 and silently truncate, which is the failure mode that hurts most, because nothing tells you it happened. The fix is subdivision: when a cell returns a count at or near the ceiling, split it into four and re-run those.
Long jobs fail. A thorough metro sweep is thousands of queries and can run for hours. Anything that does not checkpoint its progress will eventually lose a long run to a dropped connection or a sleeping laptop, and you start over.
Doing it by hand
You can, and it is worth doing once to understand the shape of the problem.
- Open Google Maps and search your category in the target city.
- Zoom into one quadrant until the viewport covers a few square kilometres.
- Re-run the search. Maps re-queries against the visible area.
- Copy the results out.
- Pan to the adjacent quadrant and repeat.
- De-duplicate the combined list afterwards in a spreadsheet.
For a small area this is perfectly reasonable, maybe twenty minutes. For a metro it is thousands of pans and copies, which is the point at which people go looking for software.
What extraction tools actually automate
When a tool advertises that it “bypasses the 120 limit”, the grid method is what it means. There is no secret endpoint. The differences between tools are in the engineering around it:
- Whether the grid adapts to density or stays uniform.
- Whether de-duplication uses a stable place identifier or fuzzy name matching.
- Whether a long job checkpoints and resumes.
- Whether request pacing looks like a person or like a script.
That last one matters more than it sounds. Grid extraction means many queries in sequence. Fired off as fast as the network allows, that pattern gets throttled quickly. Paced like a human browsing, it does not.
What the method cannot do
Grid extraction solves coverage. It solves nothing else, and it is worth being clear about the rest:
- It does not create data Google does not have. A business with no phone number published has no phone number to extract.
- It does not verify anything. Google Maps carries closed businesses and stale numbers, and a grid sweep collects those just as faithfully as the live ones.
- It does not find emails. Maps listings rarely include an email. Tools that produce them are visiting the linked website and looking for a published address, which works maybe a third of the time.
- It does not make outreach legal. Public availability and permission to contact are different questions, governed by GDPR, CAN-SPAM, and local telemarketing rules.
The practical takeaway
If a Google Maps search is returning about 120 rows, you are not looking at the size of the market. You are looking at the depth of one query. The number of businesses that actually exist in that area is frequently five to twenty times larger, and the gap is entirely recoverable with a grid, either by hand for small areas or with software for large ones.
Anyone selling you a list built from single un-gridded searches is selling you the top of the results, which is also the part every one of their other customers already has.
Lead Finder implements the grid method as a desktop application, with adaptive subdivision, place-ID de-duplication and resumable campaigns. See how it works or compare the delivery models before deciding what fits your volume.