Collecting Localized SERPs: Country, City, Language and Device Targeting

Send location=London to SearchApi and its own documentation tells you what comes back: London TV Region,England,United Kingdom. Not the City of London, not the borough your client's shop sits in, and not what the word London means in the report you are about to send them. Run the same keyword through a vendor that geolocates by proxy exit instead and you get a different top ten with no obvious explanation for the gap.

The two APIs were not running the same search. One geolocated by proxy exit, one forwarded a parameter to Google, one resolved a canonical location and encoded it into uule. All three are defensible readings of "search from the United Kingdom" and no two of them return the same SERP. If you are buying from the SERP API category, the location model matters more than the engine list: it decides whether your rank data is reproducible, and whether a vendor migration silently shifts every position in your database.

All parameter details below were read from vendor documentation on 27 July 2026. These surfaces move, so read the current docs before you build against them.

Three ways a SERP API decides where you are

Proxy exit geolocation

The oldest mechanism. The vendor routes your request through an IP address physically in the target market and lets Google infer the location the way it would for any real user. Nothing in the query says London. The request simply arrives from London.

This is what you get by default when the SERP product sits on top of a proxy platform. It is also what you are doing implicitly if you build your own search collection on a residential proxy pool instead of buying a SERP product. The strength is fidelity: it is the closest thing to a real user in that market. The weakness is that it is not auditable. You cannot store the location you asked for, because you did not ask for a location, you asked for an IP. Sub-country control depends entirely on how deep your provider's pool runs in that city, and pool composition changes week to week. The guide on residential proxy IP sourcing covers how those pools get assembled and why their geography is less stable than a coverage map suggests.

Parameter pass-through

The vendor accepts Google's own localization parameters and forwards them. Three matter. gl is the country of the search. hl is the interface language. lr restricts results to documents in one or more languages, using the lang_{two-letter code} form, and SearchApi documents combinations such as lang_it|lang_de.

Pass-through is thin by design, and that is the appeal. There is no vendor-side resolution step to reason about, no location database to fall out of date, and the request stays small. It is the right model when you genuinely need country-level results and nothing finer.

The limitation is that gl is a ranking bias, not a physical position. It tells Google which country to favor; it leaves the searcher's location unset. SerpApi's documentation makes the split explicit and then goes further, recommending that you specify location at the city level in order to simulate a real user's search. If your keywords carry any local intent, gl alone will underserve them.

Canonical location resolution

The vendor takes a human-readable location string, matches it against a database of Google geo targets, and turns the match into something Google understands, in practice the uule parameter.

SerpApi exposes both. Its location parameter "defines from where you want the search to originate. If several locations match the location requested, we'll pick the most popular one," and uule is "the Google encoded location you want to use for the search." The two cannot be combined: location "can't be used together with uule, lat, and lon parameters." A Locations API sits behind it for exact targeting.

SearchApi implements the same model and documents the hazard more plainly than anyone else. Its docs state that uule and location cannot be used at the same time, that "if multiple locations match your input, the most popular one will be selected," and then give the example that location=London resolves to London TV Region,England,United Kingdom. A TV region is not the City of London, and it is not what your client means when they say London. If you pass bare city names, you are accepting whatever the resolver picked.

DataForSEO makes the same idea numeric. Its SERP endpoints take a location_code ("search engine location code"), a location_name ("full name of search engine location") or a location_coordinate ("GPS coordinates of a location"), and require exactly one of the three. Language is set separately through language_code or language_name.

Bright Data sits across two mechanisms. Its SERP API runs on the same platform as the rest of its network, so exit geography is part of the picture, but its docs also expose gl ("two-letter country code used to define the country of search"), hl ("two-letter language code used to define the page languages") and uule, including a coordinate form written as uule=lat,lon,radius.

Canonical resolution is the only mechanism of the three that produces an auditable record. You stored a code or a canonical name, the vendor stored the same thing, and next year you can prove which search you ran. If anyone downstream might dispute a number, this is the mechanism you want.

What each vendor documents

Half that table is unverified, and saying so beats filling it with plausible parameter names. Four of the nine publish parameter documentation readable without an account, and those four are the only ones whose behavior is described here as fact. For the rest, the row is a research task.

