How to Check Google Rankings in Another City

Google's help page on managing your location in Search lists four sources it combines to estimate where a searcher is: the device's own location, a saved home or work address, earlier activity, and the IP address, which Google describes as "roughly based on geography". Your laptop in Denver and your client's phone in Austin feed different values into every one of those.

A few other things pile on top:

• Account history. A signed-in client who has clicked your site before may see it higher than a stranger would.
• Device. Mobile and desktop result pages differ in layout and sometimes in order.
• A cached location. The same Google help page says google.com may reuse your last device location, "stored in a cookie set to expire after 6 hours."
• Time. Rankings move during the day, so two checks hours apart are two different measurements.

You can't recreate the client's personal history, and you shouldn't try. What you can reproduce is the clean, logged-out results page a new searcher in that city gets. That's the number worth reporting, and it's the one this pipeline produces.

The instinct is to buy an IP in Austin and search from it. It's a weak fix, for two reasons.

First, the IP is the coarsest signal on Google's list. Second, the "Austin" label on a proxy is a geolocation database's opinion, and databases often disagree about the same address (our guide to validating IP geolocation accuracy shows how to measure that). Our post on city-targeted proxies covers when paying for city-level IPs is still justified. For rank checks, the location is better carried in the request itself.

Here's the split of responsibilities:

So the proxy's job here is narrow: put every request in the right country and keep Google answering. The city comes from somewhere else.

Two of the three parameters are documented by Google. In the Programmable Search JSON API reference, gl is "Geolocation of end user" and takes "a two-letter country code", and hl "Sets the user interface language." The same names work on the regular results page URL, which is how rank trackers have used them for years.

uule is a different story. Google has never published it. It's a location string that rank-tracking tools reverse-engineered, and the version in common use starts with w+CAIQICI, then a single character that encodes the length of the location name, then that name in Base64. Because it's undocumented, it can stop working without notice, so the verification step later in this guide isn't optional.

Keep all three aligned with the exit IP. A US proxy, gl=us, hl=en and a Denver uule tell one consistent story. A German proxy with gl=us and a Denver uule tells three, and you have no idea which one Google believed.

The location name inside uule has to be Google's canonical name for the place, not whatever you type. Google publishes those names in the geotargets CSV on its Google Ads API developer site. The file we read on 30 October 2026 was geotargets-2026-10-06.csv, with the columns Criteria ID, Name, Canonical Name, Parent ID, Country Code, Target Type, Status and 273,674 data rows.

Use the file rather than guessing, because short city names are ambiguous. In that release, "Austin" matches a city in Manitoba (Austin,Manitoba,Canada), a neighborhood in Colorado (Austin,Colorado,United States) and the one you probably want (Austin,Texas,United States, Criteria ID 1026201). "Springfield" appears 31 times, 22 of them as US cities. Encode the wrong row and you'll get a perfectly valid result page for a town your client has never heard of.

This lookup filters by country and target type, and refuses to guess when more than one row survives:

import csv

def find_canonical(csv_path, city, region, country_code="US"):
    """Return the one active City row matching city + region, or raise."""
    matches = []
    with open(csv_path, newline="", encoding="utf-8") as f:
        for row in csv.DictReader(f):
            if (row["Name"] == city
                    and row["Country Code"] == country_code
                    and row["Target Type"] == "City"
                    and row["Status"] == "Active"
                    and f",{region}," in f",{row['Canonical Name']},"):
                matches.append(row)
    if len(matches) != 1:
        raise ValueError(f"{city}/{region}: {len(matches)} matches, pick by Criteria ID")
    return matches[0]["Canonical Name"], matches[0]["Criteria ID"]

name, cid = find_canonical("geotargets-2026-10-06.csv", "Austin", "Texas")
print(name, cid)   # Austin,Texas,United States 1026201

Then build the string. The length character comes from a 64-symbol table indexed by the byte length of the canonical name:

import base64
import string

UULE_KEYS = string.ascii_uppercase + string.ascii_lowercase + string.digits + "-_"

def make_uule(canonical_name: str) -> str:
    raw = canonical_name.encode("utf-8")
    if len(raw) >= len(UULE_KEYS):
        raise ValueError("canonical name too long for the single-character length key")
    return "w+CAIQICI" + UULE_KEYS[len(raw)] + base64.b64encode(raw).decode("ascii")

print(make_uule("Denver,Colorado,United States"))
# w+CAIQICIdRGVudmVyLENvbG9yYWRvLFVuaXRlZCBTdGF0ZXM=

Store the Criteria ID next to every result. When a client asks "which Austin?", you can answer with an ID instead of a shrug.

You have two ways to send the request through SparkProxy, and the choice is mostly about whether you want to run browsers yourself.

