Serper vs SearchApi: SERP Data at Crawl Volume Compared (2026)

On 2026-07-27, SearchApi's pricing page listed eight tiers between $40 and $5,000 a month, with the per-thousand rate falling from $4 to $1 along the way. Serper's pricing page returned a 404 on the same day, and so did its docs. Two vendors selling roughly the same thing, and only one of them will tell you the price before you open an account.

Serper and SearchApi do sell roughly the same thing. You send a query, you get parsed search results as JSON. Serper stays inside Google and competes on price and response time. SearchApi runs dozens of engines and verticals under one key. Both live in the SERP APIs category alongside SerpApi, DataForSEO, Brave Search API and a long tail of smaller providers, and for most buyers the choice between them is closer to a procurement call than an engineering one.

Head to head

Every SearchApi row above comes from its own pricing page, homepage and Google engine docs, all read on 2026-07-27. Every Serper row comes from its homepage on the same date, or from the absence of a public page where a competitor has one.

What one vendor publishes and the other does not

SearchApi publishes eight tiers. Developer is $40 a month for 10,000 searches, quoted as "$4 per 1,000 searches". Production is $100 for 35,000 at $3 per thousand. BigData is $250 for 100,000 at $2.50. Scale is $500 for 250,000 at $2. Then four Octo tiers: $900 for 500,000 at $1.80, $1,500 for a million at $1.50, $2,800 for two million at $1.40, and $5,000 for five million at $1. The curve is the usual volume ladder, and the interesting part is that the cheapest published rate is a quarter of the entry rate. Anyone buying at the Developer tier is paying a small-account premium.

Serper does not publish an equivalent table. On 2026-07-27 its homepage offered 2,500 free queries with no card, described the product as "The World's Fastest & Cheapest Google Search API", and both serper.dev/pricing and serper.dev/docs returned HTTP 404. That does not mean the pricing is bad. Serper's reputation in agent frameworks is built on being cheap, and it may well undercut every number in the paragraph above. It means you cannot verify the claim without an account, and a procurement process that needs a quote in writing has one extra step.

When you buy SERP data by the million, the per-thousand rate is most of the negotiation, so a posted ladder lets you model the spend before you write any code. Without one you sign up first and find out after. Our guide to credit pricing in scraping APIs covers the mechanics that hide inside a per-query rate, and evaluating web data providers covers the rest of the procurement checklist.

The num change reset everyone's cost model

SearchApi's Google documentation carries a line that changes the arithmetic for both vendors. The num parameter, which used to let you pull 100 results in one request, is documented as "Phased out by Google on September 2025. It is now constant 10."

If your rank tracking previously fetched a top-100 in one call and now needs ten paginated calls, your per-keyword cost went up by up to an order of magnitude, whichever vendor you use. Teams that budgeted a SERP contract before late 2025 and have not remodelled since are probably wrong about their spend. Neither product caused that, but it does mean a 2026 evaluation has to be built on the number of API calls your job makes rather than the number of keywords you track.

The change quietly favours the cheaper per-call vendor for deep rank work and the richer parser for shallow work. If you only need the top 10 you are paying for one call either way, and the question becomes how much of that page comes back parsed.

Coverage: one engine done cheaply, or many engines under one key

Serper's public surface is entirely Google, across ten endpoints. For rank tracking on Google, keyword research, or as the search tool inside an agent, that is the whole job. There is no coverage you are paying for and not using.

SearchApi's site lists more than 60 engines and verticals. The Google side includes Trends, Flights, Hotels, Jobs, Finance, Events, Lens, Forums and AI Overview alongside the usual web, images, news and maps. Off Google it lists Bing, Baidu, Yandex, DuckDuckGo, Yahoo and Naver for search, and Amazon, Walmart, eBay, Shein and BestBuy for retail, plus YouTube, Zillow, Airbnb, Tripadvisor and several ad libraries.

That list is a procurement argument, not a technical one. Price monitoring that spans Google Shopping, Amazon and Walmart can run on one key, one invoice and one integration instead of three vendors and three parsers. Local SEO work that needs Maps and Local results has them documented. If your roadmap has any of those verticals on it within the year, buying the broad vendor once is usually cheaper than buying the narrow one twice. If it does not, you are paying for a catalogue you will never call.

The Shopping engine is a good example of what the breadth buys. Its documented parameters include price_min and price_max with currency, is_on_sale, is_free_delivery, condition for new or used, and sort_by with options like price_low_to_high. The response splits shopping_ads, shopping_results and popular_products, which reads more like a product feed than a generic SERP dump. For price monitoring specifically, compare it against a dedicated retail scraper before assuming the SERP API is the right layer.

Parsed fields versus raw HTML

Both vendors sell you a parser as much as a proxy, so the question worth asking is how much of the page survives the trip.

SearchApi's Google docs list the top-level objects it returns: search_metadata, search_parameters, search_information, organic_results, ads, knowledge_graph, answer_box, local_results, shopping_ads, jobs, related_searches and pagination. That is a broad surface but a fixed one. Anything Google renders that SearchApi has not modelled does not reach you, and you will not know what is missing unless you look at the same query in a browser.

