SERP API Coverage by Vertical: News, Maps, Shopping, Scholar and Jobs

If you need Google News, Maps and Shopping from one vendor and one API key, the shortlist is genuinely short. As of July 2026, SerpApi and SearchApi.io are the two that publish endpoints for all three, plus Scholar, Jobs, Images, AI Overview and AI Mode. Serper.dev covers News, Maps, Places, Shopping and Scholar at a lower price but lists no Jobs endpoint. DataForSEO covers Maps, Local Finder, News, Events, Images, Jobs and AI Mode on its SERP product, with Shopping and Scholar absent from that list.

Coverage is the first filter because it is binary. A vendor that has no Maps endpoint cannot return business hours at any price, and no volume discount fixes that. Price differences within this category are real but bounded: ScrapingDog's own published tiers span roughly 3.4x from Lite to Premium. Coverage differences are pass or fail.

Most published comparisons in this space are organized one page per vertical, which is the right shape for someone who already knows they need Google Maps data and is choosing a scraper for it. Someone choosing a single vendor to ground an AI product needs the transpose: one row per vendor, one column per vertical. That table is below, along with what each cell actually means, because "supports Google News" turns out to describe three different things.

Why vertical coverage eliminates vendors faster than price does

The workaround for missing coverage is expensive in ways that do not appear on a pricing page. You either add a second vendor, which means a second contract, a second authentication path, a second rate-limit budget, a second payload schema to normalize and a second thing that can page you at 3am, or you build the vertical yourself and inherit the anti-bot maintenance that you bought a SERP API to avoid.

There is a second reason to lead with coverage. Per-request price is the number vendors compete on hardest, which means it converges. Vertical coverage does not converge, because each vertical is a separate parser against a separate Google surface with its own layout churn. Vendors add verticals when the demand justifies the maintenance, and they quietly stop updating the ones that do not pay. The coverage list is therefore a better signal of where a vendor is investing than its price is.

Price still matters, and it matters most once two or three vendors survive the coverage filter. For the normalized per-thousand comparison across this category, see the cheapest SERP API guide. Run coverage first, price second.

The coverage matrix

Every cell below was read off the vendor's own endpoint index in July 2026, not off a marketing page. The last column says where, so you can re-run the check yourself when this snapshot ages.

Two cautions about reading this table. ScrapingDog's row says "not on that page" rather than "no", because its Google Search API page lists dedicated APIs for Scholar, Images and Lens and sells other targets as separate scraper products; check its product index, not its search API page, before ruling it out. DataForSEO's absent Shopping and Scholar cells mean absent from the SERP endpoint list specifically, which is where organic, Maps, News, Jobs and AI Mode live; DataForSEO sells a wide catalogue beyond SERP, so the right question there is which product line a vertical sits in and how it is billed.

Beyond those five, the directory carries several vendors whose coverage I could not confirm from a single documentation index inside a reasonable check, and I would rather say so than guess. ValueSERP expresses coverage through a search type parameter on one endpoint rather than through separate endpoints, so the list you need is the set of values that parameter accepts; its distinguishing feature is batch, with jobs of up to 15,000 requests. HasData is wired into Zapier and Make, which points at no-code pipelines rather than agent-latency workloads. Zenserp ships image and reverse image search as a first-class feature. ScrapeOps is a proxy aggregator with monitoring rather than a per-vertical parser, so you get the page and you own the parsing, which is a different trade entirely.

Two more sit outside the Google frame. Brave Search API queries Brave's own index and returns Brave's own result types, so "vertical coverage" there means web, news, images, videos and local rather than any Google surface, with some result types gated behind paid plans. Yandex Search API is the equivalent for the Yandex index, relevant if your users are in Russia or the CIS and irrelevant otherwise. Both carry a different risk profile than the Google-derived vendors, which matters for the reasons in the litigation section below.

The verticals that matter for grounding

News. The vertical where recency is the entire product. You want publisher name, publication timestamp and a canonical link, because a grounded answer about a current event is only as good as its ability to say when the claim was true. SearchApi.io splits this three ways, with a lighter payload variant and a publisher-portal variant alongside the standard news engine.

Maps and local. The payload diverges furthest from organic results: coordinates, opening hours, price level, rating, review count, category. It is also the vertical where "supports Maps" hides the most, because place details, reviews, photos and directions are separate calls at the vendors that model them properly. If your feature answers "is it open now", a Maps search endpoint alone will not get you there.

Shopping. Price, merchant, availability and product identifiers, all of which change intraday and vary by location. This is the vertical where a cached response does the most damage, because a stale price reads as a confident, specific, wrong answer rather than as a gap.

Scholar. Citation counts, authors, venue and PDF links, updated on Google's own unhurried schedule. Low churn makes it the easiest vertical to cache aggressively and the cheapest to run at volume, which is why it survives on vendors that have pruned everything else, ScrapingDog included.