The gaps are themselves informative. The standalone documentation domains for both Value SERP and Scale SERP now issue 301 redirects to Traject Data product pages rather than serving docs, an artifact of the ownership chain that ends, per the banner and footer on those pages, at ScraperAPI. Scale SERP's product page points to docs.trajectdata.com/scaleserp. Read the current docs at the new host before you build, because the surface documented under the old domain is no longer the one being served.

Two structural points fall out of the confirmed rows. Free-text and canonical vendors are not substitutes: sending "London" to each produces one search against whatever the resolver guessed and one against a specific Google geo target. And only DataForSEO and Bright Data document coordinates as a first-class input, which constrains anyone planning grid-based local tracking.

Country codes are not locations

The most expensive misunderstanding in this space is reading gl=gb as "search from Britain." It is a bias applied to ranking with the physical location left unset. Any query a searcher would expect a map pack for will return a materially different result set with and without a city-level location, even when gl is identical.

This breaks vendor comparisons. Hand two SERP APIs a country code and you are not comparing vendors, you are comparing two different searches and blaming the difference on the wrong thing. Give both the same city-level canonical location, or accept that the exercise cannot be interpreted. The same discipline applies to reading anyone else's SERP API comparison: if the methodology does not state the location granularity, it is not measuring what it claims to measure. The guide on reading scraping benchmarks covers the wider version of that problem.

It also breaks migrations. Move from a pass-through vendor to a canonical vendor without changing the location values in your job definitions and positions will shift across the whole dataset. The shift looks like a ranking change and is actually an instrumentation change. Run both vendors in parallel for two weeks on the same keywords and the same locations, diff the output, and only then cut over.

City, coordinate and the postcode question

Google's geo target hierarchy runs roughly country, region or state, metro, city, and in some markets a district or a TV region. Canonical location APIs expose most of it. SerpApi's guidance is to go to city level rather than leaving searches national, on the reasoning that every real user has a physical location and Google will infer one whether or not you set it.

Postcodes are where expectations outrun the platform. Google does not expose a postcode parameter, so a vendor advertising zip-level targeting is resolving that postcode to a canonical location or to coordinates on your behalf. Scale SERP's product page, read on 27 July 2026, says: "With Scale SERP you can choose to receive data from any geographic location, down to zip/postal code level, for any device including desktop, mobile, and tablets." That may well hold in practice. It is still a vendor claim about a resolution step you cannot inspect, so verify it against a reference capture before you report on it.

Coordinates are the honest route to sub-city precision, and they are what serious local rank tracking uses anyway. DataForSEO's location_coordinate takes latitude,longitude,radius, and the radius term is the part people miss: it is a search area, not a pin, and two grids built at different radii are not comparable. Bright Data's uule=lat,lon,radius form carries the same three components.

Coordinate grids are the right tool for measuring how visibility decays across a service area and the wrong tool for a national keyword report, because a seven by seven grid multiplies your request count by forty-nine and every point bills separately. Model that before you commit; the guide on credit-based scraping API pricing covers how per-request billing compounds when one tracked keyword becomes fifty requests.

Language is a separate axis from country

Country and language get conflated because they usually correlate. They stop correlating precisely where the interesting markets are: Canada, Belgium, Switzerland, Catalonia, Quebec, and anywhere with a large second-language population.

Three levers, and the vendors expose them inconsistently:

• gl biases ranking toward a country. SearchApi documents its default as us.
• hl sets the interface language. SearchApi documents its default as en.
• lr restricts results to documents in given languages, in the lang_it|lang_de form. SerpApi and SearchApi both document it. Several vendors do not expose it at all, so check before you design a workflow around it.

Two defaults, both silently applied, are enough to make an unconfigured request a US English search regardless of what your job description says it is.

The subtler trap is convenience behavior, where selecting a location automatically rewrites the Google domain, the country and the language to match it. Set a Paris location and get French results on a French domain. That is correct for measuring what a Parisian sees and wrong for measuring what an English-speaking traveler in Paris sees, and the second is a real commercial question for travel, hospitality and expatriate services. If your vendor offers that derivation, find the switch that disables it and set all three values by hand for every multilingual market. I could not re-verify which of the Traject Data products still ship that behavior, because their documentation moved hosts; read the current docs before assuming either way.

Device is a third axis

