The Busiest Metro Areas on Google Maps: LA Leads on Paper, New York Wins in Reality

Every scraped business-listing dataset eventually gets the same request: "rank the busiest cities." It sounds like a five-minute query — group by city, sort by count, done. We tried exactly that on Crawlora's Google Maps business dataset, now past 132 million listings worldwide, and the answer it gave was wrong in an interesting, specific, and fixable way. Chicago's busiest "city" isn't Chicago. New York's isn't New York. And the borough that actually makes New York the busiest metro in the country doesn't show up as "New York" at all.

Why you can't just sort by city

Pull the dataset's global city facet with no filter and the top values already look off: "Springfield" (46,070 — could be Massachusetts, Illinois, Missouri, Ohio, or a dozen other states), "Portland" (41,193 — Oregon or Maine), "Richmond" (42,904 — Virginia or somewhere else entirely), plus entries that aren't cities at all: "Times Square" (56,135) and "Chinatown" (36,683) are neighborhoods, not municipalities. That's the obvious problem — common names collide across states and countries, and the city value assigned to each listing sometimes describes a neighborhood instead of the encompassing city.

Filtering to a single state removes the cross-state collision — but exposes a second, worse problem. Scope the city facet to New York state alone and the ranking doesn't put "New York" anywhere near the top:

Rank	"City" value	Listings
1	Times Square	56,135
2	Gramercy Park	15,591
3	(missing)	14,669
4	New York	14,352
5	Rochester	12,709
6	Financial District	12,509
7	Syracuse	12,013
8	Manhattan	11,553
9	Buffalo	11,454
10	Hell's Kitchen	10,318

