Quick answer: Serper is an API that returns Google search results as structured JSON: you send a query, it handles the scraping, and you get organic results, People Also Ask, related searches, and other SERP features back in milliseconds. It's fast, simple, and priced per search on a credit model. Its main limitation is that you only get snippets, so if your application needs the actual content behind the results, you'll pair it with a fetch layer or use an API like link.sc that puts search and page fetching behind one key.
Scraping Google yourself is miserable: consent screens, CAPTCHAs, IP blocks, and markup that changes without notice. Serper's entire job is making that someone else's problem. Here's how it works and when I'd pick something else.
What Serper Actually Does
Serper sits in the SERP API category: services that run Google searches on your behalf and return the parsed results as JSON. You never touch Google's HTML, never solve a CAPTCHA, never rotate a proxy.
What made Serper popular is focus. It doesn't try to be a scraping platform; it does Google results fast and cheap, with a straightforward credit-per-search model and endpoints for web, images, news, maps, and a few other verticals. Check their pricing page for current rates; they offer free starter credits, so testing costs nothing.
Setup and a Working Example
Sign up at serper.dev, grab your API key, and you're one POST request away from Google results:
import requests
resp = requests.post(
"https://google.serper.dev/search",
headers={"X-API-KEY": "your-serper-key"},
json={"q": "best postgres connection pooler", "gl": "us", "num": 10},
)
data = resp.json()
for item in data.get("organic", []):
print(item["position"], item["title"])
print(item["link"])
print(item.get("snippet", ""))
The gl parameter controls country, hl controls language, and num controls result count. If you do localized SEO work, those parameters are half the value of the product.
The SERP Fields You Get Back
The response is more than ten blue links. Depending on the query, you'll see:
- organic: the classic results, with position, title, link, and snippet.
- peopleAlsoAsk: the PAA questions with short answers. Gold for content research, since these are literal questions real people ask Google.
- relatedSearches: query expansions, useful for keyword discovery and for agents deciding what to search next.
- answerBox: the featured snippet, when one exists.
- knowledgeGraph: entity data for brand and person queries.
If you're building SEO tooling, rank tracking, or content research, these fields are the product. I go deeper on what you can build with them in the ultimate guide to SERP scraping.
The Snippet Problem
Here's the limitation that bites LLM builders specifically.
A snippet is roughly 20 to 40 words that Google chose to display, optimized for a human deciding whether to click. It is not the answer; it's an advertisement for the page.
If you feed snippets to an LLM and ask real questions, the model reasons over fragments. Ask "what are the connection limits of each postgres pooler" and the snippets mention that limits exist without telling you what they are. The model then guesses, fluently.
So the classic pipeline becomes: Serper for the URLs, then fetch each URL, then strip HTML, then feed the model. That works, and plenty of production systems do it. But you're now maintaining the fetch layer, which is where the actual difficulty lives (rate limits, bot walls, JS rendering).
The alternative is keeping both steps behind one API and one key. link.sc's search endpoint returns the ranked results:
curl -X POST https://api.link.sc/v1/search \
-H "x-api-key: lsc_your_key" \
-H "Content-Type: application/json" \
-d '{"q": "postgres connection pooler comparison", "engine": "google"}'
Each item in serpData.results carries a targetUrl, and the same key turns any of them into LLM-ready markdown with the fetch endpoint:
curl -X POST https://api.link.sc/v1/fetch \
-H "x-api-key: lsc_your_key" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com/pooler-comparison", "format": "markdown"}'
No fetch layer of your own to maintain, and your model sees the actual comparison tables instead of teasers about them. If your consumer is an agent rather than a dashboard, that difference is the whole game. More on that pattern in giving your AI agent internet access.
Serper Alternatives Compared
| API | What it returns | SERP features (PAA etc.) | Best for |
|---|---|---|---|
| Serper | Google results, JSON | Yes | Fast, cheap Google data |
| SerpAPI | Google + many engines, JSON | Yes, very complete | Breadth of engines, mature tooling |
| Brave Search API | Brave's own index | Limited | Volume on a budget, no Google dependency |
| Tavily | Agent-oriented search | No | RAG inside agent frameworks |
| link.sc | Search results plus a markdown page fetch endpoint | Yes (peopleAlsoAsk) | LLMs that need whole pages, not snippets |
Quick guidance:
- SerpAPI is the veteran: more engines, more parsed fields, generally higher per-search cost. If you need Bing, YouTube, or exhaustive SERP feature coverage, it earns the premium.
- Brave Search API skips Google entirely in favor of Brave's independent index. Cheaper at volume, and setup is easy (I wrote a Brave Search API key walkthrough), but you're not getting Google's ranking.
- Tavily is the right shape if you live in LangChain and want extracted content per result.
- link.sc is the pick when snippets starve your model and you don't want to build a fetch layer.
These aren't mutually exclusive. SEO tools often run Serper for rank data and a full-content API for page analysis.
When Serper Is the Right Call
To be clear about where Serper wins, because it genuinely does:
- Rank tracking. You need positions on Google specifically. Nothing else is even relevant.
- SERP feature monitoring. PAA, answer boxes, knowledge panels: only a Google SERP API sees these.
- High-volume, shallow lookups. Thousands of queries where a title and link suffice. Per-search credits stay cheap when you don't need content.
- Keyword and content research. relatedSearches plus peopleAlsoAsk is a research workflow in two JSON arrays.
When your question is "what does Google show for X," use Serper or SerpAPI. When your question is "what do the pages actually say," you need content, and a snippet API alone won't get you there.
The Bottom Line
Serper does one thing well: Google's results as clean JSON, quickly and cheaply. For SEO tooling and rank data, it's an easy recommendation.
For LLM applications, treat it as half a solution. Either pair it with a fetch layer you're prepared to maintain, or use an API like link.sc that handles the search and the page fetch behind one key. Run five of your real queries through both approaches and look at what your model produces; that comparison settles it faster than anything I can write here.
Want search results your LLM can actually read, full pages included? Start free with 500 link.sc credits a month.