Every scraped marketplace has a ceiling. What makes Workana's worth writing about is that the site cannot tell you where it is either — its own result counter caps before the interesting queries do.
The ceiling
Workana serves 7 projects per page and stops at page 50. That is about 350 projects per query, and it applies to every tool equally — there is no technique that reaches page 51.
Note that this is site behaviour, not a robots.txt rule. Workana's robots.txt says nothing about depth — unlike coches.net, which disallows pg=7, or Zonaprop, which allows only pages 2 to 5. Observed and declared are different kinds of limit and this site keeps them apart.
The counter that also caps
Workana displays how many projects match a query, and that number caps at 10,000. So for a broad query the site itself is reporting a ceiling rather than a count — which is how the `language` parameter produces its misleading 2,826 → 10,000 jump.
Why there is no coverage percentage
The obvious thing for a scraper to report is “we retrieved 350 of 2,826 projects, 12% coverage”. The Actor does not, and the reason is that the denominator is not a number anybody has.
Splitting by country, and why that axis
If depth is capped, coverage comes from partitioning — and the partition axis has to be one where the pieces barely overlap. Country measured almost perfectly additive:
| Measurement | Result |
|---|---|
| Overlap between country queries | 4% |
| Unique projects across 6 countries | 6.8x |
Six countries produced 6.8 times more unique projects than a single query, with only 4% appearing in more than one. That is close to the theoretical maximum for a six-way split, which is why country is the axis rather than category — a project belongs to one category but surfaces in several related category queries.
The coverage report
includeCoverageReport is on by default and writes one entry per query under COVERAGE in the key-value store:
{
"query": "subcategory=web-development&country=AR",
"declared_by_workana": 1284,
"delivered": 350,
"page_50_ceiling_hit": true,
"out_of_reach": "unknown — declared count may itself be capped"
}The last field is the honest one. “Unknown” is a worse-looking output than a percentage and a better one, because it is what the situation actually is.
Planning a sweep that knows its own limits
- Partition before you run. One query per country, per subcategory if needed.
- Check `page_50_ceiling_hit`. If true, that partition was truncated and needs splitting further.
- Deduplicate on `slug` across partitions, because of the 4% overlap.
- Report delivered counts, never percentages, and say which partitions hit the ceiling. That sentence is what makes the dataset defensible.
