Short answer: set your HTTP client's timeout to 60 seconds, and never below 30. If you really do need a faster answer, ask for it with a request parameter rather than by hanging up. We measured this on our own traffic: a 5-second client timeout would have thrown away 9% of successful first-page results and 49% of successful results from later pages.
The data
We looked at every request to our Google search endpoint (POST /google/search) over seven days, 2–8 November 2026: 1,061,676 requests, of which 970,882 returned a result. Elapsed time is measured at our API edge, from receiving the request to finishing the response, so your own network time comes on top.
Three limits on what this data can tell you:
- It reflects our customers' mix. A few high-volume accounts make up most of it. About 29% of successful results were pages after the first, and about 44% used search operators such as
site:or quotes. Your own numbers will depend on what you search for. - It only times successes. Failed requests are not in the tables below.
- It undercounts slow requests. When a client hangs up early, the slow result it would have received is not in the sample. The real distribution is somewhat slower than shown.
These are measurements of one week on one provider. They are not a benchmark of SERP APIs in general and not a latency promise.
SERP API latency by page depth
Elapsed seconds for successful requests:
| Percentile | All requests | Page 1 | Page 2 and later |
|---|---|---|---|
| p50 | 2.4 | 1.9 | 4.9 |
| p75 | 4.3 | 3.2 | 14.2 |
| p90 | 13.5 | 4.8 | 21.3 |
| p95 | 16.4 | 7.0 | 25.6 |
| p99 | 26.5 | 15.3 | 28.4 |
The median looks comfortable, which is how people end up with a short timeout. The tail is where the problem is, and most of the tail comes from later pages.
What each timeout would have cost
Share of successful results that arrived within each client timeout:
| Client timeout | All requests | Page 1 | Page 2 and later |
|---|---|---|---|
| 3 s | 61.0% | 72.8% | 31.8% |
| 5 s | 79.5% | 91.0% | 50.7% |
| 10 s | 86.6% | 96.1% | 62.9% |
| 15 s | 93.1% | 98.8% | 79.0% |
| 20 s | 96.8% | 99.8% | 89.3% |
| 25 s | 98.2% | 99.9% | 93.8% |
| 30 s | 100% | 100% | 100% |
Read the 5-second row as: one in five of these results would have been lost, even though each one was about to succeed.
Findings
Page depth matters far more than query type. Page 1 has a p90 of 4.8 seconds and later pages 21.3 seconds. Operators barely change the picture: the p95 was 16.2 seconds with operators and 16.6 seconds without. If you crawl deep into results, budget for the later-page column.
There is a flat stretch from 8 to 12 seconds. Raising a timeout from 8 to 12 seconds gained only 2 percentage points (85.5% to 87.5%), but going from 12 to 15 gained 5.6 points (to 93.1%). Slow requests are usually ones where the first attempt did not work out and another one took over, so they tend to land after this gap. Small timeout increases in this range can look useless, which may stop you just before the increase that would help.
Nothing took longer than 30 seconds. The slowest success in the week was 29,999 ms. Every request ends on our side within 30 seconds with a result or an error, so waiting longer than that plus network time gains you nothing, and waiting less can lose you a result.
Short timeouts are a real pattern, not a theoretical one. Clients hung up on 37,867 requests, 3.6% of the total. About 70% of those disconnects (26,346) happened at almost exactly 5 seconds, and the next largest clusters were at 30, 10 and 20 seconds. Round numbers mean a configured timeout, not an impatient user. A dashboard that only counts HTTP errors never shows these, because from the client's side they often surface as a generic timeout exception that gets retried or swallowed.
What to do in your code
1. Use a 60-second client timeout as the default. That covers the 30-second limit plus room for the network. In Python:
import requests
resp = requests.post(
"https://api.serpbase.dev/google/search",
headers={"X-API-Key": "YOUR_KEY"},
json={"q": "best standing desk", "gl": "us", "hl": "en"},
timeout=60,
)
data = resp.json()
if data["status"] == 0:
print(data["organic"][0]["title"])
else:
print(data["status"], data["error"])
Note the check on status: the API answers HTTP 200 with a JSON envelope, and 0 means success. Checking only the HTTP status will miss failures.
2. When a person is waiting, set a budget instead of hanging up. Pass timeout (1–30 seconds) in the request on Google search endpoints and keep your HTTP client's timeout above it:
json={"q": "best standing desk", "gl": "us", "hl": "en", "timeout": 10}
The difference from a short client timeout is what you get back. Retries start earlier to fit your budget, and when it runs out you receive status 1504 straight away, not charged. Your code can show a fallback or try again later. If your client hangs up instead, we stop the request and refund it, but you have no result and no error to act on.
3. Give background jobs the full time. Rank trackers and batch pipelines rarely gain anything from a tight timeout. A result that takes 20 seconds is still a result you don't have to retry.
4. Measure what your client gives up on. Count client-side timeouts separately from API errors, and break them down by page number. If your timeout rate is high on later pages only, you have found the cause.
5. Limit how deep you go in interactive features. If a user-facing feature needs results in about 5 seconds, page 1 can meet that for around nine in ten requests, and later pages for only about half.
Related reading
- Responses and errors: timeouts, the reference for status codes and the
timeoutparameter - Google Web Search API reference
- How to build a keyword rank tracker in Python