What Fields Should a Google SERP API Return?

A useful Google SERP API should return enough context to show what was searched, where it was searched, when the results were collected, and what appeared in the SERP. At minimum, a Google SERP API response should include the query, country, language, location when relevant, device when relevant, collection time, request status, result type, position, title, URL, displayed link, snippet, and nested elements such as sitelinks when they appear.

If an API returns only a list of titles and URLs, it may be fine for quick discovery. It is not enough for rank tracking, reporting, competitor monitoring, or AI workflows that need traceable evidence. The missing fields matter because a SERP result is not just a page. It is an observed search result inside a specific query, market, device, layout, and collection time.

Evaluate the response as an evidence contract, not a loose provider export. The field name matters less than the meaning behind it. position, for example, is useful only if the API explains whether it means organic rank, absolute rank across all visible SERP elements, group rank inside one result type, or page-relative order.

The Short Answer: A SERP API Should Return Context Plus Structured Results

The baseline response should have two layers:

Request context and metadata that describe the search event.
Structured result objects that describe each observed SERP element.

That usually means the response should preserve these fields:

Field group	Minimum fields	Why it matters
Request context	`query`, `country`, `language`, `location`, `device`	Shows which search state the results belong to.
Collection metadata	`collected_at`, `status`, `request_id`, `page`, `result_depth`	Makes the observation auditable and repeatable.
Result identity	`result_type`, `position`, `title`, `url`, `displayed_link`, `snippet`	Shows what appeared and how it was framed.
Nested features	`sitelinks`, PAA items, local results, rich snippets, shopping items, video or news objects	Prevents complex SERP elements from being flattened into misleading rows.
Traceability	raw provider payload, normalized internal fields, validation status	Lets the team debug mapping errors and missing fields later.

For AI workflows, this maps to the SEO data an AI workflow needs: a scoped result record whose fields tell the model what it may and may not infer.

Decision rule: if the response cannot show the query, market, device, collection time, result type, URL, title, snippet, and position definition, do not treat it as production SERP evidence.

Start With Request Context and Metadata

SERP fields are only useful when the search context is clear. A result for one country, city, language, or device should not be compared with another result as if they were the same observation.

A practical response should include:

Metadata field	What to check	Red flag
`query`	Exact searched phrase, not just a keyword group.	The response only stores a topic label.
`country`	The country or search market used for collection.	Market is inferred later from the project.
`language`	Search language or interface language when supported.	Multilingual results are mixed without labels.
`location`	City, region, coordinates, or null when not used.	Local intent queries are collected with vague location scope.
`device`	Desktop, mobile, or a documented default.	Mobile and desktop positions are blended.
`collected_at`	Timestamp with a clear timezone policy.	Freshness is guessed from when the job finished downstream.
`status`	Success, partial, blocked, timeout, error, or another explicit state.	Failed or partial jobs return empty result arrays without explanation.
`request_id`	A trace ID for debugging and support.	The team cannot connect a stored record to the original API call.
`page` or `result_depth`	Which result window was collected.	Page-one and deeper results are merged without context.

This layer protects reporting and AI workflows from false precision. A table of URLs may look clean, but without request context it cannot answer whether the result was observed in the right market, on the right device, at the right time.

Practical rule: missing context does not always make the data useless, but it should downgrade the use case. Use it for exploratory source discovery, not for rank tracking, trend comparison, client reporting, or automated recommendations.

Core Organic Result Fields to Expect

Most users evaluating a Google SERP API are looking for organic result fields first. The field names vary by provider, but the response should be mappable into a stable internal schema.

