Web Scraping Service Pricing in 2026: What the Sticker Price Hides

What a web scraping service actually costs in 2026

Short answer: anywhere from $0.06 to $16 per 1,000 pages. That 250x spread is not marketing noise. It is the real distance between pulling plain HTML off a cooperative site and driving a headless browser through an anti-bot wall on a site that does not want you there.

Four buying models dominate the market, and each one is priced in a different unit. That is the main reason quotes are impossible to compare side by side.

Before comparing any two numbers, check the unit. Per request, per credit, per record, per GB and per month are five different things, and the provider that looks cheapest in one unit is frequently the expensive one in yours.

The five web scraping pricing models, and what each one hides

Every provider picks a billing unit that flatters its own infrastructure. Knowing which unit you are being sold tells you where the surprise will come from.

The bandwidth model is the one most people misjudge. A product page that returns 40 KB of useful HTML often transfers 2–3 MB once hero images, web fonts and analytics load. If you are billed per GB and you have not disabled resource loading in your fetcher, you are paying fifty times over for bytes you throw away.

Why one page costs $0.13 per 1,000 and another costs $16

Two public pricing pages explain nearly the whole spread. The first prices difficulty directly. Zyte’s published API pricing sorts every website into five tiers and charges per 1,000 successful responses, with a separate, much higher rate once a headless browser is involved:

Read the two columns against each other: rendering is a 7–13x multiplier at every single tier. Committing $500 a month brings the same tiers down to $0.06–$0.61 for HTTP and $0.48–$7.68 rendered, so volume discounts are real — but they never close the gap between HTTP and browser. Nothing you negotiate will beat simply not needing the browser.

The same logic, disguised as credits

Credit-based plans hide the identical difficulty curve inside a multiplier table. On ScraperAPI’s plan and credit documentation, a standard page costs 1 credit, Amazon costs 5, Google and Bing cost 25, LinkedIn costs 30, and sites behind Cloudflare, DataDome or PerimeterX add 10 credits per request. Converted into money on the $149 plan, which carries 1,000,000 credits:

A $49 headline price and a 30x multiplier are the same sentence written twice. When a vendor advertises a per-month figure, the only number that matters is plan price divided by the credits your targets will actually consume.

How to estimate your real monthly scraping bill

Two lines of arithmetic, done before you talk to anyone:

monthly billable units
    = sources x pages per source x refreshes per month
    x credits (or difficulty multiplier) per request
    / success rate          # only if failed attempts are billed

monthly cost = billable units / 1000 x rate per 1,000

Worked example. You monitor 20,000 SKUs on one mid-difficulty retail site and refresh daily, so 600,000 page fetches a month.

• Browser-rendered, tier 3, pay as you go: 600 x $4.02 = $2,412/month.
• Same work on a $500 monthly commitment: $2.40 per 1,000 = $1,440/month.
• Same data pulled from the site’s own JSON endpoint, no browser: tier 3 HTTP at $0.44 per 1,000 = $264/month.

Finding the underlying API is worth more than any discount you will ever negotiate — roughly nine times the saving of the volume commitment in this example. Open DevTools, filter the network tab to Fetch/XHR, reload the page, and check whether the content hydrates from a JSON call. On modern storefronts it usually does, and it frequently returns more fields than the rendered HTML shows.

The same job on a credit plan

600,000 standard pages is 600,000 credits, which sits comfortably inside a 3,000,000-credit plan at $299. Now the target turns on Cloudflare. Each request becomes 11 credits, the job becomes 6,600,000 credits, and both the 3M and the 5M plans are too small — you are on the 10.5M plan at $975. One configuration change on someone else’s server tripled your bill, and nothing in your code changed.

This is why any scraping budget needs a volatility allowance. Price the plan you need today, then confirm what the next tier up costs, because you will eventually land on it without warning.

The costs that never appear on the pricing page

• Expiring credits. Credit balances typically reset at renewal and do not roll over. If you buy 100,000 credits for $49 and burn 40,000, your effective rate is $1.23 per 1,000, not $0.49. Under-use is as expensive as over-use.
• Concurrency as a throughput ceiling. A one-million-page backfill at 20 concurrent threads and five seconds per request takes about 69 hours — nearly three days of wall clock before you parse anything. Concurrency is sold as a feature; it behaves as a deadline.
• Geotargeting tiers. Entry plans often restrict which countries you can appear from; ScraperAPI’s two cheapest plans cover the US and EU only, with country-level targeting from the $299 plan up. If your prices or inventory differ by market — travel, marketplaces, Gulf or APAC catalogs — that is a plan upgrade, not a request parameter.
• Billing on failures. Ask explicitly whether you pay per attempt or per success. Zyte publishes its rates per 1,000 successful responses; credit systems vary. At an 80% success rate the difference is a quarter of your bill.
• Maintenance, measured in developer-days. Markup changes, selectors break, pagination gets reworked. Budget this in your team’s actual day rate, not in dollars of API spend — two maintenance days a month is routinely more expensive than the entire subscription.
• Storage, egress and reprocessing. Raw HTML archives are cheap until they are terabytes, and every parser bug means reprocessing them.
• Compliance review. The moment a dataset contains personal data, the cost moves from infrastructure to legal review. Scope that before the first request, not after.

Build in-house, buy an API, or hire a team?

The honest version of this decision is not about price per 1,000. It is about where your engineering attention is best spent.

The rule of thumb that holds up in practice: if the data is strategic and the targets are hard, pay for infrastructure and keep the logic in-house. If the data is operational and the targets are standard, buy the API. If you need both and have no one to own it, a commissioned custom data crawling and processing build is usually cheaper over twelve months than one engineer learning anti-bot evasion on company time — the in-house option is almost never as cheap as the spreadsheet says, because the spreadsheet never includes the week the scraper was down.

What to ask for before you accept any scraping quote

Vendor and agency quotes become comparable once you force them onto the same terms. Ask for all nine in writing:

1. Price per 1,000 successful responses for my specific domains, not the headline rate.
2. The credit or difficulty tier of each target URL, measured, not estimated.
3. Whether failed and retried attempts are billed.
4. Whether unused volume rolls over, and what overage costs.
5. The concurrency ceiling, and the throughput it implies for my largest backfill.
6. Geographic coverage at my price tier.
7. Turnaround time after a target site changes layout, stated in hours or days.
8. Delivery format and what happens when the output schema changes.
9. For a commissioned build: who owns the source code when the engagement ends.

Item 9 is the one most buyers forget, and the only one that is expensive to renegotiate later.

If you have the page list and the refresh cadence but not the engineering time to price it properly, send the targets over and get a scoped quote for your scraping project — the useful output of that conversation is the per-source difficulty and the real monthly number, whether or not you end up outsourcing the build.