The strongest public 2026 crawl benchmark located for this review is Firecrawl's own 1,000-URL dataset: 96% coverage, 0.638 extraction F1, 0.639 content recall, and 3,387 ms P95 latency.
Those numbers measure Firecrawl's scrape coverage and quality on a published dataset; they are not a universal crawl API success rate or a like-for-like result for every vendor.
No comparable first-party 2026 success-rate dataset was found for the other APIs reviewed here, so their rows are marked “not independently comparable” rather than filled with estimates.
A buyer should reproduce the test on target domains and score accepted fields, not only HTTP completion or returned Markdown.
Conclusion and benchmark data
The defensible conclusion is that Firecrawl has the clearest public benchmark evidence, while the market still lacks a single independently reproducible crawl-API leaderboard. Firecrawl reports a run on January 13, 2026 using 1,000 URLs from ten public-web categories. Its definition of coverage is whether the tool retrieved at least 10% of expected core page text, excluding navigation, ads, and footers.
Provider or system
Coverage / success metric
Quality metric
Latency
Evidence type
Firecrawl
96%
F1 0.638; recall 0.639
P95 3,387 ms
Vendor-run, dated public dataset
Other crawl APIs
Not independently comparable in this review
Not reported on the same dataset
Not reported on the same harness
No verified like-for-like result located
The Firecrawl benchmark page publishes the dataset name, date, metric definitions, and scope. Firecrawl also says its harness is not yet published end to end, so the input dataset is checkable but the complete run is not fully reproducible.
For the Nstdata option, review Nstdata Crawl and confirm the current API surface before running a comparison.
Methodology: what a useful crawl benchmark must control
A useful crawl API benchmark fixes the URL set, request options, timeout policy, output format, concurrency, retry budget, and acceptance rules before running any provider. Without those controls, a “success rate” can mean a completed HTTP request, any non-empty body, or a page that actually contains the required fields.
Use a stratified set of public, authorized URLs across documentation, ecommerce, news, finance, JavaScript-heavy pages, redirects, PDFs, and error cases. Freeze the URL list and record the test date. Run each provider with default settings first, then publish separately labeled tuned results.
Score at least four outcomes:
Transport success: the API returned a terminal success response within the time budget.
Content coverage: the result contains the expected core page text.
Extraction quality: required fields match a human-annotated reference.
Operational latency: report median and P95, not only an average.
The Firecrawl scrape-content dataset is a useful starting point for a reproducible input set, but a production buyer should add representative target pages. Also consult HTTP Semantics when defining acceptance and transport behavior.
Provider table: separate measured data from claims
The table below records only figures that can be tied to a named source and measurement scope.
Provider
What can be stated
What cannot be inferred
Firecrawl
96% coverage, F1 0.638, recall 0.639, P95 3,387 ms on its January 13, 2026 1,000-URL run
A guaranteed rate on your domains or a universal rank
Nstdata Crawl
Current product surface should be checked for API formats, rendering, discovery, and limits
A success rate without a logged, comparable run
Other crawl APIs
Include only a score with a published dataset, date, harness, and acceptance definition
Comparing vendor home-page claims as if they were one benchmark
Nstdata Crawl is a reasonable candidate for a buyer-run comparison when the workflow needs page scraping, bounded site discovery, JavaScript rendering, or structured and visual outputs. Review the Nstdata Crawl product and Nstdata documentation for the current API surface, then run the same URL set against every provider.
Aggregate success rate can hide the exact pages that matter to a business. Report results by domain, page type, rendering requirement, and failure reason.
Segment
Useful fields
Documentation
heading, code block, canonical URL, links
Ecommerce
product ID, title, price, availability, currency
News
title, published time, author, article body
Finance
instrument name, timestamp, value, unit
JavaScript-heavy
rendered heading, network wait, final URL
PDF or binary
download status, page count, extracted text
For each segment, publish attempts, terminal successes, accepted records, median latency, P95 latency, and the top failure classes. Do not turn a small sample into a precise ranking.
Analysis: why success rate alone is insufficient
Coverage is a gate, not the final business outcome. A tool can return enough text to pass a 10% threshold while missing the price, product ID, or table that makes the page useful. Conversely, a page can fail a text-coverage rule while still returning the exact structured field the application needs.
Cost per accepted record is usually more actionable than cost per request. Track retries, empty outputs, schema failures, manual review, and storage size. Also compare the operational work required to maintain browser actions, selectors, pagination, and site-specific exceptions.
Reproducible scoring code
This small scorer is intentionally offline: it compares a returned JSON record with a reference record and does not call any provider.
defscore_record(reference, candidate, required_fields): present =sum(bool(candidate.get(field))for field in required_fields) exact =sum(candidate.get(field)== reference.get(field)for field in required_fields)return{"coverage": present /len(required_fields),"exact_match": exact /len(required_fields),"accepted":all(candidate.get(field)for field in required_fields),}
Pair the scorer with a frozen manifest, provider request logs, response status, elapsed time, and redacted task IDs. The code is illustrative; no provider run is claimed in this article.
This review compares public evidence, not a newly executed multi-provider test. Firecrawl's reported metrics come from its own run and definition of coverage. The complete benchmark harness is not published, vendor defaults may differ, target pages change, and a 1,000-URL sample cannot represent every country, domain, content type, or protection layer. Treat the table as a starting point for procurement testing.
For an authorized trial, start with Nstdata and record the same metrics for the same URL manifest.
There is no universal threshold; define success as an accepted record for your target pages and report the dataset, denominator, failure classes, and latency alongside the percentage.
Q: Is Firecrawl's 96% a universal success rate?
No. It is Firecrawl's coverage result on a dated 1,000-URL benchmark with a specific 10% core-text definition.
Q: Why are other providers marked not comparable?
They were not assigned invented numbers when no same-dataset, same-harness, first-party result was verified in this review.
Q: Should I benchmark APIs on my own domains?
Yes. Use public or authorized URLs that represent your workload, freeze the manifest, and score the fields your application actually needs.
Q: Does a crawl API replace domain-specific validation?
No. A crawl API can retrieve and transform pages, but your application still needs schema checks, deduplication, freshness rules, and storage validation.
Marcus Chen
Sep. 9th 2026
110M+ real IPs with 99.9% access success
Blazing-fast average response ~0.5s for high-concurrency tasks
From only $0.1/GB
Get immediate access to premium residential, datacenter, IPv6 and ISP proxy pools.