Jobs. Google Jobs is an aggregation surface rather than a standalone index, and it is the vertical most often missing. It is also the one where expiry, not staleness, is the failure mode: a posting that closed yesterday looks exactly like a live one in a payload you fetched last week.

Images. Not decorative once your model is multimodal. Reverse image lookup and Lens-style endpoints are the entry points for provenance checks, and coverage here is uneven; Zenserp and ScrapingDog both single it out, which suggests it is not table stakes.

What "supports Google News" can mean

Three different implementations hide behind the same claim, and they are not interchangeable.

A parsed vertical endpoint. A separate engine with its own typed schema, its own parameters and its own pagination. SearchApi.io's google_news engine and SerpApi's News API are this shape. You get fields the organic parser does not produce, and you get them consistently.

A filter on the organic endpoint. One parser, one schema, a parameter that narrows the result set. Cheaper for the vendor to maintain and usually cheaper for you, but you typically get fewer typed fields, because the organic parser was not written to model a news item.

A block inside the organic payload. The "top stories" carousel that Google injects into a normal results page, surfaced as a nested object. You get three to five items with no pagination and no guarantee the block appears at all, because its presence is query-dependent.

A vendor can accurately say it supports Google News while shipping the third shape. Before you commit, ask which one you are buying and ask for a sample payload for a query you actually care about, in the locale you actually serve. The same test applies to Maps: if reviews are a separate call, "supports Google Maps" answers a question you did not ask.

Locale, language and device parameters that silently change results

The defaults are gl=us and hl=en almost everywhere. A product serving Germany that never sets those parameters is grounding every answer on United States results, and the symptom looks like a model problem rather than a data problem, which is why it survives so long in production.

The parameter set is broadly consistent across vendors. SearchApi.io documents location for a named place, gl for country, hl for interface language, uule for Google's encoded location value, google_domain for the property, and device for desktop, mobile or tablet. It also exposes nfpr to suppress auto-correction and verbatim to force exact matching, both of which matter for grounding, because you usually want results for the query you sent rather than for Google's guess at what the user meant. SerpApi's AI Mode endpoint takes the same locale set, which tells you these parameters are treated as first-class rather than as an organic-only concern.

Two failure modes are worth designing against. First, named location strings are resolved by the vendor against its own location database, and granularity differs: country-level for some vendors, city or postal for others. A location string that silently resolves to a country centroid produces plausible, useless local results. Second, device changes the SERP itself rather than the rendering of it: mobile carries different local packs and more AI surfaces, so a desktop-defaulted pipeline will under-report AI Overview presence.

The operational fix is unglamorous. Set gl, hl, location and device explicitly on every call, never rely on a default, and log the full parameter set alongside the response. Without that log, a support ticket about a wrong answer gives you no way to tell whether the model reasoned badly or whether the call quietly ran against gl=us.

AI Overviews and AI Mode: what is available and from whom

SerpApi ships both surfaces. Its AI Mode API returns typed text_blocks covering paragraphs, headings, lists and tables, a references array with title, link, snippet and source for each citation, and search_metadata, with optional local_results, inline_videos and products. SerpApi describes the underlying surface as powered by Gemini 2.5 and notes that AI Mode responses run longer and more detailed than AI Overviews. SearchApi.io lists google_ai_overview and google_ai_mode among its engines. DataForSEO has an AI Mode endpoint and reaches AI Overview through a load_async_ai_overview parameter that is billed on top of the base rate. Serper.dev does not list either surface publicly as of July 2026.

The name of that DataForSEO parameter, load_async_ai_overview, explains the surcharge. AI Overview is loaded asynchronously by Google after the initial response, which is why fetching it costs extra: the vendor has to do more work than a single request. It also explains why AI Overview coverage is patchier and pricier than organic coverage everywhere, and why absence in a payload is not evidence of absence on Google.

These are the least stable endpoints you can buy. SerpApi's own documentation for the AI Mode API warns that Google frequently experiments with the layout, requiring ongoing parser updates, and that the surface carries aggressive anti-bot measures and rate limits. Build against them with the expectation that the schema will move.

There is also a design question underneath the availability question. Grounding your model on Google's model output means inheriting another system's summarisation and its errors, with no way to audit either. If you need defensible citations, take the references array and fetch the sources yourself rather than passing the summary through as fact. AI Mode coverage is most useful as a signal of what Google is showing users, which is a competitive-intelligence use case, not a truth source.

Freshness and update cadence, vertical by vertical

These APIs are mostly pull-through rather than cached indexes: your request triggers a fetch. Freshness is therefore two questions stacked. How current is what Google is showing, and what does your vendor and your own cache do on top of that.

