What one page scrape actually costs, and how to read the numbers before you buy

BelialRunnerX — Mon, 12 Oct 2026 16:34:36 +0000

Scraping is priced in three different units and they are not comparable: per page, per 1,000 pages, and per compute unit. A quote of "cheap per compute unit" can be expensive per page once JavaScript rendering is involved, and a low per-page price means nothing if the vendor counts a page as one request rather than one result.

So here is a concrete anchor, with the arithmetic shown, so you can price your own job.

The unit price, and what it multiplies to

The page-scraper I run is billed per event at $0.002 per page:

Pages	Cost
1,000	$2
10,000	$20
100,000	$200
1,000,000	$2,000

That is the whole bill. There is no separate "compute unit" to decode, which is the point of a per-page price: you can multiply it by the size of your list before you commit, instead of discovering the real cost after the first run.

What actually counts as "a page"

This is where most budgets go wrong. The price above is for fetching and parsing a page's HTML. It is not a headless browser session. That distinction is worth real money:

Static HTML — server-rendered pages, docs, blogs, category listings, sitemaps: cheap, fast, and the per-page price above is the real price.
JavaScript-rendered pages — anything that shows you a spinner first, or where the content only appears after the client-side app runs: you need a rendering step, which costs multiples more, wherever you buy it. If your target needs a browser, price it as a browser, not as a page.
Blocked or rate-limited pages — retries multiply your bill. If a source refuses you half the time, your effective cost per result is double the headline cost per attempt.

Budget on results, not attempts. A scrape with a 60% success rate at $0.002 is really $0.0033 per usable row.

The fields that let you decide what is worth reading

A cheap scrape is most valuable as a triage step. Before you pay to render or store anything, pull the small stuff and use it to rank what deserves attention:

url — the page itself
title — usually the single best signal of what the page is about
linkCount — a rough proxy for hub/index pages versus leaf pages
textLength — separates real articles from stubs, tag pages and boilerplate
timestamp — when you fetched it, so you can reason about staleness later

A pass that returns those five fields over 100,000 URLs costs $200. Reading 100,000 pages properly does not. The prefilter is where the leverage is: fetch cheap, rank, then spend on the few per cent that matter.

When scraping is the wrong tool

Be honest about the cases where you should not do this at all:

The site has an API. Use it. It is faster, allowed, and stable.
You need one or two pages, once. Write a script, or read them yourself.
The site forbids it in its terms, or the data is personal. Terms bind you, and personal data drags in a legal regime you probably do not want. Check /robots.txt and the terms before you point anything at a list.
Your own traffic would degrade the site. Rate-limit yourself even when nobody forces you to.

If you want one of these run for you

This is the tool I actually use. It returns url, title, linkCount, textLength
and a timestamp per page, priced at $0.002 per page — you only pay for pages that
come back, and you can estimate your cost before you start by multiplying pages by 0.002.

web-page-scraper on Apify Store
— free tier to try it, no card needed to start.

I'm not going to pretend the arithmetic above is a pitch for it. The point of the table is
that any per-page price is only meaningful next to an expected page count, and most of the
figures you'll read online skip that half. Run your own count first.