How a Local SERP Checker Works with UULE, gl, and hl

Local SERP checkers feel magical the first time you use them. You type a keyword, pick a city, and a real Google results page opens — except it's not your results, it's your customer's. Under the hood, there's no magic at all. The tool builds a Google search URL using three documented parameters — uule, gl, and hl — that together tell Google's edge "render this page as if the searcher were sitting at this location, in this country, speaking this language."

You can view localized search results for any market with our free tool — no API keys, no scraping, no sign-up.

This article unpacks how each parameter works, how a well-built local SERP checker assembles them into a search URL, and how to debug the most common reasons localized results don't look right. Everything here is based on practical experience running localized SERP audits for U.S. service businesses and reading what Google has openly documented about Search localization signals.

The Three Parameters That Drive Localization

Google's search URLs accept a handful of query parameters that shape the response. For local SEO purposes, three matter:

• q — the search query itself. Required.
• hl — host language. Sets the interface language and influences which language-specific results Google prefers.
• gl — geographic location, expressed as an ISO 3166-1 alpha-2 country code (e.g. us, gb, de).
• uule — a Google-proprietary encoded location parameter that pinpoints a place more precisely than gl can.

You'll occasionally see pws=0 (turn off personalized web search) and num=20 (request more results per page) added in URLs built by SEO tools. They're convenience parameters, not localization controls, but they're useful for cleaner audits.

The mental model: gl tells Google what country the search is from, hl tells it what language to render, and uule tells it the exact city, neighborhood, or canonical place. Combined, they reconstruct a customer's locale with enough fidelity that the resulting page closely matches what that customer sees in their own browser.

What gl Does

gl (geographic location) accepts a two-letter country code. Setting gl=us tells Google the search originates in the United States, gl=gb says United Kingdom, gl=de says Germany, and so on. The parameter influences:

• The default Google domain behavior (gl=fr shows results biased toward French sites).
• Currency, units, and formatting in some answer boxes.
• The set of domains and businesses considered "local" before more specific signals kick in.

gl is necessary but rarely sufficient. Setting only gl=us and ignoring uule gets you a U.S.-flavored SERP, but Google still has to pick a location, and it will often default to a national centroid or the IP-detected location of the requester. That's why pairing gl with uule is the right move whenever you care about city- or neighborhood-level accuracy.

What hl Does

hl (host language) accepts a language code such as en, es, fr, de, pt-BR, or zh-CN. It influences:

• The interface chrome — labels like "All," "Maps," "News," and pack headings appear in the chosen language.
• Language preferences in the results themselves. A user with hl=es searching from gl=us will see Spanish-language results pushed higher.
• Snippet rendering and certain on-SERP features that rely on natural-language processing.

hl matters more than people assume. If you're auditing a Spanish-language landing page targeting Latinx customers in Houston, setting hl=en while testing will misrepresent the experience your real prospects have. The right combo for that audit is gl=us, hl=es, with a Houston-encoded uule.

