DataForSEO SERP API: Pricing, Setup and How It Compares (2026)

You budget a SERP crawl at $0.60 per 1,000 keywords, the rate printed on the pricing page. The invoice comes back at thirty dollars.

Nothing went wrong and nobody overcharged you. The DataForSEO SERP API is a prepaid, wholesale API that returns parsed Google results as JSON, and it bills per SERP of ten results rather than per keyword. You paid the advertised rate for a different unit than the one you had in mind.

It is one of the cheapest ways to pull Google results at volume, and one of the easiest to mis-budget, because the thing it bills you for is not the thing you asked for.

The billing unit is a page of ten results, not a keyword and not a request. At $0.60 per 1,000 SERPs on the Standard queue, 1,000 keywords at depth=100 costs $6.00 because each keyword consumes ten units, and adding a single site: operator multiplies that again by five, to $30.00. Every step is documented behaviour, which is why the rate card and the invoice can disagree by 50 times without anybody making a mistake.

We build a Google search results API at FlyByAPIs, so we read competitor rate cards the way other people read contracts, closely and in a bad mood. Everything below comes from DataForSEO’s own pricing page, docs and help centre, checked in August 2026.

By the end you will know exactly what a task costs before you send it, how to wire up both delivery modes in Python, and which billing shape actually suits the job you are doing.

What one SERP actually costs

The base rate depends only on how fast you want the answer. Same data, three speeds.

Now the sentence that matters, and it is printed right there on their own Google Organic price card : “One SERP of Google Organic SERP API contains 10 search engine results.”

Read that again. DataForSEO’s billing unit is a page of ten results, not a keyword and not a request.

For a rank tracker checking positions one to ten, that unit is a perfect fit: one keyword is one unit, so 1,000 tracked keywords cost $0.60 on the Standard queue. For anything that needs depth, the maths changes shape entirely.

So the first question to ask any vendor in this category, including us, is what exactly one billed unit contains. When we describe SERP API pricing for our Google endpoint , the unit is one request, and that is the number worth pinning down before you compare anything else.

The 45 minutes hiding under “5 minutes”

Every article about this API repeats that the DataForSEO Standard queue takes about five minutes. That figure is real, and it is an average.

Underneath the same price card sits an asterisk that almost nobody quotes: “The target turnaround time is 45 minutes. Extended processing may occur.”

This is not a scandal. It is a queue, and queues have targets. But it does mean the cheap rate carries an operational cost that a per-request rate does not.

The documented target is nine times the five minute figure everybody quotes, so design for the target rather than the average.

It is also the clearest reason to check whether a queue is something you need at all. A synchronous Google search API answers on the spot and has no ready-list to poll, which removes the question rather than answering it.

The multipliers, and how they stack

Here is the part that turns $0.60 into $30. On top of the base rate sit parameters that multiply the cost of a task, and DataForSEO says plainly that “the final price can contain multiple multipliers.”

Take one realistic job: 1,000 keywords on the Standard queue, and watch what three ordinary decisions do to it.

$30.00 instead of $0.60, same 1,000 keywords. That is fifty times the headline number, and every step of it is documented behaviour.

Nobody hid anything. The rate card describes a metered product, and metered products reward people who read the meter.

The trap is not the price. The trap is assuming a keyword is a unit. On this API a keyword is however many ten-result pages your parameters demand, multiplied by whatever your query syntax triggers.

That site: multiplier is worth dwelling on, because site queries are exactly what you reach for when auditing indexation. A 1,000 page indexation check is one of the most natural jobs in SEO, and it is five times the price of the same volume of plain keywords.

Query syntax is the variable most people forget to price. On our own Google search scraping API an operator changes the results you get back and nothing else, because the meter does not read the query.

Setting it up in Python

Almost every article about this product stops at the pricing. Nobody shows you the wiring, which is a shame, because that is where the real difference between the two modes lives.

Three things to know before the first request:

• Authentication is HTTP Basic with your login and password, not a bearer token.
• The POST body is always a JSON array of task objects, even when you are sending exactly one.
• Both delivery modes return the same schema, so moving a job from Live mode to the queue changes the plumbing around the call, not the parsing inside it.

Live mode, one call

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

import os
import requests
from requests.auth import HTTPBasicAuth

AUTH = HTTPBasicAuth(os.environ["DFS_LOGIN"], os.environ["DFS_PASSWORD"])
URL = "https://api.dataforseo.com/v3/serp/google/organic/live/advanced"

payload = [{
    "keyword": "best running shoes",
    "location_code": 2840,     # United States
    "language_code": "en",
    "device": "desktop",
    "depth": 10,               # every extra 10 multiplies the cost
}]

response = requests.post(URL, auth=AUTH, json=payload, timeout=60)
response.raise_for_status()

task = response.json()["tasks"][0]
for item in task["result"][0]["items"]:
    if item["type"] == "organic":
        print(item["rank_absolute"], item["title"], item["url"])

The whole call is that short, and results land in about six seconds at $0.002 a SERP.

Note location_code. It is required unless you send location_name or coordinates, and the codes live behind separate lookup calls to /v3/serp/google/locations and /v3/serp/google/languages. Cache those locally on day one, otherwise you will be making a lookup request every time somebody adds a country.