Mobile and desktop are separate requests, and every vendor that supports device targeting exposes it as its own parameter. SerpApi and SearchApi both document desktop, tablet and mobile. DataForSEO takes a device field of desktop or mobile plus an os field. Bright Data implements it as brd_mobile, where the default or brd_mobile=0 "will provide random desktop user-agent while brd_mobile=1 will provide random mobile user-agent," with further values for iOS, iPad, Android phones and Android tablets.

Note what that wording implies. On Bright Data the device axis is a user-agent representation, which is not the same implementation as rendering a mobile viewport. Both are legitimate, but they are not equivalent. If your parsing depends on mobile layout rather than mobile ranking, the difference will show up in your data.

Two rules regardless of vendor. Never average a desktop and a mobile position into a single reported number, because they measure different things and the average describes neither. And when you add mobile coverage, budget for parser work as well as request volume, since mobile SERPs lay out local packs, carousels and other features differently. That is a parsing change, not a parameter change.

The google.com consolidation

Older localization advice leans on the Google domain: google.co.uk for the UK, google.de for Germany. That lever is gone, and the vendor documentation is where you can see it most clearly.

SearchApi's docs mark google_domain deprecated as of 15 April 2025, when Google phased out country code domains. Bright Data's SERP API docs put it more fully: "Google now serves all search results exclusively through google.com and as such, any SERP API request sent to a different Google TLD (e.g., google.co.uk, google.ca) will automatically be routed through google.com." The same page states that "localization is no longer determined by the TLD and should instead be configured solely using the gl (country) and hl (language) query parameters."

SerpApi still documents google_domain, noting it defaults to google.com. Accepting the parameter and having it change anything are different claims, and only the first is documented. So set it if you like, but do not treat it as your localization mechanism, and do not read a change in results after a domain switch as evidence of anything.

The audit that follows from this is concrete. If you have collection jobs whose only geographic signal is a ccTLD, those jobs are now effectively unlocalized and have been for over a year. They will not error. They will just quietly return something closer to a default search. Grep your job definitions for domain-only geo configuration before your next reporting cycle.

A verification routine you can run yourself

Do not trust the parameter you sent. Verify from the payload. None of this needs a paid plan or a benchmark; it runs on free tiers.

1. Establish a reference. Pick three or four queries per target market: one with obvious local intent that should trigger a map pack, one commercial query that should surface shopping results or ads, and one informational query. Get a ground-truth capture from someone actually in that market, on an ordinary device, not through a VPN. This step costs a favor rather than a credit, and it is the step teams skip.

2. Check the local pack. For the local-intent query, confirm a pack is present and that the businesses in it are physically in the target city. A pack full of capital-city businesses when you asked for a regional city is the clearest possible sign your location did not take.

3. Check currency and units. Shopping results, product panels and rich results carry currency symbols and unit conventions. Wrong currency means the request resolved somewhere else.

4. Check the interface language strings. The result count line, pagination labels, footer and did-you-mean prompt are all translated. Set hl=de, get English chrome, and hl was ignored or overwritten. This is the fastest way to catch auto-derivation behavior.

5. Diff the top ten against the reference. Compute overlap between your URLs and your ground-truth contact's. Perfect agreement never happens, because personalization and time of day both move results. What you want is a stable overlap you can characterize for your own setup, so that a sudden drop becomes a signal. Set the threshold from your own observed baseline, not from a figure someone published.

6. Compare the three mechanisms deliberately. Where a vendor supports it, run one keyword three ways: country code only, canonical city location, and coordinates. The spread between those three is the size of the error you are exposed to if a job definition ever loses its location value. That number is more useful than any vendor comparison.

7. Store the echo, not the input. Persist what the response says about how the request was executed. DataForSEO returns location_code and language_code in its result data; SerpApi returns a search parameters block. Storing the echo rather than your own request means that when a number looks wrong in six months you can tell whether the vendor did what you asked.

Run this on a schedule, not once at integration. Location databases get revised, vendor defaults change, documentation hosts move, and Google's own handling shifts, as the ccTLD consolidation showed. A quarterly re-run of steps two through five on a fixed keyword set catches drift long before a client does.

Choosing, with the failure cases named

