Search Zonaprop for apartments for sale in Buenos Aires and the page will tell you it found tens of thousands. Page through the results and you will run out at a few hundred. That gap is where most property datasets quietly go wrong, because the number on the page looks like an inventory and behaves like a headline.
The gap between the count and the download
One Zonaprop search can hold on the order of 74,000 properties and still only page through about 270 of them. The match count is a count of matches; it is not a promise that the portal will serve them.
This is not specific to Zonaprop — coches.net stops around page 300 and Workana stops at page 50. Deep result lists are expensive to serve and nearly useless to human visitors, so portals cap them. What varies is whether a scraper tells you about the cap.
The compliant cap, stated by the site
Before the portal's own ceiling is even reached, robots.txt sets a lower one. Zonaprop allows pagina-2 through pagina-5 and disallows every deeper page, so at 30 listings per page a compliant crawler gets 150 listings per search URL.
| Limit | Listings | Set by |
|---|---|---|
| robots.txt pagination | 150 | The site, in a machine-readable file |
| Result-list depth | ~270 | The site's own behaviour, undocumented |
The lower one is the one that applies, and it is the one this Actor respects. There is no version of “more pages” that is both compliant and effective.
Why portals do this
Because page 40 of a search result is a cost with no user. Nobody looking for an apartment goes there; the only clients that do are crawlers, and each one costs a database query. Add that ranked results are commercially valuable — promoted listings sit at the top — and there is no incentive to make the tail cheap to enumerate.
Splitting by location, which is the only way through
If depth is capped, coverage has to come from breadth. The Actor splits a large search into smaller ones by location, and each of those gets its own compliant 150.
You can do this by hand too, and for a serious dataset you should think in these terms regardless: one search per neighbourhood per operation per property type. Capital Federal has 48 barrios; that is 48 searches at 150 each rather than one search at 150.
# One run per neighbourhood, same operation and property type
palermo → 150
recoleta → 150
belgrano → 150
caballito → 150
…
# 48 barrios × 150 = 7,200 listings, all compliantThe bias in a truncated search
This is the part that matters more than the row count. The 150 or 270 rows you get are not a random sample — they are whatever the portal ranked first, which correlates with paid promotion and recency.
So a median price computed from one broad truncated search is the median of the promoted and the new, not of the market. Splitting by location does not just add rows; it removes that bias, because each narrow search is close to exhaustive for its area.
Planning a run that is actually complete
- Decide the unit of analysis first. If it is a neighbourhood, one search per neighbourhood is the design.
- Check whether you hit the cap. A search that returned exactly 150 probably had more, and needs splitting further — by price band or property type.
- Never report a percentage of the market. The denominator is a match count the portal caps, so a percentage of it is a percentage of a headline.
- Repeat on a schedule and keep every snapshot. Disappearance from the listing set is the closest proxy you have for a sale.