Illinois shows the identical pattern: the top city value is "Chicago Loop" (19,455), not "Chicago" (7,688, ranked #5), with the rest of the city's own dense core split across "Near North Side," "Lincoln Park," "North Center," "West Town," "Logan Square," and "Uptown." This isn't Google's raw data leaking through, and it isn't a geocoding gap either — as the next section shows, it's a deliberate granularity choice in how each listing's city gets resolved: the nearest named locality wins, even when that locality is a neighborhood rather than the city it sits inside. There's no separate field carrying the encompassing municipality to fall back on. Rank cities by city directly and you'd rank the two biggest, most-searched-for cities in the table artificially low, and a scatter of their own neighborhoods artificially high.

The unit that actually works: county — but only scoped one state at a time

county doesn't have the neighborhood-granularity problem — nobody's business address gets auto-assigned to a "sub-county" locality. But it has its own version of the cross-state collision problem, and it's easy to miss because county names look more official than city names. Pull the nationwide county facet with no state filter and "Montgomery County" ranks #4 in the whole country at 246,633 listings — which is only possible because roughly 18 different US states have a county by that name, all summed into one bucket. "Jefferson County" (212,029), "Washington County" (164,419), "Franklin County" (154,383), "Lake County," "Monroe County," and "Madison County" all show the same artifact.

The fix is the same discipline that failed for city: filter by state first, every time. Doing that state by state across the 16 most populous states, here's the real top 20:

Rank	County	Metro	Listings
1	Los Angeles County, CA	Los Angeles	409,114
2	Cook County, IL	Chicago	287,344
3	Harris County, TX	Houston	238,167
4	Miami-Dade County, FL	Miami	171,154
5	Dallas County, TX	Dallas	160,940
6	Orange County, CA	LA metro	143,396
7	San Diego County, CA	San Diego	116,751
8	Broward County, FL	Fort Lauderdale	113,672
9	Bexar County, TX	San Antonio	109,604
10	Tarrant County, TX	Fort Worth	108,810
11	Middlesex County, MA	Boston metro	103,370
12	Allegheny County, PA	Pittsburgh	102,733
13	King County, WA	Seattle	100,490
14	Philadelphia County, PA	Philadelphia	96,220
15	Maricopa County, AZ	Phoenix	95,016
16	Palm Beach County, FL	West Palm Beach	94,744
17	Oakland County, MI	Detroit metro	93,189
18	Hillsborough County, FL	Tampa	91,289
19	Riverside County, CA	Inland Empire	86,924
20	Hennepin County, MN	Minneapolis	85,113

This ranking looks like what you'd expect: LA, Chicago, and Houston — America's three biggest cities by population — occupy the top three spots, in the right order. That's the tell that county-level, state-scoped counting is measuring something real.

The catch: New York's own structure breaks this ranking too

Every county in that top-20 table names a single, contiguous metro area — except it doesn't include New York City at all, and that's not because NYC has few Google Maps listings. It's because New York City is the one major US city that isn't a single county. It's five: Manhattan is New York County, Brooklyn is Kings County, Queens is Queens County, the Bronx is Bronx County, and Staten Island is Richmond County. Each one, counted alone, is too small to crack the top 10 — so the actual busiest city in the dataset is invisible in a flat county table for the exact same structural reason "Chicago" was invisible in the flat city table.

Summed, the picture flips:

New York City (5 boroughs summed)490,756NY + Kings + Queens + Bronx + Richmond counties

Los Angeles County409,114

Cook County (Chicago)287,344

Harris County (Houston)238,167

Miami-Dade County171,154

Borough	County name	Listings
Manhattan	New York County	177,021
Brooklyn	Kings County	119,631
Queens	Queens County	115,909
The Bronx	Bronx County	55,913
Staten Island	Richmond County	22,282

This is the real headline of this piece, more than the top-20 table itself: whichever ranking method you pick has to be checked for exactly this kind of administrative-boundary trap, because it will silently misrank the single biggest entry in the dataset. LA's #1 spot in the flat table isn't a data error — it's a correct count of a real, single-county city. It's just answering a narrower question ("biggest single county") than the one most readers actually want ("biggest city").

Not a US quirk: Tokyo does the exact same thing

We checked whether this is a US-specific artifact of the dataset's locality resolution, or something more structural in how dense metros resolve to a "nearest named place" anywhere. Japan is a clean test — its state facet is really the prefecture level, and it comes out clean:

Rank	Prefecture	Listings
1	Tokyo	787,551
2	Osaka	314,242
3	Aichi	291,873
4	Saitama	282,132
5	Kanagawa	256,797

But scope the same query down to city within Tokyo and the same fragmentation reappears, ward by ward: the top value is Ginza (11,302), then Hachiōji (10,792), Nakano (10,264) — "Tokyo" itself shows up ninth, at 8,276. Exactly the New York/Chicago pattern, on the other side of the world. The one partial exception we found is London: it still tops the UK's raw city facet cleanly (180,353, more than 4x #2 Birmingham), even though some real borough splintering exists underneath it ("City of London," "City of Westminster," "Soho," and "Holborn" are all separately bucketed). London's sheer size relative to the fragments is enough to keep it on top; New York, Chicago, and Tokyo aren't so lucky. The lesson generalizes, but not every city behaves identically — check before you assume.

Could reverse geocoding fix this?

Our first instinct was: the underlying records carry lat/lon, so why not reverse-geocode every listing to a proper administrative boundary and rebuild city cleanly? We tried exactly that, on the exact coordinate behind the "Times Square" value (40.758, -73.9855) — and reverse geocoding it through OpenStreetMap's Nominatim returns city: "New York", correctly, on the first try. That's the tell that this isn't a missing-geocoding problem: reverse geocoding this dataset's own coordinates already gives the right answer. The city value stored on the listing just isn't built that way — it resolves to the nearest named locality (a real, gazetteer-listed place, which for a business standing in the middle of Times Square or the Chicago Loop is exactly that neighborhood), not the encompassing city boundary. Both are legitimate, different answers to "what city is this in" — one is more useful for a mailing address, the other for a metro-level ranking like this one — and the dataset is built to give the first one.

So "reverse-geocode it" isn't really the fix, because reverse geocoding is already part of how these values get built. The actual choice on the table is narrower: keep resolving city to the nearest named locality (as now, useful for its own purposes), or add a second, civil-boundary-based field alongside it specifically for cases like metro-level rankings. That second option is a real, boundable project, not an afterthought:

• Running it across the full 132M+ records isn't the way to scope it. At OpenStreetMap Nominatim's public 1-request-per-second policy, reverse-geocoding every listing would take roughly 4.2 years run serially (132,237,427 requests ÷ 1/sec) — and distributing that load across many source IPs to get around the limit is explicitly against Nominatim's usage policy, not just slow. A self-hosted Nominatim instance or a paid geocoding provider's high-QPS tier removes that ceiling, but at commercial rates (roughly $5 per 1,000 lookups) a full 132M-record pass would run north of half a million dollars.
• It doesn't need to run across the full dataset. The listings that actually resolve to a sub-city locality are concentrated in a handful of dense, high-fragmentation metros — New York, Chicago, Tokyo, and probably a few dozen more like them worldwide — a few hundred thousand to low millions of records, not 132 million. That's cheap enough for a paid geocoder, or slow-but-free through the rate-limited public endpoint if nobody's in a hurry.

For this piece, we didn't need either path: the county-level, state-scoped method above sidesteps the granularity choice entirely for the US, and the state/prefecture level does the same internationally. Building a second, civil-boundary city field is a legitimate follow-up for anyone who specifically wants clean city-level (not county-level) rankings without giving up the existing field's locality-level precision — just not a quick pass, and not something we're claiming to have done here.

Busiest metros also have meaningfully better website coverage

One more thing came out of scoping these counties individually: website coverage tracks metro size. Pulling facet=website_status scoped to each of the top 4 counties:

New York County (Manhattan)64.4%

114,091 of 177,021 listings

Los Angeles County63.8%

260,858 of 409,114 listings

Harris County (Houston)63.0%

150,164 of 238,167 listings

Cook County (Chicago)62.4%

179,390 of 287,344 listings

Global average (132.2M listings)39.2%

51,868,204 of 132,237,427 listings

The four busiest US counties all sit 23–25 points above the global 39.2% average. That's directionally what you'd expect — denser, wealthier metros should have better digital presence — but it hadn't been quantified against this exact dataset before. It's also a clean example of why the ranking method matters beyond vanity: once you can reliably say "this is Cook County's real listing count," you can ask real follow-up questions about it, like coverage, category mix, or growth over time, without re-litigating whether the base count is even right.

How we did this, and the caveats

Every number above comes from a live facets call against Crawlora's Google Maps business dataset (132,237,427 listings, 2026-08-25/26 snapshot) — facet=city, facet=county, facet=state, and facet=website_status, filtered by country/state/county as described in each section. Nothing here is estimated or extrapolated.

Caveats worth stating plainly: the top-20 county table isn't exhaustive — it was built by state-scoping the 16 most populous US states by total listing count, not all 50, so a county in an unchecked state could theoretically place in the 15–20 range (unlikely, since state-level totals for the remaining states are all well below the states we did check, but not impossible for a single dense county within one). review_count is excluded throughout — it's flagged dataset-wide unsafe pending a re-crawl fix, so this is a listing-density ranking, not an engagement or popularity-in-the-foot-traffic-sense ranking. International coverage beyond the US/Japan/UK spot-checks is unverified — we don't yet know how many other countries show the New York/Chicago/Tokyo fragmentation pattern vs. the London exception. And this is a live-growing dataset — a re-pull months from now will show different, almost certainly higher, totals across the board.

If you want to run your own cuts on this data — by category, by rating, by any of the filters above — that's exactly what Crawlora's Google Maps business API is for. It's the same structured-data approach behind our PitchBook and anti-bot adoption studies, and the dataset behind our existing State of Local Business on the Web study.

Query the Google Maps business dataset directly

Crawlora's Google Maps dataset turns 132M+ business listings into structured, queryable JSON — filter and facet by category, country, state, county, city, rating, and website status. 2,000 free credits a month, no card.

Explore the Google Maps APISee pricing