SerpApi is the sensible default when auditability matters and volumes are moderate. Canonical location plus raw uule, a Locations API for exact targeting, gl/hl/lr all documented, three device values, and explicit guidance to work at city level. It is wrong for coordinate grid work, because location cannot be combined with uule, lat or lon, so the coordinate path is yours to build and the per-search cost of a forty-nine point grid is yours to absorb.

SearchApi sits close to SerpApi in model and documents the sharp edges better than anyone else in the category, including the mutual exclusivity of location and uule, the most-popular-match resolution, and the London TV Region example. That documented resolution behavior is itself the reason it is wrong for passing bare city names: resolve through the Locations API and store the full canonical string, or you are recording a guess. Note also that SearchApi's operator is contesting a 2026 trade-secret lawsuit filed by SerpApi in the US District Court for the Western District of Texas, a dispute known so far only from the plaintiff's account. Nothing is settled and nothing about the product's location model depends on it, but a procurement team should know it exists.

DataForSEO is the pick for grid-based local tracking and for teams that want numeric location codes rather than strings. Native location_coordinate with a radius term, location_name and location_code alternatives, separate device and os fields, and location and language echoed back in the result. It is wrong for anyone who wants a readable one-line GET, because the code model adds a lookup step and the task-style request bodies are heavier than a query string. It is also a broader SEO data platform than a pure SERP API, which is either a consolidation win or scope you are paying to ignore.

Bright Data makes sense when you already hold a contract on its platform and want SERP collection under the same billing as your proxy network. Its docs are also the clearest published statement of the google.com consolidation, which says something useful about how closely it tracks Google's behavior. It is wrong for a small team with no existing relationship: the zone-and-credential setup is heavier than one API key, the commercial motion is enterprise, and the device axis is expressed as user-agent representation rather than a rendered mobile viewport. If you are weighing the platform vendors against each other, the Bright Data vs Oxylabs comparison covers that ground.

Serper is positioned as the thin, fast, Google-focused option and is widely used as the search tool inside agent frameworks, a profile that suits country-level collection at volume. Its documented parameter surface could not be verified for this guide, because the playground sits behind a consent wall. Treat its geographic granularity as unconfirmed and test it before using it for local SEO work.

Scale SERP advertises the deepest granularity in this group, down to zip and postal code, along with desktop, mobile and tablet. If that claim holds it is a strong fit for local rank tracking. The caveat is continuity rather than capability: the product now sits under Traject Data inside ScraperAPI, its old documentation domain redirects to a marketing page, and its parameter surface should be read at the current docs host before you build. That makes it wrong for a team that needs stable, citable documentation today.

Value SERP is the sibling product and carries the same continuity caveat with less publicly visible detail. Its standalone docs domain also redirects. Do not build a rank tracker against it without first confirming, in the current documentation, how it resolves a location string and whether it derives country and language from that string.

Zenserp covers Google, Bing, Yandex and YouTube with geolocation targeting and a batch endpoint, which fits teams that need more than Google. I could not confirm its location parameter names or its granularity, so it is wrong, on present evidence, for reporting that needs an auditable canonical identifier. If the only record of what you asked for is a free-text string you sent, you do not have an audit trail.

SERPHouse advertises geo-targeting across more than 245 countries with desktop and mobile targeting, dedicated News, Images, Shopping and Local endpoints, and pay-on-success billing aimed at SEO suites running large keyword sets. Those figures come from its own site with no independent verification. The volume orientation also makes it a poor fit for a one-off research project where you want a handful of searches and no scheduling model to learn.

Four decisions to make before you build

Decide your granularity floor and apply it everywhere. If any part of your product reports local rankings, set city-level locations on every job, including the national ones, so the dataset is internally consistent.

Settle whether country and language are ever allowed to move together. If you touch even one multilingual market, the answer is no, and every auto-derivation feature your vendor offers should be switched off.

Work out what you persist. Store the vendor's echoed execution parameters alongside your own request, and record the canonical location identifier rather than the human string you typed.

Pick a re-verification cadence. Quarterly is enough for most teams. Zero is what most teams actually run, which is why a documented change to Google's domain handling can sit in a pipeline for a year before anyone notices.

None of this is exotic, and none of it errors when you skip it. That is the awkward part: an unlocalized job returns a perfectly valid response, so you find out months later, when someone asks a question the data cannot answer. If you are still assembling the layers underneath, the tool selection guide and the 2026 scraping stack overview cover the rest of the stack.