Queue mode, three calls

The cheap rate requires the queue, and the queue requires you to hold state. Three calls, in this order:

1. Post the task to task_post, with priority: 1 for the Standard queue at $0.60 per 1,000 or priority: 2 for Priority at $1.20.
2. Poll tasks_ready rather than hammering task_get, and set your own timeout against the 45 minute target, not the five minute average.
3. Collect the result from task_get/advanced/{id} once that ID appears on the ready list.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

import os, time, requests
from requests.auth import HTTPBasicAuth

AUTH = HTTPBasicAuth(os.environ["DFS_LOGIN"], os.environ["DFS_PASSWORD"])
BASE = "https://api.dataforseo.com/v3/serp/google/organic"

# 1. Post the task. priority 1 = Standard ($0.60/1K), 2 = Priority ($1.20/1K)
posted = requests.post(f"{BASE}/task_post", auth=AUTH, timeout=30, json=[{
    "keyword": "best running shoes",
    "location_code": 2840,
    "language_code": "en",
    "priority": 1,
}])
task_id = posted.json()["tasks"][0]["id"]

# 2. Poll the ready list rather than hammering task_get
for _ in range(30):
    time.sleep(30)
    ready = requests.get(f"{BASE}/tasks_ready", auth=AUTH, timeout=30).json()
    ids = {t["id"] for r in ready.get("tasks", []) for t in (r.get("result") or [])}
    if task_id in ids:
        break
else:
    raise TimeoutError("Task never landed. Target turnaround is 45 minutes.")

# 3. Collect it
done = requests.get(f"{BASE}/task_get/advanced/{task_id}", auth=AUTH, timeout=30)
for item in done.json()["tasks"][0]["result"][0]["items"]:
    if item["type"] == "organic":
        print(item["rank_absolute"], item["title"], item["url"])

Look at what changed. You now need somewhere to persist task IDs, a poller, a retry policy, and a decision about what to tell a user who is still waiting after half an hour.

None of that is a criticism of the design. It is the honest cost of a queue, and it belongs in your estimate next to the per-SERP rate.

What it takes to open an account

There is no ongoing free tier. Registration gives you $1 of test credit, and after that the minimum payment is $50 .

One detail deserves credit, and it is rarer than it should be in this market. Their help centre states that once you top up, “the funds will remain on your balance until you spend all of them.” No monthly expiry, no use-it-or-lose-it.

The $50 floor is the part to plan for if you are still evaluating. It is a reasonable ask for a wholesale vendor, and it does mean the trial happens after the purchase order rather than before it. Our Google search API plans run the other way round, with a free tier first and a $19.99 entry plan after.

If you are shopping this category more broadly, our pricing breakdown across ten SERP API providers covers how the other rate cards are structured.

Metered billing versus flat billing

Forget the numbers for a second. The real fork in this decision is the shape of the bill, and there are only two of them.

The FlyByAPIs Google Search API sits on the flat side, deliberately. A request costs one credit whether the query carries a site: operator or not, and people_also_ask plus people_also_search_for come back in the same response at no extra charge. There is no element to switch on and no surcharge to forget about.

One authenticated GET, and the shape of it is the point:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

import os, requests

r = requests.get(
    "https://google-serp-search-api.p.rapidapi.com/search",
    headers={
        "X-RapidAPI-Key": os.environ["RAPIDAPI_KEY"],
        "X-RapidAPI-Host": "google-serp-search-api.p.rapidapi.com",
    },
    params={"q": "best running shoes", "gl": "us", "hl": "en", "num": 10},
    timeout=30,
)
data = r.json()["data"]

for item in data["organic_results"]:
    print(item["position"], item["title"], item["link"])  # position is 0-based

print(data["people_also_ask"])  # included, no extra call, no surcharge

No task IDs, no poller, no ready-list. Plans start at $19.99 a month, and there are 100 requests a month free if you want to run your integration before paying anybody. The Google Search API request and response fields are documented if you want to check the schema first.

Worth saying plainly: if your job is genuinely one keyword, ten results, once a day, on a queue you control, the Standard tier is a very sharp tool and you should use it.

Which one fits your job

Search results are rarely the only dataset a project needs, which is why we publish the neighbours on the same flat model: Google Maps business data extraction for local work, Amazon product data scraping for retail pricing, Crunchbase company data enrichment for firmographics, job listings search for hiring signals, and a translation API for multi-market pages. Same billing shape across all of them.

Before you send the first task

Run this in your head, or better, in a spreadsheet.

The short version

DataForSEO built a wholesale product and priced it like one. The meter is precise, it is documented, and it rewards anybody who reads it before writing the integration. A perfectly legitimate way to sell data.

The failure mode is not the vendor. It is reading $0.60 per 1,000 as $0.60 per 1,000 keywords, sending a depth=100 job full of site: queries, and finding out at the end of the month.

So do the arithmetic first. If the answer suits you, their rate is genuinely hard to argue with. If you would rather have one number per request and no meter to watch, that is the trade the FlyByAPIs Google search results API is built around, and its free tier of 100 requests a month is there to test it with before any money changes hands.

P.S. If you take one habit from this post, make it grepping your keyword list for operators before you queue a job. We have watched that single check turn a scary estimate back into a boring one more than once.

Oriol.