UULE Explained: The Geotargeting Parameter Behind Local SERPs

If you've spent any time inside local SEO tools, you've seen the term UULE. It's the parameter that does the heavy lifting behind every credible local SERP checker, and it's the difference between auditing what your customer sees and auditing what your own browser happens to show you. Yet UULE is also one of the least documented parts of Google Search. Google has never published an official spec, and most of what the SEO community knows about it has been reverse-engineered, tested, and refined over the years.

Use it to check local search rankings across the neighborhoods and ZIPs you serve.

This article is a complete explainer on UULE — what it is, where it came from, how the format works, how SEO tools use it, and how to think about it as Google's search surface continues to evolve. The structure draws from years of building and using UULE-based tooling, where every local SERP audit our team runs depends on getting this parameter right.

What UULE Actually Is

UULE is a query parameter Google accepts in its search URLs (https://www.google.com/search?...&uule=...). It carries an encoded representation of the searcher's location, and when Google sees a valid UULE on a request, it serves results as if the searcher were physically at that location. The page that comes back — the Local Pack, the organic listings, the SERP features — calibrates to the encoded place rather than to the user's actual IP or account location.

UULE stands for Universal Unique Location Encoding (loosely; Google has never confirmed the exact acronym). The practical definition is simpler: it's a base64-encoded string carrying either a canonical place name or a coordinate pair, prefixed with a short identifier that tells Google which encoding format is in use.

For local SEO purposes, only one variant matters: the canonical-name UULE that encodes "City, Region, Country" style strings. There's also a coordinate-based UULE used by Google Ads and a few specialized tools, but the canonical-name format is what every public-facing local SERP checker on the web uses.

Where UULE Came From

UULE wasn't designed as an SEO tool. It emerged from Google's need to localize search results when the natural geographic signal — the user's IP, browser locale, or account-based location — was insufficient or absent. Google products like search, ads, and maps needed a precise, compact way to communicate "this request is from this place" without relying on noisy IP-based geolocation.

Once SEO tool builders noticed that the parameter worked predictably on google.com/search, it became the foundation of the entire "check Google rankings from any location" category of tools. Today, UULE underpins live SERP checkers, rank trackers, and many SERP scraping services that need location accuracy at city or neighborhood granularity.

The Format: How a UULE Is Constructed

The canonical-name UULE follows a documented (community-reverse-engineered) pattern. The structure is:

uule = "w+CAIQICI" + <length-key-character> + base64(<canonical name>)

Breaking that down:

• Prefix w+CAIQICI. A fixed string that identifies the format. The w indicates the canonical-name variant.
• Length key character. A single character drawn from a 64-character alphabet — uppercase letters, lowercase letters, digits, dash, underscore — picked at the index equal to the byte length of the UTF-8 encoded canonical name. So a 30-byte canonical name uses the 30th character of the alphabet as the key.
• Base64-encoded canonical name. The UTF-8 bytes of the location string, base64-encoded with standard encoding.

A worked example: encoding "Brooklyn, New York, United States."

1. UTF-8 bytes: 32 bytes.
2. Length key character: the 32nd character of the alphabet (g in standard 0-indexed ordering, or whatever character the implementation uses at that position).
3. Base64 encoding of "Brooklyn, New York, United States": QnJvb2tseW4sIE5ldyBZb3JrLCBVbml0ZWQgU3RhdGVz.
4. Concatenated UULE: w+CAIQICIg + the encoded string, producing roughly w+CAIQICIgQnJvb2tseW4sIE5ldyBZb3JrLCBVbml0ZWQgU3RhdGVz.

The result is a compact token Google's edge can decode in microseconds. The location string can be quite long — up to about 60 bytes in practice — so most city/state/country combinations fit comfortably.

The Coordinate-Based Variant (Briefly)

A second UULE variant encodes latitude and longitude directly, used by Google Ads location targeting and a few hyperlocal tools. The format is more complex — a binary protocol-buffer-like structure base64-encoded. It's powerful for ad targeting but rarely used in organic SEO testing because:

• The canonical-name variant is more stable across Google's properties.
• Coordinate encoding requires a more sophisticated builder than most SEO tools provide.
• For local SERP analysis, a canonical name like "Park Slope, Brooklyn, New York, United States" is usually as precise as a coordinate, with better predictability.

Most SEO operators never need to touch coordinate UULE. It's enough to know it exists.

Why Canonical-Name Quality Matters

The biggest determinant of UULE-based localization quality isn't the encoding — it's the canonical name you feed into the encoder. Google's interpretation of the location is only as good as the place string you provide. Three patterns matter:

• Specificity. "Brooklyn, New York, United States" is much better than "Brooklyn." The full canonical form gives Google enough context to render a Brooklyn-specific SERP. The short form may default to a less precise interpretation.
• Order. The "City, Region, Country" order matches what Google expects. Reordering ("United States, New York, Brooklyn") tends to degrade localization.
• Consistency. Use the same canonical form for the same place every time. "St. Louis, Missouri, United States" and "Saint Louis, Missouri, United States" can produce different localization quality.

This is why serious local SERP checkers run user input through a geocoder — like the Nominatim service backed by OpenStreetMap — before encoding UULE. The geocoder returns structured address components (locality, county, region, country) that the tool then assembles into a clean canonical name. The encoding step is trivial; the canonicalization step is where quality is won or lost.

How SEO Tools Use UULE

A typical local SERP checker workflow:

1. User enters a free-form location ("downtown Austin," "1600 Pennsylvania Ave," "Park Slope").
2. The tool calls a geocoder to resolve the input into structured address components.
3. The tool assembles a canonical name in the right order.
4. The tool encodes the canonical name into UULE using the canonical-name format.
5. The tool constructs a Google search URL with q, hl, gl, uule, and possibly pws=0 and num=20.
6. The tool opens the URL in a new tab (or for rank trackers, fetches the page server-side for parsing).

That entire flow happens in well under a second. The user sees: keyword in, localized Google SERP out.

For rank trackers, UULE is the parameter that enables defining a "location" as a stored attribute. Each tracked keyword's location is stored as a canonical name (or coordinate pair), encoded fresh on each scheduled check, and used to build the Google request. The same approach lets a tracker store hundreds of city-level monitoring jobs without re-resolving each one from raw input every cycle.

Pairing UULE With gl and hl

UULE doesn't work alone. It's almost always paired with gl (country) and hl (language). The reasoning:

• gl keeps country identity aligned. A UULE pointing to "Sydney, New South Wales, Australia" paired with gl=us is a contradiction. Google can pick the wrong interpretation. Setting gl=au reinforces the country signal.
• hl keeps language signal aligned. A UULE pointing to "Berlin, Germany" paired with hl=en produces results with English-leaning bias when most real Berlin searchers use German. Setting hl=de matches reality.

The cleanest local SERP checker UIs offer combined country/language dropdowns ("Germany — German") that set both gl=de and hl=de together. The checker then encodes UULE for a German city in the same canonical form, and the final URL is internally consistent.

Limitations and Edge Cases

UULE works well for the cases SEO tools actually care about, but it has limits worth knowing:

• Hyperlocal granularity. UULE can encode neighborhood-level names ("Park Slope, Brooklyn, New York, United States"), but rendering accuracy at the block or street level depends on Google's interpretation. For sub-neighborhood precision, coordinate UULE is more reliable.
• Recently-changed places. New developments, renamed neighborhoods, or recently incorporated municipalities may not yet be in Google's place graph. UULE encoding works, but the SERP may default to a parent geography.
• Ambiguous names. "Springfield" exists in many U.S. states. Always include state and country in the canonical name to disambiguate.
• URL length. Some browsers truncate long URLs. UULE itself is short, but combined with long keywords and other parameters, the URL can grow. Most modern browsers handle it fine, but it's a real edge case.
• Account contamination. Even with a valid UULE, a logged-in Google account with a strong search history can shape results. Audit in incognito for clean reads.

The Future of UULE

Will UULE keep working? The honest answer: probably, but it's an undocumented parameter, and undocumented things can change without notice. A few signals are reassuring:

• UULE has worked consistently for over a decade across Google Search and other Google surfaces.
• Many of Google's own systems (Ads, Maps internal tools) rely on the parameter, which creates internal incentive to keep it stable.
• The community of SEO tools depending on UULE is large enough that any breaking change would produce widespread visibility.

That said, Google is reshaping SERPs aggressively in 2026 with AI Overviews, query rewriting, and tighter personalization. Those changes affect what's rendered, not what's localizable. Until Google introduces a public, supported alternative — and they haven't — UULE remains the practical mechanism for telling Google where a search should look like it's coming from.

Best Practices for Working With UULE

If you're using UULE directly (in a custom tool or a workflow), a short list of best practices:

• Always canonicalize through a geocoder. Don't trust user input. Run it through Nominatim or a commercial geocoder.
• Use the standard "City, Region, Country" order. Don't experiment with reverse orderings.
• Pair UULE with matching gl and hl. Internal consistency matters.
• Re-encode on every change. Stale UULE is the most common cause of confusing results.
• Test in incognito. Account history corrupts even clean UULE-based audits.
• Log the canonical name, not just the UULE token. UULE is opaque; the canonical name is auditable.

The Bottom Line

UULE is the unsung infrastructure of local SEO. It's the parameter that lets you, your tools, and your team look at Google through your customer's eyes — not your own. The encoding is simple, the canonicalization is where quality is won, and the future of the parameter is reasonably durable as long as Google continues to need a precise way to communicate location signals to its own search edge. Understand UULE well enough to know when your tools are getting it right and when they aren't, and your localized SERP audits become measurably more trustworthy. That trust is what every defensible local SEO recommendation ultimately rests on.