SERP API rank tracking

What a SERP API contributes to rank tracking

A SERP API supplies result positions for a specific query and search context. It does not, by itself, run a recurring campaign, maintain keyword history, calculate visibility share or explain why a result moved. Those are application responsibilities.

Collect a repeatable snapshot

Send the same query and market settings each time. For Google web results, a request can look like this:

curl https://api.serqo.io/v1/search \
  -H "x-api-key: $SERP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"q":"espresso grinder","engine":"google","type":"web","gl":"us","hl":"en","device":"desktop"}'

Store the exact query, engine, type, gl, hl, device and collection time beside each response. Small changes in query or market create a different measurement and should be tracked separately.

Calculate a page-level position

1. Read data.results and inspect each item’s type, url, domain and position.
2. Decide whether the report measures a specific URL, a canonical page or any page on a domain.
3. Match URLs consistently, including redirects, trailing slashes and canonical paths.
4. Keep “not found in this response” distinct from a numeric position; the result may be beyond the returned page range.
5. Store the original snapshot so a changed URL or parsing rule can be reviewed later.

Compare snapshots carefully

Compare only records with the same query, engine, type, country, language and device. Record missing results instead of treating them as position zero. A result page can change between checks, and its layout may contain modules besides organic links. If the report is about organic ranking, filter by the result category your application considers organic rather than mixing maps, news or other modules into one sequence.

Set cadence and history in your system

Your scheduler determines how often to collect. Store timestamps in a consistent timezone and keep raw request inputs with the results. Aggregations such as daily median position, first-seen position or share of voice are your own metric definitions; document how each is calculated so reports remain comparable.

Frequently asked questions

Does Serqo automatically track a keyword over time?

No. Serqo returns a response for each request. Your system schedules checks and stores historical snapshots.

Can search position be compared across countries?

Yes, as separate market observations. Keep gl and hl with each record; do not combine markets into one position series.

Should I use the page’s position as a universal rank?

No. It is the position in one returned snapshot. Define the result type and market before comparing it, and do not assume every person sees the same results page.

Define what “rank” means in your report

A search page can contain organic links, ads, local results, news and other features. Before collecting data, decide whether your metric measures a specific organic URL, any URL on a domain, a local listing or another result category. Keep the definition visible in your report. A single number called “rank” becomes misleading when one chart includes different result categories or when the matching rule changes.

Store the query, engine, type, country, language, device and collection time with every response. Record the exact URL and the returned result category. If your business wants domain visibility, define how subdomains and country hosts are grouped. If it wants page-level position, use a stable URL normalization policy that accounts for redirects, fragments, trailing slashes and tracking parameters.

Choose a measurement depth and cadence

Rank checks cost time and credits. Decide how deep into the results the report needs to look; a campaign may only care whether a page appears in the first few pages, while research work may need a deeper sample. Set a maximum number of pages and stop when the API indicates there is no next page. Deeper checks should have a clear purpose rather than being an automatic default.

Choose collection frequency based on how quickly the result can affect a decision. A daily check can be useful for a short campaign or incident, while a slower schedule may be enough for a stable topic. Avoid interpreting small daily movements as a product or site change without checking query context, result features and other evidence. The API provides observations; it does not explain cause.

Store raw snapshots and derived metrics

Keep the original response or the relevant raw fields in addition to calculated values. Useful record fields include the query, engine, type, market settings, device, collection timestamp, result URL, result category, position, request ID and any classification version. Raw snapshots help explain a report later if URL matching changes or if the result page returns a different feature group.

Common metrics include first-seen position, median position over a period, visibility within a chosen depth, and the share of tracked queries for which a site appears. Each metric needs a written definition. For example, decide whether a missing URL is null, “outside the checked range,” or a separate status. Do not store missing results as position zero; zero looks like an observed rank and can distort averages.

Compare only like with like

Compare observations with the same query and search context. If a search moved from one country to another, split the chart or label the change as a new market. Likewise, keep desktop and mobile series distinct where device profiles are available. Search engines can return different layouts and ranking positions, so Google and Bing should have separate series even when the query is identical.

Results can move between scheduled checks, and a single response may not represent what every user sees. For important changes, look at more than one observation and review the page URLs and result categories behind the metric. If your application normalizes different country-specific URLs to one page, preserve both the original and normalized values so the report remains auditable.

Make the collection job reliable

1. Validate and version the set of tracked queries.
2. Use a bounded queue and a documented maximum page depth.
3. Store each request's settings and timestamp before aggregating it.
4. Handle missing fields and API errors separately from “not found.”
5. Retry only transient, retryable failures and cap the retry count.
6. Monitor the share of completed checks so missed collection runs are visible.

Successful searches are charged at the applicable rate. Cache hits are free under the default rules, while failed searches and timeouts release their reservation. A large tracked-keyword set can create many requests per run, so estimate the monthly volume before increasing cadence. See pricing and credits.

What Serqo handles and what your tracker handles

Serqo returns search results for each API request. Your tracker controls schedules, stores history, matches results to the sites being monitored, calculates metrics and sends alerts. Keeping that boundary clear helps you test the parts that can be measured and prevents a one-time API response from being presented as a continuous ranking service.

Explain uncertainty in the product

A rank chart is an observation, not a guarantee. Make the search context visible and show whether a URL was found within the depth you checked. If it was not found, say “not in returned results” or “outside checked range” rather than assigning a position of zero. These labels help users distinguish the limits of a collection from a true measured position.

For decisions such as a major traffic change, require more than one signal. Search result position does not directly measure impressions, clicks, conversions or the reason a page moved. Combine it with first-party analytics or webmaster data when the question concerns the performance of a site you own. Keep each source labeled so that a SERP observation is not mistaken for verified traffic data.

Review the model when the search page changes

Result pages change their layout over time. A new answer block, local pack or other feature can change what counts as an organic result and how visible it is. Review your classification rules when the response begins to contain new groups or when a report's result mix changes unexpectedly. Save representative raw responses from your own collection to support that review.

Version derived metrics and matching rules. If a formula changes, show when the change took effect or recalculate the full history under the new rule. Mixing metrics computed by two different definitions in one chart can create a trend that never happened in search results.

Read the Google Search API reference or see how Google SERP requests work.