The Scraping API (https://scrape.sparkproxy.io/api/v1, key in the X-API-Key header) handles rotation and rendering. render_js defaults to true and costs 5 credits, render_js=false is a plain fetch at 1 credit, and country_code adds 5. You pass the Google URL with gl, hl and uule already in it, and set country_code=US so the exit agrees with gl=us. If challenges pile up on the standard pool, proxy_type=premium switches to the premium pool at 10 credits without rendering or 25 with it, per the docs.

The proxy gateway (gateway.sparkproxy.io) is for teams already running Playwright or another browser. Port 11000 is Random Rotation, a new exit per request. Port 11002 is Sticky Sessions, which holds one exit for 5 minutes. Port 13000 is SOCKS5. Plans start from $75/month with unlimited bandwidth, and they're billed by plan and thread count, not by gigabytes, so a heavy rendered results page costs the same as a light one.

The broader trade-offs between proxy types for rank work are in datacenter proxies for SEO rank tracking, so we won't repeat them here.

Run one check by hand before you script anything. This sends a Denver results page for "emergency plumber" through the API with the response envelope turned on:

UULE='w+CAIQICIdRGVudmVyLENvbG9yYWRvLFVuaXRlZCBTdGF0ZXM='
TARGET="https://www.google.com/search?q=emergency+plumber&gl=us&hl=en&pws=0&uule=$(python3 -c 'import sys,urllib.parse;print(urllib.parse.quote(sys.argv[1],safe=""))' "$UULE")"

curl -sG "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: $SPARKPROXY_API_KEY" \
  --data-urlencode "url=$TARGET" \
  --data-urlencode "country_code=US" \
  --data-urlencode "json_response=true" \
  --data-urlencode "tag=rank:denver:emergency-plumber" \
  -o denver.json

Two details trip people up. The uule value contains + and =, so it must be URL-encoded inside the target URL, or Google receives a broken string and quietly ignores it. And with json_response=true the page arrives as Base64 in the body field of the envelope, next to job_id, status_code, duration_ms and credits_used. Decode it before you search it for anything.

Don't use format=json for this. In the SparkProxy API, format only converts the page content (html, md, mdx, json, screenshot, pdf). The envelope with the status code and credit count comes only from json_response=true.

The same request in Python, which the rest of the pipeline builds on:

import base64
import os
import urllib.parse

import requests

API = "https://scrape.sparkproxy.io/api/v1"

def serp_url(query, uule, gl="us", hl="en"):
    params = {"q": query, "gl": gl, "hl": hl, "pws": "0", "uule": uule}
    return "https://www.google.com/search?" + urllib.parse.urlencode(params)

def fetch_serp(query, uule, country="US", tag=None):
    params = {
        "url": serp_url(query, uule),
        "country_code": country,
        "json_response": "true",
    }
    if tag:
        params["tag"] = tag
    r = requests.get(API, params=params,
                     headers={"X-API-Key": os.environ["SPARKPROXY_API_KEY"]},
                     timeout=120)
    r.raise_for_status()
    env = r.json()
    html = base64.b64decode(env["body"]).decode("utf-8", errors="replace")
    return env["status_code"], env["credits_used"], html

urlencode handles the + and = in the uule value for you, which removes the most common silent failure.

This is the step most tutorials skip, and it's the one that makes the numbers defensible. Google's help page says the bottom of a results page shows the location it used and where that came from, with labels such as "From your device", "Based on your past activity" and "From your internet address".

Check every page for three things before you trust its rankings:

1. Was it a results page at all? Google's block page contains the sentence "Our systems have detected unusual traffic from your computer network." A page like that has no listings, so a naive parser records "not ranked", which looks exactly like a ranking drop.
2. Does the page name the target city? Look for the canonical city name (or its first part) near the footer.
3. Do local results agree? If the page has a local pack, the business addresses should be in or near the target city.

import re

BLOCK_MARKERS = (
    "Our systems have detected unusual traffic",
    "/sorry/index",
)
FOOTER_LABELS = (
    "From your internet address",
    "From your device",
    "Based on your past activity",
    "Based on your places",
)

def classify_page(html, canonical_name):
    if any(m in html for m in BLOCK_MARKERS):
        return "blocked"
    city = canonical_name.split(",")[0]
    text = re.sub(r"<[^>]+>", " ", html)
    tail = text[-20000:]   # the location footer sits near the end of the page
    if city in tail:
        return "location_ok"
    if any(label in tail for label in FOOTER_LABELS):
        return "location_other"   # Google states a location, but not ours
    return "location_unknown"

How uule shows up in that footer isn't documented by Google, and the footer's wording can change, so treat the three outcomes as a triage, not a proof. Store location_other and location_unknown pages and read a sample by eye during your first week. If a city keeps coming back location_other, the usual cause is an unencoded uule, a canonical name typed by hand, or an exit country that disagrees with gl.

We couldn't run a live measurement of how often Google honours uule while writing this (our test endpoint was unavailable on 30 October 2026), so we're not quoting a success rate. Measure your own on a pilot: 10 keywords, 3 cities, 3 mornings.

Once single checks verify, the job is a loop over two lists. Keep the city list in a file with the Criteria ID, so encoding happens once and the ambiguity check never reruns at 6am:

CITIES = [
    # (label, canonical name from geotargets CSV, criteria id)
    ("denver", "Denver,Colorado,United States", "1014485"),
    ("austin", "Austin,Texas,United States", "1026201"),
    ("chicago", "Chicago,Illinois,United States", "1016367"),
]
KEYWORDS = ["emergency plumber", "water heater repair", "drain cleaning"]
TRACKED_DOMAIN = "sparkproxy.io"   # replace with the client's domain

Finding the domain's position needs a parser. Google's markup changes often, so this one relies on a single stable-ish pattern, an organic result is a link that wraps an