The right TTL is per vertical, not global. News wants minutes, and it is the vertical where a stale response is most obviously wrong. Shopping wants minutes to hours and should be treated as a quote at a timestamp rather than as a price, because merchant, location and session all move it. Maps and local tolerate days for hours and ratings, though review counts drift faster. Scholar tolerates weeks, since citation counts update on Google's schedule. Jobs is the awkward one: the content is stable but the posting's existence is not, so expiry checks matter more than refresh intervals.

Ask every vendor two questions before you model unit costs: do you cache, and am I billed for a cached hit. The answers differ across this category, and for a workload with high query repetition the answer changes the economics more than the headline per-thousand rate does.

Rate limits, batch endpoints and async jobs

Vendors handle volume in three shapes, and the shape you need follows from where the request sits in your architecture.

Synchronous. One request, one response, concurrency capped per plan. You own retries and backoff. This is the only shape that works when a user is waiting inside an agent turn.

Batch. You submit a set and collect results later. ValueSERP's batches take up to 15,000 requests, which is well suited to a scheduled backfill and useless for anything interactive.

Task queue. DataForSEO's Standard method is a POST to enqueue and a GET to collect, with normal and high priority tiers, and up to 100 tasks per POST. Its Live method returns in one call and costs more. Picking between them is a latency-versus-unit-cost decision, and it is worth making it per feature rather than per account.

DataForSEO also illustrates a billing pattern worth checking for at every vendor: the sticker rate is a floor. Parameters including calculate_rectangles, load_async_ai_overview, search operators such as site: or filetype:, and elevated depth values all multiply the final cost. Budget from a representative call with the parameters you will actually send, not from the number on the pricing page.

For payload inspection before any of this matters, Serper.dev's 2,500 free queries with no card is the lowest-friction way to see what the JSON actually looks like. For the head-to-head on that vendor against the coverage leader, see SerpApi vs Serper.dev.

Vendor risk and continuity after the July 2026 SerpApi ruling

On 20 July 2026 the United States District Court for the Northern District of California ruled on Google's suit against SerpApi. Search Engine Land reported that the court dismissed Google's two DMCA claims, permanently as to search results containing no copyrighted content and with leave to amend as to results that do, finding that Google had not alleged facts showing that SearchGuard was implemented "with the authority of the copyright owner." The same reporting states that the court upheld Google's standing under the DMCA, left the circumvention allegation alive, gave Google 21 days to file an amended complaint, and kept discovery stayed pending resolution of any amended complaint and subsequent motions.

Read that carefully before you draw a conclusion from it. This is a ruling on whether Google's pleadings were sufficient, not a merits judgment, and not a holding that scraping search results is lawful. The case is live and the deadline for an amended complaint falls in August 2026. Nothing about the legal status of Google-derived SERP data is settled.

The buyer implication is about diversification rather than about SerpApi specifically. Every vendor whose data derives from Google's SERP is exposed to the same underlying question, so treating this as one vendor's problem misreads it. The defensible response is to normalize each vendor's payload into your own schema at the boundary, so that swapping vendors is a configuration change rather than a rewrite. Lock-in accumulates fastest in exactly the verticals where schemas diverge most: Maps place details and Shopping offers, where SearchApi.io's four-call decomposition has no direct equivalent at a vendor that returns one flat object.

The vendors running their own index rather than parsing Google's, Brave and Yandex among them, sit outside this particular exposure. They also sit outside Google's result set, which is usually the reason you were buying a SERP API in the first place. That is a genuine trade, not a free hedge. None of this is legal advice; if the outcome bears on your roadmap, ask counsel.

How to verify each cell yourself

Coverage lists change, and this one is a snapshot dated July 2026. Five checks, in order.

Read the endpoint index, not the marketing page. SerpApi's search-api page, SearchApi.io's Google docs index and DataForSEO's SERP overview each enumerate what exists. Marketing pages enumerate what sells, which is a smaller and differently shaped set.

Establish which of the three response shapes you get. A dedicated engine, a filter on organic, or a block inside the organic payload. Ask directly and get a sample payload for a query you care about.

Diff two vendors on an identical call. Same query, same gl, hl, location and device, then compare the JSON field by field. Field-level coverage gaps that no documentation mentions surface within minutes.

Price a representative call, not the headline rate. Include every billed parameter you intend to send. On DataForSEO in particular the multipliers are the difference between a plausible budget and a surprise.

Re-check quarterly. Verticals get added, Google reshapes its surfaces, and AI Mode endpoints in particular are being maintained against a moving target by every vendor selling one.

The short version: decide which verticals your product cannot ship without, cut every vendor that lacks one, and only then open the pricing pages. If the answer includes Jobs, you are choosing among SerpApi, SearchApi.io and DataForSEO. If it includes Shopping and Scholar together, DataForSEO's SERP list drops out. If it is News, Maps and Shopping only, Serper.dev is the cheapest vendor that documents all three. And whatever you pick, write the boundary layer that lets you replace it, because the litigation calendar in this category runs longer than most product roadmaps.