Serper's response shape is not publicly documented at a URL we could reach on 2026-07-27, though its homepage names organic results, knowledge graphs, people also ask and related searches among the things it returns. Confirm the schema during the free 2,500 queries.

Which is why the test that settles this is a fixed query set through both, followed by a field-level diff. Take 200 queries that represent your real traffic: some head terms, some long tail, some with local intent, some with shopping intent, some that trigger an AI Overview. Run them through both APIs on the same day. Then diff, per query, which fields came back populated, which came back empty, and which came back with a different value for the same rank. Disagreement between two SERP vendors on the same query at the same minute is normal, because they hit different data centres from different IPs. What you are looking for is systematic disagreement: a field one vendor always has and the other never does, or a vertical where one silently returns an empty array.

Do not run that test once and call it done. Run it for a week. Any single-day comparison is a snapshot of two proxy pools on one afternoon. Our notes on reading scraping benchmarks explain why published third-party numbers rarely transfer to your query mix. Proxyway maintains SERP API roundups and a guide to scraping Google, and there is no public head-to-head of these two specifically that we could open on 2026-07-27, so treat any ranking you find as a starting point to reproduce rather than a result to cite.

Location, language and the parts you cannot see

Localized results are the reason most rank trackers exist. SearchApi documents the controls: location for a canonical place, uule for Google's encoded location string, gl for country, hl for interface language, and device for desktop, mobile or tablet. The Shopping engine takes the same localization set. google_domain is documented as deprecated as of April 2025, which is a useful reminder that these parameters change under you.

Serper's endpoints are public but the parameter reference is not, so localization parity has to be established in a trial rather than read off a page. If city-level or postcode-level targeting is central to your product, that verification is the first thing to do with the free tier, not the last. Our guide to localized SERP collection covers what to check and where geo-targeting usually breaks.

Operational terms, and the risk each carries

Two SearchApi terms are worth noting because they are the kind of thing that only shows up in month two. First, "Only successful searches with a 200 status code incur charges", which means failed requests do not burn credits. Second, "You can utilize only up to 20% of your plan's credits each hour", which caps how fast you can drain a plan. On the million-query tier that is 200,000 queries an hour, generous for most jobs and a hard ceiling for a batch that wants to finish in ten minutes. Serper publishes neither term publicly, so ask.

Then there is vendor risk, and here both have something to declare.

Serper's public footprint is thin. Our directory entry notes there is little public information on the company's background or funding, so a buyer weighing long-term stability has the product to go on and not much else. For a $200-a-month line item that is fine. For a pipeline that a revenue product depends on, it is worth asking directly about team size, uptime history and what happens to your contract if the company is acquired.

SearchApi has a live legal question. SerpApi filed a trade-secret lawsuit in 2026 against SearchApi's operator in the US District Court for the Western District of Texas. That is reported from the plaintiff's account, we have not read the docket, and nothing about it has been decided as far as we can tell. On its own it does not disqualify the vendor, but it belongs on the list of questions for a procurement call, and it is one more argument for keeping a second SERP vendor integrated, which is good practice anyway. The same logic applies at the proxy layer, where teams routinely run multi-vendor failover.

Where the alternatives sit

If neither fits, the SERP APIs category has the rest of the field. SerpApi is the longest-established competitor with a similarly broad vertical list. DataForSEO puts SERP data inside a much larger SEO data platform, which suits teams that also want keyword and backlink metrics on the same invoice. Brave Search API is a different proposition again, serving its own index rather than parsing Google.

At the other end, Bright Data and Oxylabs both sell SERP scraping as one product inside an enterprise proxy contract, which is worth considering if you already buy from the proxy networks side and can fold search into an existing commitment. Our Bright Data vs Oxylabs comparison covers that motion. If you are still deciding whether to buy an API at all or run your own collection, choosing web scraping tools and the 2026 stack overview are the wider frame, and why scrapers get blocked explains what you take on when you self-run.

Who each one is wrong for

Serper is wrong for a team whose roadmap includes Amazon prices, Bing rankings, YouTube metadata or Google Flights within the next year. Buying a Google-only API and then buying a second vendor six months later costs more than buying the broad one once, and it doubles the parsing code you maintain. It is also wrong for a procurement process that needs a written rate card before a trial, because on 2026-07-27 there was not one to read.

SearchApi is wrong for a team running tens of millions of plain Google web queries where the per-thousand rate is the entire decision and nothing else on the feature list will ever be called. Paying for 60 engines to use one of them is a real cost at that volume, and a narrower, cheaper vendor is the rational buy. It is also wrong for a buyer who cannot get comfortable with an unresolved legal dispute, however it turns out.

For everyone in between, the spec sheets are close enough that the diff decides it. Two hundred of your own queries, both APIs, a week of runs, and a field-by-field comparison. That costs about a day of someone's time and tells you more than this table did.