Field	What it should mean	What to verify
`title`	The visible title link shown in the SERP.	Whether it is the observed SERP title or a page title extracted later.
`url` or `link`	The destination URL associated with the result.	Whether it is a clean destination, a Google redirect URL, or a provider-normalized URL.
`displayed_link` or `displayed_url`	The visible breadcrumb, domain, or formatted URL shown to searchers.	Whether it is stored separately from the actual destination URL.
`snippet`	The visible preview text shown under or near the result.	Whether missing snippets are explicit instead of silently empty.
`position`	The result's rank or order within a documented scope.	Whether this is organic position, absolute position, group rank, or page-relative order.
`result_type` or `type`	The SERP element class, such as organic, ad, local, news, video, PAA, or shopping.	Whether mixed SERP features are separated before comparison.
`source` or `domain`	The visible or parsed source domain.	Whether it is derived from the URL, displayed link, or provider parser.
`date`	A visible date signal when Google shows one.	Whether missing dates are marked unknown instead of treated as evergreen.
`sitelinks`	Child links attached to a parent result.	Whether they remain nested under the parent result.
Rich fields	Rating, review count, price, thumbnail, author, favicon, or extensions when present.	Whether optional fields are typed and not required for every result.

A strong API response does not need every optional field on every result. Google result layouts vary by query and result type. The important requirement is that missing fields are explicit, result types are labeled, and optional objects do not break the structure of the response.

Red flag: if the provider uses the same flat row format for organic results, ads, local pack entries, shopping results, videos, and sitelinks, the integration will need careful normalization before the data is safe to compare.

What Each Field Can and Cannot Prove

The main gap in many field lists is that they name fields without explaining what those fields are allowed to support. That is risky when the response feeds reports or AI systems.

Field	Safe use	Unsafe use
`title`	Understand the visible result title and search framing.	Treat it as the page's HTML title, H1, or canonical page headline.
`url`	Identify the observed destination and choose sources for extraction.	Assume the final resolved URL, canonical URL, or live page status without checking.
`displayed_link`	Understand the visible source cue shown in the SERP.	Store it as the crawlable destination URL.
`snippet`	Read the visible preview text and infer search-result framing.	Treat it as proof that the full page covers a topic or claim.
`position`	Measure observed visibility inside a defined query-market-device-date context.	Treat it as a universal ranking across markets, devices, dates, or result types.
`sitelinks`	Understand extra links Google attached to a parent result.	Count each sitelink as an independent organic ranking unless the schema explicitly supports that analysis.
`result_type`	Separate organic results from ads, local results, PAA, shopping, news, video, and other SERP elements.	Ignore it and compare every visible item as if it were the same kind of result.

This matters because SERP data is presentation evidence. It tells you what Google displayed for a search event. It does not automatically tell you what the destination page currently contains, what schema it uses, whether the page is canonical, or whether the snippet reflects the most important content on the page.

If the response will feed AI automation, it should separate SERP evidence from source-page evidence before any model summarizes, compares, or recommends.

Decision rule: use SERP fields to decide what to inspect, compare, monitor, or validate next. Use source-page extraction when the workflow needs page-level facts.

Position and Result Type Need Separate Semantics

position is one of the most useful fields in a SERP API response, but it is also one of the easiest to misuse. A single number is not enough. The API should explain the ranking scope.

There are several common meanings:

Position concept	Meaning	Safe comparison
Organic position	Rank among organic results only.	Compare with other organic results collected under the same query, market, device, and date rules.
Absolute position	Order across visible SERP elements, including ads or features if the provider counts them.	Compare only when the provider documents exactly which elements are counted.
Group rank	Rank within a result group, such as local pack items, shopping items, videos, or PAA items.	Compare inside the same result type only.
Page-relative position	Position within the requested page or result window.	Use only when pagination or result depth is preserved.

Result type should travel with position. Without it, a ranking table can silently mix organic links, sponsored results, local pack entries, videos, news cards, People Also Ask questions, shopping items, knowledge panels, featured snippets, related searches, and AI overview-style blocks.

That creates unreliable decisions. A local pack result, an organic blue link, and a video carousel item may all be valuable, but they are not the same ranking unit.

Red flag: do not compare a featured snippet, a local pack slot, a shopping item, and an organic result as if one position field made them equivalent.

Sitelinks and Rich SERP Features Should Stay Nested

Sitelinks are not ordinary organic results. They are child links attached to a parent result. A useful response should keep that parent-child relationship intact.

A sitelink object should usually preserve:

parent result identifier;
sitelink title;
sitelink URL;
optional description or snippet when present;
layout type when available, such as inline or expanded;
the parent result's position and result type.

