A 200-result ceiling splits Dubai into 1,760 tile-and-category crawl jobs

A loop that reads `data.local_results.length` throws a TypeError on page 11 ^[2]. One that reads `data.local_results?.length ?? 0` gets a zero and exits cleanly, for the wrong reason. The toolkit ships that response as a committed test fixture, so the next person does not spend a credit rediscovering it ^[3]. `FULL_PAGE` in the crawl loop is 20 ^[13], so roughly 200 results is about ten pages, and page 11 is the first request that buys nothing ^[1].

The ceiling number itself is soft. The write-up gives "roughly 200" from its own crawling and does not cite a documented limit ^[1]. For contrast it names the Places API Text Search ceiling: 20 results across three pages, 60 in all ^[8]. The Maps engine goes about three times deeper before it stops ^[2].

SearchApi's fit for this job is its location parameter. It takes Google's own format straight through as `ll=@lat,lng,zoom`, so no geocoding service sits between the tile grid and the query ^[19]. One request costs one credit. The cost model is a 3x3 lookup table ^[20]. Roughly 99.8% of results come back with `country_code` and `city`. That pair drives the in-city filter without a geocoder ^[10]. The write-up is published as part of SearchApi's developer ambassador programme, which the author says backs developers who ship something real on the APIs and leaves the work in their name ^[18].

Tiles overlap in what they return. Google answers from a radius, and about half the businesses landed in a tile other than the one whose query found them, so the pipeline reassigns each business by its own `gps_coordinates` ^[9], which arrive on every result ^[11]. `place_id` arrives on 100% of results and stays stable, and it is the dedup key, the database partition key, and the only value the takedown suppression list may hold ^[12]. Duplicate hits across neighbouring tiles collapse on that key. Each one still cost a credit to fetch.

Four guards sit outside the crawl loop: a mandatory `--yes`, a free dry run, a hard budget stop, and the plan-time drops ^[14]. The fifth is inside it. `shouldFetchNextPage` buys another page only when the last one came back with a full 20 results and at least 30% of them were new ^[13]. The retry predicate is one expression, true for 429 and for anything 500 or above ^[15]. The comment above it says rate limits and server errors are worth retrying, while a 400 or a 401 will fail identically forever and retrying only burns time and credits ^[16].

The Dubai run suggests the new-results check rarely stopped a fetch. No page returns more than 20 results, so 1,400 requests could have produced at most 28,000; the crawl kept 15,246 unique businesses, which puts the corpus-wide new-unique rate at about 54% against a 0.3 floor ^[3]. For 10.9 businesses per credit ^[7] to hold in another city, the density inside a similar grid has to be comparable and most of the category list has to return results. The planner already threw out 510 of the 1,760 pairs before any credit was spent ^[5]. As the write-up puts it, "Crawling law firms in the desert spends money to find nothing." ^[17]