Why Google Maps only ever shows you ~120 results

This is the single most common support question for every Google Maps extraction tool ever built, and the answer is the same for all of them. Understanding it properly changes how you prospect, because the workaround is straightforward once you stop fighting it.

What you are actually seeing

Google Maps loads search results into a scrolling list, roughly twenty at a time. Scroll to the bottom, twenty more load. Keep going and eventually you reach "You've reached the end of the list."

That end arrives at somewhere around 120 results. Not exactly 120 — it varies — but that is the region. It arrives whether there are 130 matching businesses or 8,000.

Critically, this happens in the Maps interface itself. Open Maps in a clean browser, scroll manually, and you will hit the same wall with no extension installed. Any tool reading that list is bounded by what the list contains.

Why Google does this

Google has never published the reason, so this is informed inference rather than documented fact. Three explanations are consistent with the behaviour:

• Nobody scrolls that far. Maps is built for people finding a coffee shop, not for building lists. Real users almost never pass result thirty. Serving unlimited results would cost real infrastructure for a use case that barely exists.
• Relevance stops meaning anything. Maps ranks by a blend of distance, prominence and relevance. By result 120 the ranking signal is exhausted and the ordering is close to arbitrary. Returning 8,000 rows in no meaningful order would make the product worse.
• It limits bulk extraction. A cap makes the dataset far more tedious to harvest wholesale. Google sells this data through the Places API, so there is a commercial logic to not giving it away by the 10,000.

Why the same search returns different counts

This is the second question, and it usually arrives as "it gave me 76 results this morning and 14 just now, is it broken?"

It is generally not. Three things move the number:

1. Throttling. If you have been running searches steadily, Maps begins returning thinner result sets before it ever shows you a CAPTCHA. Quietly fewer results is the first sign you are going too fast, not an error.
2. Map viewport. Maps results are bounded by the visible map area. Zoomed out over a whole region returns a different set from zoomed into one district — often fewer when zoomed out, because relevance is spread thinner.
3. Personalisation and location. Your own location, language and account history all shift the ordering, and therefore what falls inside the cap.

If the count looks unexpectedly low, wait a few minutes and try again before concluding anything. If it stays low, you are probably throttled.

The workaround: subdivide, then merge

Since the cap is per search, the fix is more searches, each narrow enough that the true result count sits under the ceiling. Three axes to subdivide on:

By geography

The most reliable. Instead of "restaurants in Manchester", run "restaurants in Chorlton", "restaurants in Didsbury", "restaurants in Ancoats". In the UK, postcode districts are ideal — M1, M2, M3 — because they are small, exhaustive and never overlap. US equivalents are ZIP codes; elsewhere, use suburb or neighbourhood names.

By sub-category

"Restaurants" is one search. "Italian restaurant", "Indian restaurant", "Thai restaurant", "pizza restaurant" are four, each returning a different set, each with its own ceiling. Google's own category taxonomy is a good source of terms — the category shown on any listing is one Google recognises.

By map viewport

The advanced version. Zoom the map to a tight area before searching, and Maps restricts results to that box. Systematically panning a grid across a city gives full coverage — this is what large-scale operations do, and it is the most laborious option by a distance.

Making the merge work

Subdividing means the same business will appear in several runs — postcode boundaries do not respect map viewports, and a business can match several category terms. Without proper de-duplication you end up with a list that is 30% duplicates.

Name matching is not good enough. There are four businesses called "The Crown" in most British cities, and one business's name can render differently across searches.

The right key is Google's own identifier. Every Maps listing has a stable numeric CID, encoded in the listing URL. It does not change when a business renames, moves or updates its details. De-duplicating on CID is exact — two rows with the same CID are the same business, full stop.

If your tool de-duplicates on business name, it is guessing. If it de-duplicates on Google's listing id, it is correct.

A worked example

Covering plumbers across Greater Manchester, properly:

1. List the postcode districts you care about — say M1 through M46, plus the relevant OL, BL and SK districts.
2. For each, search "plumber in M20" and so on. Roughly sixty searches.
3. Add sub-category passes for the dense districts: "emergency plumber", "boiler repair", "drainage".
4. Let the tool merge everything and de-duplicate on CID as you go.
5. Pace yourself. Sixty searches back to back will get you throttled; spread across a couple of sessions, they will not.

The result is a few thousand genuinely distinct businesses rather than the 120 a single search would have given — and, filtered, a working list rather than a spreadsheet.

---

How the extractor handles this

Maps Business Extractor de-duplicates on CID automatically, so you can run search after search and let results accumulate without building a duplicate mess. Results persist between runs until you clear them deliberately, which is what makes the subdivide-and-merge method practical rather than tedious.

It also stops rather than pushing through when Google shows a verification prompt, which is the behaviour that keeps you off the throttling ladder in the first place — more on that here.