Flattening sitelinks into the main organic result array can create misleading counts. A domain with one main result and four sitelinks should not automatically become five separate organic rankings. It may be five visible links, but it is still one parent result with nested child links unless the API clearly defines a different model.

The same principle applies to other rich SERP features. People Also Ask items, local pack businesses, shopping products, video cards, news results, and AI overview-style references should be represented as typed nested objects or typed result groups. They can be valuable fields, but they should not be forced into the same shape as a standard organic result.

Decision rule: preserve nesting when the SERP feature is nested in the interface. Flatten only after you define what the flattened row means.

URL Fields Need Traceability, Not One Pretty String

URL handling is where clean-looking data can become hard to audit. A single url field is useful, but production workflows often need more than one URL-related value.

URL field	Meaning	When it matters
`observed_url`	The URL captured from the SERP source or provider response.	Auditing what was actually observed.
`displayed_link`	The visible breadcrumb or formatted URL shown in the result.	Understanding searcher-facing source cues.
`redirect_url`	A redirect or tracking URL when the provider exposes one.	Debugging click paths or provider parsing behavior.
`final_url`	The resolved destination after redirects, when checked.	Source-page extraction, deduplication, and status validation.
`canonical_url`	The canonical hint found during page extraction, when checked.	Page-level consolidation and content analysis.
`domain` or `source`	Parsed source label.	Domain-level grouping, competitor lists, and reporting.

Do not let URL normalization erase the original observation. Lowercasing hostnames, removing tracking parameters, resolving redirects, or merging variants may be useful, but the workflow should still be able to explain which URL appeared in the SERP.

For larger pipelines, this is where teams should normalize raw SEO and SERP data into a stable internal schema without losing the original source trace.

This is especially important for AI workflows. If an AI recommendation cites a competitor page, the team should be able to trace the recommendation from the normalized source back to the observed SERP result and then to the extracted destination page.

Red flag: if the system keeps only a cleaned URL and drops the displayed link, raw observed URL, parent result, and resolution status, later audits will be weaker than the original data.

A Field Checklist for Choosing a Google SERP API

Use this checklist before a SERP API response becomes part of rank tracking, competitor discovery, reporting, source selection, or AI-generated recommendations.

Check	Pass condition	Action if it fails
Request context	Query, country, language, location when relevant, device, and result depth are present.	Use only for exploratory research until context is fixed.
Collection metadata	Timestamp, status, and request ID or trace ID are available.	Do not use for freshness-sensitive reporting.
Organic fields	Title, URL, displayed link, snippet, position, and result type are mapped clearly.	Normalize internally or ask the provider for field semantics.
Position definition	Organic rank, absolute rank, group rank, or page-relative position is documented.	Do not compare positions across records.
Result type coverage	Organic results are separated from ads, local, PAA, shopping, news, video, and other features.	Reject for mixed-layout reporting until types are reliable.
Sitelink structure	Sitelinks stay nested under their parent result.	Do not count them as independent organic rankings.
URL traceability	Observed URL, displayed link, final URL when resolved, and domain handling are separable.	Add an internal URL normalization layer before analysis.
Missing fields	Unknown, not applicable, partial, and error states are explicit.	Treat silent blanks as validation warnings.
Raw payload access	The original provider response can be stored or inspected when needed.	Expect harder debugging when mappings fail.
Validation status	The workflow can mark records valid, partial, stale, invalid, or needs review.	Add validation before data reaches reports or AI prompts.

Before the response becomes an input to automation, use a separate gate to validate incoming search data against the decision it is supposed to support.

The checklist should produce one of five decisions:

Integrate the API because the response preserves context, core fields, result types, URL traceability, and validation states.
Integrate with internal normalization because the fields are useful but provider-specific names need a stable internal schema.
Use only for exploratory research because the response has titles and URLs but weak context, timestamp, or position semantics.
Ask for clarification before production use because sitelinks, result types, missing fields, or position definitions are ambiguous.
Reject the API for production workflows when it silently omits fields, flattens mixed result types, or cannot prove what was searched and observed.

The best Google SERP API response is not the longest response. It is the response whose fields preserve what was searched, where it was searched, what appeared, and what each field is allowed to support.