Debugging SERP API
Use thex-brd-debug response header to extract detailed debug information about your requests.
Activate by appending -debug-full to your proxy username:
x-brd-debug response header will look like this:
Common Error Codes
Example 429 response
SERP API error catalog
Fast SERP runs inside the SERP API and shares its error codes. When a request fails, the error code is returned in thex-brd-error-code response header and a human-readable message in x-brd-error, as shown in the examples below. None of the errors in this catalog are billed.
HTTP Error 502
A 502 means the request failed due to an issue on Bright Data’s side. Read the error code to tell them apart.Example query mismatch response
HTTP Error 429
A 429 means a rate limit was reached. Read the error code to tell them apart.Example rejected query response
client_10110 uses the proxy-layer headers, read both when handling a 429:
sr_rate_limit and bucket_rate_limit responses also state the limit that was applied:
Handling query mismatches (unexpected_q)
By default, when Bright Data detects that Google returned results for a different query than the effective query Bright Data sent to Google, the request returns theunexpected_q error and you are not billed. If you prefer to receive the mismatched data and validate it yourself, enable return_mismatch:
- Proxy requests - add the request header:
- API requests - add to the request body:
How to detect query truncation
When automatic search query optimization is enabled,
general.query is the effective query Bright Data sent to Google after any eligible optimization. Compare this value—not necessarily the query originally submitted—with general.detected_query.pizza in tlv can return results for pizza. This behavior applies to both the SERP API and Fast SERP text (web) search. By default these responses return the unexpected_q error (see above). If you enabled return_mismatch, validate each response yourself by comparing general.query with general.detected_query, then checking for a spelling object to tell a genuine spelling correction apart from a truncated search:
- If
general.queryandgeneral.detected_querymatch, Google returned results for the effective query Bright Data sent. - If they differ, check for a
spellingobject:spellingpresent - Google auto-corrected the spelling and the results are valid for the corrected query.spellingabsent - Google truncated (cloaked) the effective query and returned results for a shorter version.
detected_query differs from query but a spelling object confirms the results are valid:
general and spelling field definitions, see Parsed JSON results for the SERP API or Fast SERP web search for Fast SERP.
What happens when a query is blocked
When Bright Data detects that Google has flagged a query, that exact query is blocked across the SERP API and Fast SERP for 15 seconds. Any request for the same query during that window returns thefailed_query_rejected error (or repeat_query_rejected if the query was throttled for being repeated). Retry the query after the 15-second window, or vary the query, to receive results. Repeatedly hammering flagged queries hurts overall success rates. If your queries are generated synthetically (templates, LLMs, keyword permutations), track which patterns repeatedly trigger rejections or truncation and reformulate them. See SERP API error catalog for the full error responses.
Get Success Rate Statistics Per Domain
Retrieve SERP API success rate stats from the past 7 days. Supports single domain or wildcard.Single domain
All monitored TLDs