Someone on r/SEO asked the question that half the local SEO industry quietly googles every month: "Was wondering is there a tool which allows you to view the SERPs on a per city basis in a given country?" They added the constraint everyone runs into: "VPNs are limited to just a few cities per country." The instinct behind the question is reasonable and also wrong. You do not need an IP in every city to see city-level results. Google will render results for almost any town on earth if you ask in the right way, and the right way is a URL parameter most people have never heard of. What you do need an IP for is narrower, and worth being precise about.
Google builds your location from four signals
Google decides where a search "happens" using the IP's geolocation, an explicit location parameter in the URL, the country and language parameters, and, on mobile, device GPS. That is the whole list. The ccTLD stopped mattering in 2017; google.de and google.com serve the same thing, based on where Google thinks you are, not which domain you typed. On a phone with location permission granted, GPS wins. On a desktop with a bare query, the IP wins. And when the URL carries an explicit location parameter, that parameter sets the location for the render, with the IP still hanging around in the background as a trust signal.
Those four signals are not equal, and they answer different questions. Which is why "get an IP there" and "set a parameter" are both correct answers, to different problems.
The uule parameter tells Google to render results as if you were standing somewhere
The uule parameter carries an encoded canonical place name, and Google renders the results page as if you were in that place. This is the mechanism behind every local rank tracker on the market, and almost nobody explains it.
The encoding is simple. Take a canonical location name from Google's geotargets list (the CSV Google publishes for Ads targeting, each row a place with an ID and a canonical name). Base64 it. Prepend a single character that encodes the name's length, then the fixed prefix w+CAIQICI. For "Chicago,Illinois,United States" (30 characters, length character e) you get:
https://www.google.com/search?q=emergency+plumber&hl=en&gl=us&uule=w+CAIQICIeQ2hpY2FnbyxJbGxpbm9pcyxVbml0ZWQgU3RhdGVz
Open that from anywhere and Google renders the plumber results, local pack included, for Chicago. Swap the base64 for "New York,New York,United States" (31 characters, so the length character becomes f) and you are in Manhattan. No VPN. No Chicago IP. The distance component of local-pack ranking runs off the location Google believes for that render, and uule is what sets it.
This also answers the r/SEO thread asking how local SEO services run "granular gps searches" across a whole metro grid. They do not own an IP in every zip code. They fire the same query through a grid of uule values, one per coordinate cell, through IPs that merely sit in the right country. The per-city layer is parameters. The per-country layer is IPs.
gl and hl set the frame around it
Two more parameters matter: gl picks the country edition of the results and hl picks the interface language. They are cheap levers and worth setting explicitly on every check, because otherwise Google infers both from the IP and your session, and your data stops being comparable from one run to the next.
The parameter stops working when the real IP starts to matter
For organic rank checks, uule plus a country-appropriate IP is enough; for ad testing and country-accurate SERP features, the real IP starts to carry weight. This is the line most people asking "which VPN for checking foreign SERPs" actually need drawn for them.
An r/PPC thread asked for proxy services "for testing searches in other countries (aside from ad preview and diagnosis tool)", and the parenthetical is telling. Google Ads ships a preview tool precisely because previewing ads properly is hard: ad serving weighs the searcher's real signals, including the IP, harder than an organic render does. The preview tool shows whether your ad would appear for a location without burning impressions. What it cannot show is the live page a real user sees, with competitors' ads, extensions, and the surrounding SERP. For that you need to actually be there, which means an IP in that country.
The IP country also decides things no parameter overrides. Google serves EU users a consent screen before anything else. Currency, shopping results, and some result formats follow the IP country. And gl=us from a German IP is a halfway state Google has no reason to honor cleanly: you get a US-flavored render assembled for a session it still knows is in Germany. Fine for a quick look. Not something to build a dataset on. For country-accurate results, use an IP in the country and let uule handle the city on top. BirdProxies residential proxies target at country level, rotating or sticky, which covers exactly this layer; a few residential pools on the market sell city or state IP targeting, but for rank checks you rarely need it, because uule already is the city layer.
Checking at scale is a scraping job, whatever you call it
One check in a browser is trivial, and ten thousand checks a day is a scraping operation with everything that implies. An r/GrowthHacking poster who tried to build an in-house SERP tool summarized the usual first attempt: "I tried using selenium and a bunch of free proxies, But it didn't work well. I was blocked by Google." Of course it didn't. Google blocks aggressively, the results HTML shifts under your parser without notice, and success rates vary by locale and query type, which is why an r/SEO thread about tracking roughly 15k keywords across 8 locales turned into a debate about how to even measure ROI when completion rates wobble.
The same applies to jobs people do not think of as scraping. Checking whether 20,000 URLs are indexed means 20,000 site: queries against the most defended search engine on the planet. That is a scraping pipeline. Whether you should build that pipeline yourself or pay an API to run it is a separate question, and we already wrote it up honestly in DIY proxy stack vs a managed scraping API, so this post will not re-answer it.
One thing said plainly, once: scraping Google's results violates Google's terms of service. The entire rank-tracking industry does it at scale anyway, and every tool you have ever paid for SERP data was built on it, but you should know what you are signing up for.
A captcha does not prove your IP is burned
Google captchas hit people on clean home connections too, so a challenge on its own tells you less than you think. A recent r/proxies thread described constant Google captchas with a notable detail: "Currently not using any proxy. Using my own Internet service provider's IP." Browser fingerprints, automation signals, unusual extensions, aggressive privacy settings, and neighbors behind the same carrier-grade NAT all trigger challenges independently of IP reputation. When your checks start failing, rotating IPs is one lever. It is not the only one. If a fresh residential IP still gets challenged instantly, look at what your browser or script is broadcasting before blaming the address.
Which setup you actually need
Match the tool to the question, because most location checks need less infrastructure than people assume. Checking organic rank in another city of your own country: uule, no proxy required. Building comparable rank data across cities: uule plus a stable country-appropriate IP, so the trust signal stays constant. Checking another country's organic results: an IP in that country, with gl, hl and uule set explicitly. Testing live ads abroad: an in-country IP, full stop, with the Ads preview tool as the free cross-check. And anything past a handful of daily checks: treat it as scraping, budget for blocks, and read the build-vs-buy post before you write the first line of Selenium.