SERP API pricing looks simple: a price per thousand searches, a handful of monthly plans. The bill that arrives is rarely what teams expected, because the number of searches a project needs is the product of several decisions that are easy to make without noticing their cost. Track a few more cities, add mobile, go a page deeper, check daily instead of weekly, and the volume multiplies.
This guide breaks a SERP API bill into its parts, explains the change that made deep rank tracking ten times more expensive in 2025, and shows how to plan a workload that buys the data you need without paying for data you do not use. It includes a small calculator you can run against your own numbers and any provider’s price list.
Key takeaways
- Monthly searches are keywords times pages times locations times devices times engines times checks per month. Every factor multiplies the others.
- Depth is the most expensive factor now. Since Google stopped honouring the parameter that returned 100 results on one page in September 2025, tracking the top 100 takes ten requests instead of one.
- The cheapest saving is usually frequency: check volatile, high-value keywords daily and the long tail weekly.
- Compare providers on what you are charged for, not just the headline rate: whether failed and cached requests count, whether every engine is included, and how overage works.
- Plan the workload first, then choose the plan. A tiered schedule in our example delivered top-100 coverage for priority keywords at about an eighth of the volume of tracking everything to 100 daily.
What you are actually paying for
Most SERP APIs, including ours, bill per search request. A request is one results page, for one query, in one location, on one device, from one engine, at one moment. Everything else follows from that unit:
| Factor | What it means | Typical range |
|---|---|---|
| Keywords | Queries you track | Dozens to hundreds of thousands |
| Depth | How many positions you need; every 10 results is a page, and every page is a request | 10 to 100 |
| Locations | Countries, regions or cities you track separately | 1 to hundreds |
| Devices | Desktop and mobile results differ, so tracking both doubles volume | 1 or 2 |
| Engines | Google, Bing, Yandex and others, each a separate request | 1 to 3 |
| Frequency | How often each combination is checked | Monthly to several times a day |
Multiply them and the scale becomes obvious. Five hundred keywords, two devices, five cities and a daily check is 150,000 requests a month before you go past the first page.
Why depth got ten times more expensive
For years, rank trackers asked Google for 100 results on a single page with a URL parameter, num=100. One request returned the whole top 100. In mid-September 2025, Google stopped honouring it, and tools that relied on it began showing gaps until they switched to paging through results ten at a time.
The effect on cost is direct. Tracking the top 100 for one keyword now takes ten requests, so the same depth costs ten times as much. For many teams that changes the question from “how deep can we track?” to “how deep do we actually need to track, and for which keywords?” Most clicks go to the first page, and for most keywords knowing whether you are on it, and roughly where, is the decision-relevant fact.
A calculator for your own workload
The module below computes monthly requests for one or more tracking schedules. Multiply the result by any provider’s price per thousand to compare plans.
import math
from dataclasses import dataclass
RESULTS_PER_PAGE = 10 # Google stopped honouring num=100 in September 2025, so every 10 results is a call
@dataclass
class Workload:
keywords: int
depth: int # how many positions you need: 10, 20, 100...
locations: int = 1
devices: int = 1 # 2 if you track desktop and mobile separately
engines: int = 1
checks_per_month: float = 30.0
def calls_per_month(self):
pages = math.ceil(self.depth / RESULTS_PER_PAGE)
return math.ceil(self.keywords * pages * self.locations * self.devices * self.engines * self.checks_per_month)
def summarise(name, workloads):
calls = sum(w.calls_per_month() for w in workloads)
return f"{name}: {calls:,} calls a month"Run on four typical workloads:
from serpcost import Workload, summarise
WEEKLY = 52 / 12 # checks per month for a weekly schedule
print(summarise("500 keywords, top 10, daily", [Workload(500, 10)]))
print(summarise("500 keywords, top 100, daily", [Workload(500, 100)]))
print(summarise("Tiered: top 10 daily, plus top 100 weekly for 100 priority keywords",
[Workload(500, 10), Workload(100, 100, checks_per_month=WEEKLY)]))
print(summarise("200 local keywords, 5 cities, desktop and mobile, weekly",
[Workload(200, 10, locations=5, devices=2, checks_per_month=WEEKLY)]))500 keywords, top 10, daily: 15,000 calls a month
500 keywords, top 100, daily: 150,000 calls a month
Tiered: top 10 daily, plus top 100 weekly for 100 priority keywords: 19,334 calls a month
200 local keywords, 5 cities, desktop and mobile, weekly: 8,667 calls a monthThe second and third lines are the point. Tracking 500 keywords to the top 100 every day takes 150,000 requests a month. Tracking all of them on page one daily, and the 100 that matter most to the top 100 weekly, takes 19,334, about an eighth, and still answers nearly every question a ranking report is used for.
Seven ways to pay less
- Match depth to the decision. Track most keywords to the first page, and only go deeper for the keywords where moving from position 40 to 15 changes what you do.
- Tier the frequency. Check high-value and volatile keywords daily, stable long-tail keywords weekly. Our guide to detecting SERP volatility shows how to tell which is which from your own data.
- Only add locations that differ. City-level tracking matters for local intent and much less for informational queries; when city-level targeting matters explains how to decide.
- Only track both devices where they diverge. Measure desktop and mobile for a sample first; if rankings match closely, track one and spot-check the other.
- Deduplicate across clients and teams. Agencies often track the same keyword in the same location for several clients. Fetch it once and share the result.
- Cache within the day. If several systems need the same results page, store the first response and reuse it rather than requesting it again.
- Pay for results, not attempts. Check whether failed requests, retries and cached responses are billed, since failures are a hidden share of every bill.
Comparing providers fairly
Headline prices per thousand are only comparable once the units match. When comparing SERP APIs, ask:
| Question | Why it matters |
|---|---|
| Is a “search” one results page, or does deeper pagination cost extra credits? | Determines the true cost of depth |
| Are failed, empty or retried requests billed? | Failures are a hidden share of every bill |
| Is every engine and result type included, or priced separately? | Determines the cost of tracking beyond Google web results |
| Are location and device targeting included at the same rate? | Determines whether city-level or mobile tracking changes the rate |
| What happens above the plan: hard stop, overage rate or automatic upgrade? | Determines what a busy month really costs |
| Are results live or served from a cache, and is that labelled? | Determines how fresh the data is |
The cost per clean record principle applies here too: the meaningful number is what you pay per usable results page, after failures, retries and duplicates, not the list price per request.
Build or buy
Running your own collection through proxies can be cheaper at very high volume, but it brings parsing, maintenance and the work of keeping up with changes like the end of num=100. A SERP API moves that work to the provider. How SEO platforms use SERP APIs covers where the line usually falls, and automating daily keyword position monitoring shows a complete pipeline built on one.
The bottom line
A SERP API bill is the product of keywords, depth, locations, devices, engines and frequency, and since Google stopped returning 100 results per page, depth is the factor that multiplies fastest. The way to pay less is not to hunt for the lowest rate per thousand, but to buy only the requests that change a decision: page one for most keywords, deeper for the few that matter, daily where rankings move and weekly where they do not.
Run the calculator on your own workload before choosing a plan, and multiply by each provider’s rate to compare like with like.
Sources and references
- Search Engine Journal, Google modifies search results parameter, affecting SEO tools, September 2025.