Quick answer
A Google Search API in Python lets your application send a query and receive machine-readable search data instead of parsing a browser page by hand. The phrase can mean an official Google search service, Search Console data, Gemini grounding, or a third-party SERP API. The sections below show how to choose the right interface and parse JSON results safely.
If you need public Google result pages for SEO monitoring, research, RAG retrieval, or an AI agent, start with the data you need. Search Console is for your own search-performance data. Grounding is for model responses with search-backed context. A SERP API is for retrieving the visible search result structure, such as organic results, People Also Ask, and entity data.
What “Google Search API” can mean
The same phrase is used for several different jobs. Choosing an interface before defining the output usually creates confusion later, especially when a tutorial promises “Google results” but in practice returns site-search documents or Search Console metrics.
| API category | What it returns | Best fit |
|---|---|---|
| Official Custom Search service | Searchable documents from a configured search engine | Site search and controlled document discovery |
| Search Console API | Search Analytics data for a verified property | Queries, clicks, impressions, CTR, and position for your site |
| Grounding with Google Search | Search-backed context and citations for supported model workflows | Model answers that need current web context |
| Third-party SERP API | Structured results from a live Google results page | Rank tracking, SERP analysis, SEO research, and retrieval pipelines |
These categories overlap in conversation but not in output. A Search Console request cannot replace a live SERP response, and a SERP response should not be presented as your site’s Google Analytics or Search Console data.
For a product implementation that returns Google SERP JSON, see the SearchCans Google Search API. For your own performance data, use the Google API that has access to your verified property. For a model workflow, define where citations and source content will be stored before adding search to the agent.
How to choose the right Google Search API
Ask these questions before writing code:
- Do you need public result pages or performance data from your own site?
- Do you need only titles, links, and snippets, or also SERP features?
- Must the result be localized by country and language?
- Will the response feed a human dashboard, a crawler, a RAG pipeline, or an agent tool?
- Do you need one page at a time, or a controlled range of pages?
If the answer is “public Google results in structured JSON,” the SearchCans SERP endpoint is designed for that workflow. It uses a POST request, a Bearer token, and a JSON request body. The current stable endpoint is:
POST https://www.searchcans.com/api/v1/search
The core request fields are:
t: search engine type, such asgoogles: the search querycountry: an ISO 3166-1 alpha-2 country codelanguage: a BCP 47 language codep: a specific SERP pagepage: a range of pages from 1 through N
Optional fields can request raw SERP HTML, AI Overview data, Knowledge Graph data, People Also Ask questions, news aggregation, video aggregation, and related searches. A field may be absent or empty for a particular query, so downstream code should treat optional sections as optional.
Google Search API in Python: a minimal JSON request
Install the HTTP client once in your project:
pip install requests
Keep the key outside the source file. The following example sends one query and prints the organic result positions and titles:
import os
import requests
API_URL = "https://www.searchcans.com/api/v1/search"
API_KEY = os.environ["SEARCHCANS_API_KEY"]
payload = {
"t": "google",
"s": "google search api python",
"country": "us",
"language": "en",
"p": 1,
"knowledgeGraph": True,
"peopleAlsoAsk": True,
"peopleAlsoSearchFor": True,
}
response = requests.post(
API_URL,
headers={"Authorization": f"Bearer {API_KEY}"},
json=payload,
timeout=30,
)
response.raise_for_status()
data = response.json()["data"]
for result in data.get("organic", []):
print(result.get("position"), result.get("title"), result.get("link"))
The API response is nested under data. The organic array contains the blue-link result objects. Use .get() for optional keys because result layouts vary by query and a SERP feature may not appear on every page.
In production, add structured logging, a bounded retry policy for transient failures, and a timeout that matches your job’s latency budget. Do not retry every error forever. A malformed request, invalid key, or unsupported parameter needs a clear failure path rather than an aggressive retry loop.
Parsing organic results, PAA, and Knowledge Graph data
Search results are more useful when the parser preserves the structure of the page instead of flattening everything into one text field. A defensive parser can keep the main result list and optional features separate:
def parse_serp(response_json: dict) -> dict:
data = response_json.get("data") or {}
organic = []
for item in data.get("organic", []):
organic.append(
{
"position": item.get("position"),
"title": item.get("title"),
"url": item.get("link"),
"snippet": item.get("snippet"),
}
)
return {
"organic": organic,
"people_also_ask": data.get("peopleAlsoAsk") or [],
"knowledge_graph": data.get("knowledgeGraph") or {},
"related_searches": data.get("relatedSearches") or [],
}
There are two important implementation details here:
- Preserve
positionas a number when you compare ranking snapshots. - Store the query, country, language, page, and collection time beside the response. Without those dimensions, two different SERP snapshots can look comparable when they were generated for different markets or pages.
For content research, People Also Ask and related searches are useful query-expansion signals. They are not a guarantee that every question will appear for every location or on every future request. Treat them as observed SERP features, not permanent fields.
If the next step is to read the full page behind a result, pass the selected URL to the Reader API. SERP search discovers candidate URLs; Reader extracts the page content. Keeping those jobs separate makes it easier to control cost, retries, and evidence quality in an AI or RAG pipeline.
Pagination, localization, and production boundaries
The p and page parameters serve different purposes:
# Fetch one specific SERP page.
one_page = {"t": "google", "s": "google search api", "p": 3}
# Fetch pages 1 through 3 in one request.
page_range = {"t": "google", "s": "google search api", "page": 3}
Use only one of these as a value greater than 1 in a request. p selects a specific page. page requests a range beginning at page 1. If both are greater than 1, p takes priority, which can produce a result set different from what the caller intended.
Country and language are part of the query definition, not cosmetic metadata. A US English request and a French request can return different domains, snippets, and SERP features. Store them with your result record and keep them stable when you compare ranking changes.
For a scheduled rank tracker or research job, use a queue with bounded concurrency. SearchCans plans expose Parallel Lanes for concurrent in-flight requests. A lane is concurrency capacity, not a monthly quota or a reason to create unbounded worker threads. Match your worker count to the plan and the workload, then measure timeout and error rates before increasing concurrency. The rate-limit and throughput guide explains the distinction in more detail.
Google Search API pricing and free access
Pricing depends on which API operation you run and which plan you choose. SearchCans uses prepaid credits. New accounts receive 100 free credits without a card, and a standard Google or Bing SERP call costs 1 credit. Reader standard mode costs 2 credits. Proxy and other optional processing modes can add credits.
The current SearchCans pricing page is the source of truth for plan prices and credit balances. Higher-volume plans can reach $0.56 per 1,000 credits. That is a credit rate, not a promise that every workflow has the same total cost. A multi-page SERP request, a Reader follow-up, proxy escalation, retries, and storage all belong in the workload estimate.
For a basic estimate:
SERP cost = successful SERP calls × 1 credit
Reader cost = successful standard Reader calls × 2 credits
Total credits = SERP cost + Reader cost + selected add-ons
Credits are deducted only for successful HTTP 200 responses according to the current product rules. Keep billing calculations close to the actual request log, and recheck the live pricing page before publishing a commercial comparison or committing to a budget.
Google Search API for SEO, RAG, and AI agents
The same search response can support different workflows, but each workflow needs a different quality check.
SEO monitoring
Store the query, market, language, page, result position, URL, and timestamp. Compare like with like. If a page moves, the snapshot should tell you whether the query or location also changed. Add the Google Search API product page to your implementation notes for the current response fields.
RAG retrieval
Use the SERP response for discovery and filtering. Select a small set of relevant URLs, then use Reader to extract the source content. Keep the source URL and retrieval time with each chunk. Search snippets are useful for ranking candidates, but they are not a substitute for the source page when the answer needs detailed evidence.
AI agent tools
Give the agent a narrow tool contract: query, engine, country, language, page, and optional SERP features. Validate the arguments before sending the request. Return a compact, typed result to the model and preserve the raw response in your application’s evidence store when policy allows.
Content research
Use the SERP API to map competing formats, PAA questions, related searches, and repeated entities. Then read representative pages with Reader. The goal is not to copy the top results. It is to identify the unanswered part of the query and produce a clearer, more useful page with first-hand product facts and a defensible point of view.
FAQ
Q: Is Google Search API free?
A: Some official Google services and third-party platforms have limited free access, but the quota and output differ. SearchCans currently offers 100 free credits without a card. Check the live pricing page for current credit rules before estimating a workload.
Q: Is there an official Google Search API?
A: Google provides several APIs that people call a “Google Search API,” but they solve different problems. Custom Search, Search Console data, and model grounding should not be treated as interchangeable with a live SERP API.
Q: Can I use Google Search API with Python?
A: Yes. A Python client can send a POST request with requests, a Bearer token, and a JSON body. Keep the API key in an environment variable, set a timeout, validate the response, and handle optional SERP fields defensively.
Q: What does a Google Search API return?
A: The returned fields depend on the API and request options. A SearchCans SERP response can include organic results and optional sections such as Knowledge Graph, People Also Ask, news, video, related-search, and raw HTML data when requested.
Q: What is the difference between a SERP API and the Search Console API?
A: A SERP API retrieves observed search-result data for a query and market. The Search Console API reports search performance for a verified property, such as clicks, impressions, CTR, and average position. Use the one that matches the data you need.
Next step
Start with a small set of queries and one market. Save the complete request dimensions, parse optional fields without assuming they exist, and add Reader only for the URLs that need full content. When the pipeline is ready, use the SearchCans playground to test the request before moving it into a scheduled job.