Quick answer: Every serious scraping API has a free tier or trial, so trying before buying costs nothing but an afternoon. The mistake is testing with example.com and a couple of news sites. Instead, assemble 50-100 URLs from your actual workload, run them through each candidate, and measure four things: success rate, output quality, latency, and cost per successful page. That's a real evaluation; everything else is vibes.
I've watched teams pick a scraping provider off a pricing page, integrate for two weeks, and then discover it fails on the exact sites they care about. The fix is embarrassingly simple: test on your sites first, for free.
Free tiers are the industry norm
Good news first: you almost never need to pay to evaluate. The pattern across the industry looks like this, described qualitatively because exact numbers change and I refuse to put stale competitor prices in writing:
- Recurring free tiers: a monthly allowance of requests or credits that resets, no card required. This is the most evaluation-friendly model because you can re-test later.
- One-time trial credits: a bigger burst of credits that expire after a week or two. Fine for a focused eval, useless for ongoing spot checks.
- Card-required trials: technically free, practically a dark-pattern filter. Not disqualifying, but read the auto-conversion terms.
link.sc is in the first bucket: 500 credits every month, free, no card. That's enough to run the full evaluation in this post and keep spot-checking monthly afterward.
Step 1: Build a test set from YOUR workload
This is the whole game. A scraping API's performance varies enormously by target site, so an eval on someone else's URLs measures nothing.
Pull 50-100 URLs that represent production:
- Weight them realistically. If 40% of your volume is one domain, 40% of your test set should be too.
- Include your known-hard cases. The Cloudflare-fronted site, the JS-heavy SPA, the one that 429s everyone. These decide the outcome.
- Include some junk. Real pipelines hit dead links and redirects. How an API reports failure matters as much as how it succeeds.
One warning shaped by experience: keep the set to sites you have a legitimate basis to fetch. If you're unsure where the lines are, read is web scraping legal before, not after.
Step 2: Decide what "good" means before you run anything
Four metrics, defined up front so you can't rationalize afterward:
| Metric | How to measure | What's respectable |
|---|---|---|
| Success rate | 2xx AND real content (not a challenge page) | Depends entirely on your mix; compare candidates, not absolutes |
| Output quality | Spot-check markdown: is the article there? Nav junk stripped? | Main content intact, boilerplate gone |
| Latency | p50 and p95 per request | Seconds for rendered pages is normal; minutes is not |
| Cost per success | credits spent / successful pages | The only number pricing pages can't tell you |
The sneaky one is the "real content" clause. A 200 response containing "Just a moment..." is a failure that naive evals count as success. Grep for challenge-page markers in every response.
Step 3: A runnable eval sketch
Here's the shape of it against link.sc's fetch endpoint. Adapt the URL list and you can run this today on the free tier:
#!/usr/bin/env bash
# eval.sh: run a URL list through link.sc and log results
KEY="lsc_your_key" # from https://link.sc/register
while read -r url; do
start=$(date +%s%3N)
body=$(curl -s -w '\n%{http_code}' \
"https://link.sc/v1/fetch?url=$url" \
-H "Authorization: Bearer $KEY")
ms=$(( $(date +%s%3N) - start ))
code=$(echo "$body" | tail -n1)
chars=$(echo "$body" | head -n -1 | wc -c)
echo -e "$url\t$code\t$chars\t${ms}ms"
done < urls.txt
Then the manual part nobody automates well: open ten random outputs and read them. Is the content actually there, in clean markdown an LLM can use? Character counts catch empty shells; only eyeballs catch subtly mangled extraction.
For a stricter pass, flag any body under ~500 characters or containing challenge-page strings, and diff a few outputs against the page in your own browser. The quickstart docs cover response fields if you want to log credit costs per request too.
Step 4: Compute cost per successful page
This is where evaluations earn their keep. Take each candidate's credit usage from your run, divide dollars by successful pages, and compare that, not headline credits per dollar. Multipliers for rendering and stealth mean two providers with identical-looking pricing can differ 5x on your specific mix. I unpacked the mechanics in what is a credit.
A worked example with made-up round numbers, purely to show the arithmetic: if 100 test URLs consumed 260 credits and 92 succeeded, that's 2.83 credits per success. On a plan priced at $99 for 100k credits, that's roughly $0.0028 per successful page, and your 100k-page monthly workload pencils out around 283k credits. Do this same arithmetic for every candidate.
Step 5: Re-test before you scale, and periodically after
Two habits that save pain later:
Re-run the eval right before committing to an annual plan. Anti-bot landscapes shift; a provider that aced your hard sites in March may not in July.
Keep the eval script. A monthly free-tier run against your test set is a cheap canary. When your production success rate dips, you'll know within minutes whether it's your pipeline or the provider.
If your eval reveals that most of your workload is one or two easy domains, it's also worth rerunning the build vs buy math; an eval sometimes talks you out of an API entirely, and that's a fine outcome too.
The honest pitch
I obviously want you to include link.sc in your candidate list. But the meta-point stands regardless of who wins your bake-off: free tiers exist precisely so you never have to trust a pricing page or a blog post (including this one). An afternoon and 50 real URLs will tell you more than any vendor can.
Ready to run the eval? Create a free link.sc account and put your 100 hardest URLs through 500 free credits.