Ask Nextdoor's category directory for 200 dentists in one city and you will get 200 rows. Roughly 72 of them will be in the city you asked for. This is not a bug in the request and it is not gradual — we counted where the switch happens, and it is a cliff.
The finding
Nextdoor's category directory is ordered by distance, not bounded by municipal limits. It serves every business in the requested city and then keeps going into neighbouring towns until it has filled the number of results asked for.
| Results | In San Clemente |
|---|---|
| 1–75 | 96–100% |
| 76–200 | 0% |
There is no blend zone. Up to result 75 essentially everything is local; from 76 onward essentially nothing is. San Clemente simply has about 72 dentists, and past that point the list is San Juan Capistrano, Dana Point, Ladera Ranch and Laguna Niguel.
How it was measured
One city, one category, 200 requested results, counted in blocks of 25 by address_city. A separate 120-business run on the same city and category came back 92% San Clemente with no filtering applied — consistent with a cut-off around 72, since the remaining 48 slots pull from the next towns over.
The transferable part of this measurement is the mechanism: distance ordering with an abrupt switch at the point the city is exhausted. The exact number, 72, is specific to San Clemente's dentists and tells you nothing about roofers in Ohio.
Why Nextdoor does this
Because for its actual users it is correct. A resident looking for a plumber does not care about the city line — they care about who will come out. A directory that stopped at the municipal boundary would be less useful to the person Nextdoor built it for.
It only becomes a problem when you treat the output as a municipal dataset. It is a trade area, which is arguably the more useful unit — as long as you know that is what you have.
The cost consequence
Every row is billed, including the ones from towns you did not ask for. A cap set to 500 in a town that holds 70 providers means you pay for 430 rows of regional overflow and then filter most of them out in your own pipeline — having paid for all of them.
This is the practical reason the caps matter more than they look. It is not primarily about controlling spend; it is about not buying data you are about to throw away.
The two controls
maxBusinessesPerCity near what a city plausibly holds. Set it in the region of the real provider count and you get that city with no filtering: the 120-run came back 92% local by itself.
onlyRequestedCity: true when you need it strict. Filtering happens during discovery, so two things follow: you are never charged for a business that gets dropped, and the Actor stops paging once the city is exhausted instead of continuing into the region to fill a quota it cannot fill locally.
When regional overflow is the feature
Often. Three cases where you should deliberately leave the cap high and onlyRequestedCity off:
- Service-area businesses. A roofer's market is a radius, not a boundary.
- Competitive analysis. Your competitors do not stop at the city line either.
- Finding the boundary itself. The point where in-city results stop is a measurement of how many providers that city actually holds — which is a number nobody publishes and the directory gives you for the price of one run.