What uule Does (and Why It's the Hardest Parameter)

uule is the parameter that does the heavy lifting for local SEO testing. It encodes a canonical location string — typically "City, Region, Country" — into a compact token that Google's search backend treats as the searcher's location.

The format Google uses is well-known to SEO tool builders:

uule = "w+CAIQICI" + <key char> + base64(<canonical name>)

The key character is taken from a fixed alphabet (uppercase letters, lowercase letters, digits, dash, underscore) at the index equal to the length of the UTF-8 byte string of the canonical name. The base64 encoding is standard. There are other UULE variants — coordinate-based UULE strings used by Google Ads and by some internal tools — but the canonical-name form is the one almost every local SERP checker on the public web uses.

The reason uule is hard to get right is that garbage in, garbage out. Feed it "downtown LA" and you'll get a UULE for the literal string "downtown LA, United States," which Google may not interpret accurately. Feed it a clean canonical form like "Los Angeles, California, United States" and the localization quality jumps dramatically. Building a good local SERP checker means investing as much in the canonicalization of the user's input as in the encoding itself.

How a Local SERP Checker Builds a Search URL Step by Step

Here's what happens inside a well-designed local SERP checker from the moment a user clicks "Open Local SERP":

Step 1 — Capture inputs. The tool reads the keyword (q), the country/language selection (which yields gl and hl), and the free-form location string.

Step 2 — Canonicalize the location. The raw location is normalized. White space is trimmed, repeated commas collapsed, and the chosen country name appended if it's not already present. Many tools take an extra step: they call a geocoder such as Nominatim (the OpenStreetMap-backed service) or a commercial equivalent to resolve the input into structured address components — locality, region, country — and then rebuild the canonical string from those fields. This step is what turns "1600 Pennsylvania Ave, DC" into the clean "Washington, District of Columbia, United States" that UULE prefers.

Step 3 — Encode UULE. The canonical string is UTF-8 encoded, its byte length read, and the key character looked up. The bytes are base64 encoded, and the prefix w+CAIQICI plus the key char is prepended. The result is a UULE token like w+CAIQICIfV2FzaGluZ3RvbiwgRGlzdHJpY3Qgb2YgQ29sdW1iaWEsIFVuaXRlZCBTdGF0ZXM=.

Step 4 — Assemble the URL. The tool composes:

https://www.google.com/search?q=<keyword>&hl=<lang>&gl=<country>&uule=<uule>&pws=0&num=20

Each value is URL-encoded. pws=0 opts out of personalized web search; num=20 widens the result set for fuller audits.

Step 5 — Open the URL. The tool launches the URL in a new browser tab. Google renders a real, live results page calibrated to the encoded location.

That's the whole pipeline. There's no proxying of traffic, no scraping, no API tokens — just a correctly assembled URL.

A Worked Example

Let's say you want to see what a Brooklyn resident searches for "best pediatric dentist" sees. The inputs:

• Keyword: best pediatric dentist
• Country / Language: United States — English (gl=us, hl=en)
• Location: Brooklyn, NY

Canonicalization resolves "Brooklyn, NY" to "Brooklyn, New York, United States." UULE encoding produces a token like w+CAIQICIeQnJvb2tseW4sIE5ldyBZb3JrLCBVbml0ZWQgU3RhdGVz. The final URL becomes:

https://www.google.com/search?q=best+pediatric+dentist&hl=en&gl=us&uule=w+CAIQICIeQnJvb2tseW4sIE5ldyBZb3JrLCBVbml0ZWQgU3RhdGVz&pws=0&num=20

Opening that URL in a clean browser session (or an incognito tab to reduce account bias) gives you the Brooklyn three-pack, the Brooklyn-focused organic listings, and whatever local SERP features Google decided to render — exactly as a Brooklyn customer would see them.

Why Geocoding Matters as Much as Encoding

The single biggest predictor of local SERP checker quality is the canonicalization step. Geocoding does three things for you:

1. Disambiguation. Springfield exists in Illinois, Massachusetts, Missouri, Oregon, and more. A geocoder returns the right one given country and context.
2. Structure. Free-form input like "main and 5th, Austin" becomes structured address fields, then a clean canonical name.
3. Spelling and casing repair. Geocoders tolerate typos and quietly fix capitalization so the UULE encodes a recognizable place name rather than a mangled string.

Tools that skip geocoding can still produce UULEs, but the localization quality varies wildly. For agency-grade work — multi-city audits, ZIP-level comparisons, recurring monitoring — geocoding is non-negotiable.

Common Failure Modes (and How to Debug Them)

When a local SERP checker's output doesn't look right, the cause is almost always one of these:

• Stale UULE. The user changed the location field after geocoding but didn't re-encode. The UULE still points at the old place. Fix: always re-geocode after any location edit.
• Wrong country mismatch. gl=us paired with a UULE encoding "Toronto, Ontario, Canada" produces a confused page. Fix: keep gl aligned with the country in the canonical name.
• Language mismatch. hl=en with a UULE pointing to "Tokyo, Japan" still works mechanically, but the SERP layout will skew English-leaning. Fix: pair hl=ja with Japan-encoded UULEs when auditing for Japanese-speaking searchers.
• Account-personalized contamination. If you're signed into a Google account with a strong search history, your SERP can drift even with pws=0. Fix: audit in incognito or in a clean browser profile.
• IP-level dominance. In rare cases Google ignores uule and falls back on IP geolocation, especially for ambiguous queries. Fix: confirm the URL still has a valid UULE; some browsers strip query parameters when redirecting. Re-paste the URL fresh.

A short debug routine — re-geocode, confirm gl/hl alignment, open in incognito, paste the URL fresh — fixes 90% of "the results look wrong" complaints.

Beyond the Basics: Coordinate-Based UULE and the Future

The canonical-name UULE format is the only one publicly used at scale because it's the version Google's edge has consistently honored across years. Some advanced tools use a coordinate-based UULE format that encodes latitude and longitude directly. That format is closer to what hyperlocal advertisers use, but it's less stable for organic SERP testing and the encoding is more involved. For agency workflows, the canonical-name UULE remains the practical standard.

Looking forward, Google is steadily reshaping SERPs with AI Overviews, more aggressive query rewriting, and tighter personalization. Those changes affect what's rendered, but they don't change the URL-level localization controls. UULE, gl, and hl remain the public, supported way to tell Google where a search should look like it's coming from.

The Bottom Line

A local SERP checker isn't an algorithmic black box. It's a careful assembler of a Google search URL — built on three parameters Google has supported for years. gl sets the country, hl sets the language, and uule carries an encoded canonical name that pinpoints the location. Pair them with disciplined canonicalization (ideally via a geocoder like Nominatim), open the URL in a clean browser session, and you get a faithful view of what real customers see in real places. That's the whole craft — and once you understand the moving parts, your localized audits stop being guesses and start being measurements.