SEO & SERP · Local rank tracking
Local rank tracking by city, from exits in that city
Local results depend on where the searcher is, so a ranking checked from your office describes your office. Run the same queries from exits in each metro you compete in, and see the local pack a searcher in Leeds, Lyon or Dallas is shown — at city level, which is what an exit IP can honestly give you.
Pay per GB · No subscription · Prices in EUR, excl. VAT
- €0.75
- per GB on ARC Basic, excl. VAT
- −21%
- at 1 TB (€0.59 / GB)
- 185+
- countries, city targeting
- Never
- expires — no subscription
Written for
- Local SEO agencies
- Multi-location brand marketers
- Franchise marketing teams
- Rank-tracking tool developers
The short answer
- Google says local results are based mainly on relevance, distance and prominence — and that when a searcher does not share a location, it uses what it knows about it. An IP address is one of those signals.
- An exit IP gives a general-area view: our city targeting covers a fixed list of metros per country. It does not give ZIP-code or street-level precision, and nothing about an IP can.
- Track two query types separately: implicit queries ("dentist"), where the exit's city decides the local pack, and explicit ones ("dentist Leeds"), where the query does.
- Search result pages are strict; residential exits on ARC Fast with city targeting are the default for this work.
The problem
What goes wrong without the right IPs
Every city reports the office's ranking
Run implicit local queries from one location and every client city in your report shows the local pack around your office. The numbers are precise and describe the wrong place.
Expecting street-level precision from an IP
A city-targeted exit is somewhere in or around that metro, and IP geolocation itself is approximate. Grid rankings for a single neighbourhood need a precise searcher location, which an IP address does not carry.
Personalisation leaks into the result
Signed-in history, saved places and earlier searches all shape local results. A rank check that carries cookies from the last check is measuring itself.
Local and organic are different lists
The map pack and the organic results below it rank different things by different rules. A report that blends them hides the movement your client asked about.
Daily checks from one IP get throttled
Hundreds of keywords across ten cities every day is a pattern no single address can carry. Throttled runs leave gaps exactly on the days you most need data.
What to collect
What you can collect
- Query, query type and city
- Implicit versus explicit-location queries behave differently; store which one each row is.
- Exit country and city
- The location you asked for — and, ideally, the location the page itself says it used.
- Local pack positions
- Business name, position and rating for each entry in the map pack.
- Organic positions
- The classic ranking below the pack, tracked as a separate list.
- Business profile rating and review count
- Part of what Google calls prominence; collected from the pack itself.
- SERP features present
- Ads, local services units and other modules push the pack down the page.
- Device type
- Mobile and desktop layouts differ; a mobile pack can show fewer entries above the fold.
- Timestamp
- Local rankings fluctuate day to day; trends only appear across dated runs.
How it runs
How a collection run works
- 01
Map each location to a metro you can target
For each client location, pick the nearest metro on our list — for example London, Manchester, Birmingham or Leeds in the UK; Berlin, Munich, Frankfurt, Cologne or Hamburg in Germany; New York, Los Angeles, Chicago, Miami, Dallas or Seattle in the US. Locations far from a listed metro get country-level checks and explicit-location queries.
- 02
Split implicit and explicit queries
Implicit queries ("emergency plumber") need the city exit. Explicit queries ("emergency plumber Leeds") put the location in the query and are the honest way to cover places outside the metro list.
- 03
Run each check clean and from the right city
No cookies carried over, no signed-in state, one fresh rotating exit per query, with the country and city tokens set. Each check is independent, so rotation is the right default.
One clean request per query and city13 linesimport httpxGATEWAY = "proxy.arcproxies.io:8000"PASSWORD = "PASSWORD"def check(query_url: str, country: str, city: str) -> str: user = f"USERNAME_pool-arcfast_country-{country}_city-{city}" proxy = f"http://{user}:{PASSWORD}@{GATEWAY}" # New client per check: no cookies, no history, no carried-over location. with httpx.Client(proxy=proxy, timeout=30, follow_redirects=True) as c: return c.get(query_url, headers={"Accept-Language": "en-GB"}).texthtml = check("https://search.example/search?q=emergency+plumber", "gb", "leeds") - 04
Record the location the page reports
Search result pages often state the location they used. Parse it and store it next to the city you requested; when they disagree, flag the row rather than trusting it. The location testing guide covers how to check an exit before a run.
- 05
Retry on throttling, do not hammer
A throttled or challenged response is a failed check, not a result. Retry it later from a new exit and keep the per-run pace modest — see handling 429 rate limits.
Setup
Recommended setup
Search result pages are among the strictest pages you will collect, and local results need the city token, so the residential pools carry this.
| Plan | Role | Session | Targeting | Price |
|---|---|---|---|---|
ARC Fast Rotating residential | Default for local rank checks Residential exits in the listed metros, a fresh one per check so no result inherits the last one's location or history. | Rotating, one exit per query | Country + city | €2.00 / GB €1.12 at 1 TB (−44%) |
ARC Ultra Premium residential | For checks that keep failing Premium residential for the keyword sets or markets where ARC Fast leaves you with failures you cannot otherwise explain. | Rotating, one exit per query | Country + city | €3.50 / GB €2.17 at 1 TB (−38%) |
ARC Mobile Mobile 4G/5G | For mobile-network spot checks Carrier IPs for comparing what a searcher on a mobile network sees. Country only — ARC Mobile has no city targeting, so it cannot run local-pack checks per city. | Rotating or sticky up to 60 minutes | Country (DE, GB, US, JP) | €3.50 / GB €3.15 at 1 TB (−10%) |
Prices are list prices in EUR, excl. VAT. Volume discounts apply automatically at checkout — full ladder on the pricing page.
Connect
One connection string per market
The country, city and sticky session are tokens in the username. Change the token, change the market; keep the session handle, keep the IP.
http://USERNAME_pool-arcfast_country-de_session-k3f9a1x2_sesstime-10:PASSWORD@proxy.arcproxies.io:8000Swap _country-de for any market you quote. The full grammar is on the residential proxies page.
Illustration
What daily local rank tracking in 10 cities costs
An illustration with round numbers — your pages, payloads and retry rate will differ. The arithmetic is the real price ladder.
Assumptions
- Keywords
- 500
- Cities
- 10
- Pages per check
- 1 (first results page)
- Cadence
- once a day
- Weight per page
- 300 KB
- Bandwidth per month
- ≈ 45 GB
On ARC Fast
€79.20per month, excl. VAT
45 GB bought in one purchase at €1.76 / GB (−12% volume rung, applied automatically).
The same 45 GB on ARC Ultra: €140.18 at €3.12 / GB. Route only the jobs that need it through the pricier pool.
Retries for throttled checks add to this; budget 10–20% on top. Checking mobile and desktop layouts separately doubles the figure.
Bandwidth never expires, so a bigger single purchase is only ever cheaper per GB. See the ladder.
In depth
Local rank tracking, in depth
How location shapes local search results
Google's own guidance for businesses says local results are based mainly on three factors: relevance (how well a profile matches the search), distance (how far the business is from the searcher) and prominence (how well known it is, including links and reviews). It also says there is no way to pay for a better local ranking.
Distance needs a searcher location. When the searcher does not share one, Google says it uses what it knows about their location. Its help page on location lists the sources: device location when permitted, saved home and work addresses, past activity, and the IP address — which it describes as roughly based on geography, giving a general area rather than an exact location. Google defines that general area as larger than 3 square kilometres and shared by at least 1,000 users.
For a rank tracker this sets the ceiling. A clean, signed-out request from a city-targeted exit carries one location signal — the IP — and it places the searcher in a general area of that metro. That is the view of an average signed-out searcher in the city, which is exactly what most local SEO reporting needs.
What a city-targeted exit can and cannot tell you
| Question | City-targeted exit | Why |
|---|---|---|
| Which businesses show in the local pack in Manchester? | Yes | The exit places a signed-out searcher in the metro |
| How does the pack differ between Manchester and Leeds? | Yes | Two exits, two general areas |
| Rank for "dentist" at a specific postcode or street corner | No | Needs a precise searcher location, which an IP does not carry |
| A geo-grid of rankings across one neighbourhood | No | Every grid point would need its own precise location |
| Rankings in a town not on the metro list | Partly | Use country targeting with an explicit-location query |
Be wary of anyone promising ZIP-level local rankings from proxies alone. IP geolocation databases place addresses approximately and do not always agree; even a correctly targeted exit is somewhere in the metro, not at a chosen address. City-level precision is the honest claim, and it is the one we make.
Implicit and explicit queries: two series, two methods
An implicit local query has no place in it — "pizza", "tax advisor", "emergency plumber". The search engine fills in the location from the searcher, so the exit's city is the experiment. These are the queries a city exit is for.
An explicit query names the place — "tax advisor Hamburg". The location comes from the text, and the searcher's own location matters much less. These are the honest way to cover places outside the metro list, and they are worth tracking anyway: they are how people search for places they are not in yet.
Keep them as separate series in your reporting. Blending them averages two different measurements into a number that describes neither.
Keeping rank checks clean
- No carried state. New client, no cookies, no signed-in session, every check. Personalisation from history is the most common source of phantom rank changes.
- Pin language and region. Set the interface language explicitly so a London check and a Paris check differ by location, not by accident of default language.
- One exit per query. Rotating proxies are the right default; a sticky session only helps when you deliberately page past the first results page.
- Pace the run. Spread daily checks across hours rather than firing them in a burst.
The parent SERP monitoring page covers country-level rank tracking; this page is the city layer on top of it.
Works with anything that takes a proxy URL
- Python requests / httpx
Playwright- Node.js
- Go net/http
- Docker
FAQ
Questions
Something not covered? Write to contact@arcproxies.io.
Can proxies track local rankings at ZIP-code level?
Not honestly. An exit IP places a signed-out searcher in a general area of a metro; Google describes IP addresses as roughly based on geography. Our city targeting covers a fixed list of metros per country. For specific postcodes, use explicit-location queries or tools built on precise searcher locations.
Which cities can I target for local rank tracking?
ARC Basic, ARC Fast and ARC Ultra take a city token from a published list, including New York, Los Angeles, Chicago, Miami, Dallas, Seattle, London, Manchester, Birmingham, Leeds, Berlin, Munich, Hamburg, Paris, Lyon, Milan, Tokyo, Toronto, Sydney, São Paulo and Amsterdam, among others.
What decides the local pack ranking?
Google says local results are based mainly on relevance, distance and prominence. Distance depends on where the searcher is, and when the searcher does not share a location, Google uses what it knows about it, including the IP address. That is why the city of the exit changes the local pack.
Should I use rotating or sticky proxies for rank tracking?
Rotating. Each rank check is an independent, signed-out request, and a fresh exit per query keeps one check's location and history from leaking into the next. A sticky session only helps when you deliberately page through several result pages in one check.
Can I use mobile proxies for local rank tracking?
Only at country level. ARC Mobile has carrier IPs in Germany, the UK, the US and Japan, but no city targeting, so it cannot place a searcher in a particular metro. Use ARC Fast or ARC Ultra with the city token for local-pack checks.
How much bandwidth does local rank tracking use?
A results page is typically a few hundred kilobytes. 500 keywords in 10 cities, checked daily at about 300 KB a page, is roughly 45 GB a month before retries. Bandwidth is billed per GB and never expires.
Sources & review
Last reviewed by the ARC Proxies team. Prices are read from the live catalog at build time.
- [1]Google Business Profile Help: Tips to improve your local ranking on Google
- [2]Google Search Help: Manage your location on Google (search results based on location)
SEO & SERP
More on seo & serp
Get started
Buy a gigabyte and try it on your own targets.
No subscription, no sales call. Code WELCOME15 takes 15% off your first purchase, and whatever you do not use is still there next quarter.