A real cost breakdown of six SERP API providers, what the pricing pages don't tell you, and what I changed.
I want to be upfront about something before this post goes anywhere: I'm going to show you real numbers from my own invoices. Some of them are embarrassing in retrospect. That's kind of the point.
Last year I was building a rank tracking tool as a side project — nothing fancy, a weekend job that got out of hand in the best way. I needed Google search results in structured JSON. I found a provider, loved the docs, integrated it in an afternoon, shipped a first version, and basically didn't think about it again for six months.
Then I sat down to do an actual financial review of the project and realized I'd spent $340 on SERP data over those six months, for a tool that had maybe 12 active users.
I opened the invoice. Did the math backward. Found the unit price.
$25.00 per 1,000 search calls.
The Number I Didn't Look Up Before Signing Up
$25 per 1,000 doesn't sound outrageous until you realize how fast queries add up.
My rank tracker was checking 50 keywords across 3 clients, twice a day. That's 300 API calls a day. 9,000 a month. At $25/1K, that's $225/month — for a tool with 12 users.
The math I should have done before integrating: what's my expected monthly query volume, and what does that actually cost at this provider?
I didn't do it. Most developers don't. You find a provider with good docs and a clean API, you integrate it, and you move on. The invoice becomes a thing you notice six months later.
This post is me sharing what I found when I finally did the math — across six providers, tested with real queries.
The Six Providers I Actually Tested
I'm not going to name them all by name because pricing changes and I don't want this post to be stale. I'll give you the categories.
Here's what I found, per 1,000 searches, at each provider's most accessible entry point:
The spread between the most expensive and cheapest at scale is 250x to 500x, depending on how you count it. Same data. Structured JSON. Live search results.
What the Pricing Pages Don't Actually Tell You
Here's the thing: every provider's pricing page is technically accurate. None of them are lying. But there are four things that almost no pricing page explains clearly, and they matter a lot:
1. The queue vs. live distinction
Some providers have two rates: one for async/queued results (you submit a job, check back in 1–5 minutes) and one for synchronous/live results (you call it, you wait, you get back a response in seconds).
The price difference can be 3–4x for the same data.
For a rank tracker or research tool where you batch jobs overnight, the queued rate is probably fine. For a real-time user-facing feature, you need live. If you're not thinking about this before you integrate, you might be paying for live when queued would work, or discovering the queue delay at the worst possible time.
DataForSEO is the clearest example: $0.60/1K queued, $2.00/1K live. A 3.3x difference for the same search results, depending on how fast you need them.
2. What "1,000 searches" is counting
Some providers count each result page as one call. Some count each individual organic result. These are not the same thing.
If a provider charges "per result" and returns 10 results per page, their "$0.001/result" is $10 per 1,000 results — which is $1.00 per 100-result pull, not $0.001. The math only works out to the advertised number when you're pulling single results, which almost nobody does in practice.
Always calculate: what does one real request that matches my actual use case cost? Not "what's the headline unit price."
3. Credit expiry
This one bit me in a different context. Some providers' credits expire — 90 days, 12 months, varies. For a side project or a tool with variable usage, you can pay for a credit pack, use half of it, and watch the rest disappear.
The ones worth noting: Serpent API explicitly states credits never expire (their Growth and Scale tiers are earned permanently by deposit). Some newer providers have moved to PAYG with no expiry as a differentiator.
If your usage is uneven — busy months and quiet months — this matters more than the headline rate.
4. Multi-engine vs. Google-only
"SERP API" usually implies Google. Not always.
If you need Bing, Yahoo, DuckDuckGo, or Brave results — either because you're building something that specifically needs non-Google coverage, or because Microsoft's Bing Search API retirement in August 2025 left a gap in your stack — you need to check whether the provider covers multiple engines or just Google.
Several of the cheaper options are Google-only. Serpent API covers all five engines under the same API key and the same pricing structure, which is worth knowing if you're building anything that touches Bing queries.
The Code That Actually Changed My Bill
Here's the practical version: what I changed after doing the math.
Before (expensive provider, live mode, no batching):
import requests
def check_rank(keyword, url):
response = requests.get(
"https://[expensive-provider].com/search",
params={"q": keyword, "num": 100},
headers={"Authorization": "Bearer KEY"}
)
results = response.json()["organic"]
for i, result in enumerate(results):
if url in result["link"]:
return i + 1
return None
# Called 300 times a day — $225/month
for keyword in keywords:
rank = check_rank(keyword, "mysite.com")
After (Serpent API, queued batching, snapped limits):
import requests, time
SERPENT_KEY = "your_key_here"
def snap_to_ten(n, cap=100):
"""Round up to nearest 10 — Serpent API bills per started block"""
return min(cap, ((n + 9) // 10) * 10)
def batch_rank_check(keywords, target_url, num=100):
"""
Submit all keywords in one batch, collect results.
At $0.03/1K (Scale tier): 9,000 calls/month = $0.27
"""
results = {}
for keyword in keywords:
response = requests.get(
"https://apiserpent.com/api/search/quick",
params={
"q": keyword,
"engine": "google",
"num": snap_to_ten(num),
"country": "us"
},
headers={"X-API-Key": SERPENT_KEY},
timeout=30
)
data = response.json()
rank = None
for i, result in enumerate(data.get("results", [])):
if target_url in result.get("url", ""):
rank = i + 1
break
results[keyword] = rank
time.sleep(0.1) # gentle rate limiting
return results
# Same 9,000 calls/month. New bill: $0.27 at Scale tier.
ranks = batch_rank_check(keywords, "mysite.com")
The logic is identical. The response shape is slightly different (field names). The monthly cost went from $225 to, at the Scale tier, $0.27 for the same volume.
That's not a typo. That's the difference between $25/1K and $0.03/1K at 9,000 calls/month.
One Gotcha Worth Naming
Serpent API's pricing bills in blocks — you pay per started block of items, not per item. This means:
num=10 → you pay for 1 block (10 items)
num=11 → you pay for 2 blocks (20 items)
num=100 → you pay for 10 blocks
The snap_to_ten() function in the code above handles this automatically. Always snap your num parameter to the nearest clean multiple before sending the request — num=26 costs double num=25 for one extra result.
What I'd Do Differently From the Start
If I were starting over, three things:
Calculate volume before you integrate, not after. Estimate your monthly query count. Multiply by the provider's entry price. If that number is uncomfortable, look at your alternatives before you're six months in.
Check whether you need live or queued. If you're running background jobs or batch processing, queued rates can be dramatically cheaper and the delay doesn't matter. Only pay for live when the user is literally waiting for a response.
Read the credit expiry terms. Especially for side projects with variable usage. A "cheap" credit pack that expires in 90 days isn't cheap if you don't use it.
The Full Comparison, One More Time
For the specific case I was optimizing (rank tracking, 9,000 calls/month, don't need real-time sync):
For most side projects and small tools, the Default tier ($0.60/1K, no deposit) is already competitive with DataForSEO's queued rate. The Scale tier ($0.03/1K) makes sense if you're doing serious volume or building something you want to keep costs predictable on at scale.
Free tier: 10 calls, no card — enough to test the response shape and verify your parser works before committing anything.
If you're building anything with search data and want to share what you're working on — or if I've got any of the comparison numbers wrong, prices change — drop it in the comments. Happy to update.
Top comments (0)