Best Practices for Canonical Location Formatting in SERP Checks

Every local SEO tool that uses UULE ultimately encodes a canonical location name. The quality of that canonical name determines whether the SERP that loads is the one your customer actually sees. Sloppy canonical names produce drifting localization. Clean ones produce repeatable, comparable, audit-grade results. The difference is small in any single check but compounds across hundreds of audits.

You can see your local SERP from any address — enter a keyword, country, and location to open the live page.

This article codifies the canonical-name formatting practices that hold up across markets, languages, and tools. The rules below are drawn from the conventions we apply across every UULE token generated by the Local SERP Checker tool, refined through years of cross-market audits. Treat them as a working standard you can adapt to your team's needs.

The Core Principle: Consistency Beats Cleverness

The single most important principle is consistency. There's rarely one objectively correct canonical name for a given place — there are several variants that all work — but the one that produces comparable data over time is the variant your team uses every time. Audits today should be reproducible six months from now by an analyst who wasn't on the project then. That reproducibility lives in the canonical-name standard.

A team without a standard produces canonical names like "Brooklyn," "Brooklyn, NY," "Brooklyn, New York," "Brooklyn, New York, United States," and "Brooklyn, NY, USA" across different audits and different analysts. Each variant may localize slightly differently. The aggregate data becomes unreliable simply because the locations weren't formatted the same way.

A team with a standard produces "Brooklyn, New York, United States" every time. The data lines up.

Rule 1: Use a Three-Component Form Where the Country Supports It

For most countries with meaningful regional administrative structure, the canonical form is:

Locality, Region, Country

Examples:

• "Austin, Texas, United States"
• "Manchester, England, United Kingdom"
• "Toronto, Ontario, Canada"
• "Munich, Bavaria, Germany"
• "São Paulo, São Paulo, Brazil"
• "Sydney, New South Wales, Australia"

The three components — locality, region, country — give Google's edge enough context to disambiguate cleanly. The region component is the load-bearing piece that resolves "Springfield" (which exists in many U.S. states) or "Manchester" (which exists in multiple countries).

For countries without meaningful intermediate administrative units (Luxembourg, Singapore, Vatican City, some Caribbean nations), use a two-component form:

Locality, Country

Examples:

• "Luxembourg, Luxembourg"
• "Singapore, Singapore"
• "Reykjavik, Iceland"

Rule 2: Spell Out Country Names

Always use the full country name rather than ISO codes or common abbreviations. The full name matches Google's place graph entries most reliably.

Use:

• "United States" (not "USA," "US," or "U.S.")
• "United Kingdom" (not "UK")
• "United Arab Emirates" (not "UAE")
• "South Korea" (not "ROK" or "Korea")

ISO codes belong in the gl parameter, not in the canonical name.

Rule 3: Use Title Case for All Components

Title case is the canonical form most cities use officially. Google's edge handles case insensitively, but title case matches how places are typed in user-facing content and reduces variance when comparing across audits.

Use:

• "Brooklyn, New York, United States" (title case)
• Not: "brooklyn, new york, united states" (lowercase)
• Not: "BROOKLYN, NEW YORK, UNITED STATES" (uppercase)

For places with mixed-case conventions (e.g., "iPhone" branding aside, but consider names like "DeKalb" or "McAllen"), respect the official mixed case.

Rule 4: Be Consistent With Abbreviations

Some place names contain abbreviations or have abbreviated forms in common use. Pick one form and use it consistently.

Common decisions:

• "Saint Louis" vs. "St. Louis" — both work; pick one. We use "St. Louis."
• "Saint Paul" vs. "St. Paul" — same pattern. We use "St. Paul."
• "Mount Vernon" vs. "Mt. Vernon" — same pattern. We use "Mount Vernon."
• "Fort Worth" vs. "Ft. Worth" — pick the full form. We use "Fort Worth."

Document the decisions in a team style guide.

Rule 5: Preserve Diacritics and Special Characters

UTF-8 + base64 handle diacritics, accents, and special characters cleanly. The question is whether to use them.

The reliable answer: use diacritics and special characters when they appear in the place's official name in the language matching your hl.

• For hl=es, use "Málaga, Andalucía, España" (or "Spain" if you keep country names in English).
• For hl=en, "Malaga, Andalusia, Spain" without diacritics is acceptable but slightly less precise; "Málaga, Andalusia, Spain" works too.
• For hl=fr, use "Saint-Étienne, Auvergne-Rhône-Alpes, France."
• For hl=de, use "München, Bayern, Deutschland" or the English form "Munich, Bavaria, Germany" depending on the team's standard.

Pick a standard per country/language and apply it.

Rule 6: Use Comma-Space Separators

Always separate components with , (comma + space). Don't use slashes, pipes, or any other separator.

Use:

• "Austin, Texas, United States"
• Not: "Austin/Texas/United States"
• Not: "Austin|Texas|United States"
• Not: "Austin Texas United States" (no separators)

The comma-space form is what Google's place graph uses and what every working SEO tool produces.

Rule 7: No Trailing Punctuation, No Extra Whitespace

Trim aggressively. Trailing commas, double spaces, leading whitespace, or stray punctuation contaminate the encoded string.

Use:

• "Brooklyn, New York, United States"
• Not: "Brooklyn, New York, United States." (trailing period)
• Not: " Brooklyn, New York, United States " (leading/trailing whitespace)
• Not: "Brooklyn, New York, United States" (double space)

A simple normalization step — trim, collapse multiple spaces, strip trailing punctuation — handles this reliably.

Rule 8: For Sub-City Granularity, Add Neighborhood as the First Component

When auditing at neighborhood level, the canonical form becomes:

Neighborhood, Locality, Region, Country

Examples:

• "Park Slope, Brooklyn, New York, United States"
• "Shoreditch, London, England, United Kingdom"
• "Belltown, Seattle, Washington, United States"
• "Le Marais, Paris, Île-de-France, France"

Always include the parent city. A neighborhood name alone ("Park Slope") doesn't anchor to a city in many cases and can drift.

For ZIP-level audits, replace the neighborhood with the ZIP:

ZIP, Locality, Region, Country

Examples:

• "10001, New York, New York, United States"
• "94110, San Francisco, California, United States"

Rule 9: Validate Every Canonical Name With the SERP

Once you've generated a canonical name and built the UULE-encoded URL, open it in incognito and validate the SERP. Specifically:

• The Map Pack listings should clearly belong to the encoded location.
• The "results from [location]" indicator (when Google shows it) should match.
• The organic listings should have a noticeable local tilt for transactional queries.

If any of those checks fail, refine the canonical name and re-encode. Usually adding the region or country fixes ambiguity issues; sometimes switching from a colloquial neighborhood to a recognized one fixes others.

Rule 10: Log the Canonical Name Alongside the UULE

UULE tokens are base64-encoded opaque strings. They're not human-readable, they're not searchable in audit logs, and they're not auditable on their own. The canonical name is.

Every audit log entry should include both: the canonical name (human-readable, auditable, comparable) and the UULE token (machine-readable, used in URLs). Drop one or the other and the audit's reproducibility weakens.

Rule 11: Match the Canonical Name to the Geocoder's Conventions

If your tool uses Nominatim, the canonical name should match the components Nominatim returns. Nominatim returns city, state, country fields for U.S. places — composing "City, State, Country" from those fields produces canonical names that round-trip cleanly through the geocoder.

If you switch geocoders (to Google Maps, Mapbox, or HERE), expect minor naming differences. Some geocoders return "Province" where another returns "State." Standardize on the labels your primary geocoder uses, and accept that switching tools requires a re-audit of the canonical-name standard.

Rule 12: Treat the Canonical-Name Standard as a Living Document

Local SEO evolves. Place names change. Google's place graph updates. New conventions become reasonable. Treat your canonical-name standard as a team document that gets reviewed quarterly. When you find a case where the standard produces weak localization, debug, decide on a new rule, update the document, and apply it going forward.

The standard isn't sacred — but the consistency of applying it is.

A Sample Standard for U.S. Local SEO Teams

A short, practical canonical-name standard for a U.S.-focused local SEO team:

• Format: Locality, State, United States for city-level.
• Country: Always "United States." Never "USA" or "US."
• State: Spell out fully. "Texas," not "TX."
• Case: Title case throughout.
• Abbreviations: "St." for "Saint" in city names. "Mount" spelled out.
• Diacritics: Preserve in city names when present (e.g., "Española, New Mexico, United States").
• Neighborhood form: Neighborhood, City, State, United States.
• ZIP form: ZIP, City, State, United States.
• Separator: Comma-space.
• Trim: No leading, trailing, or doubled whitespace.

That fits on an index card and resolves 95% of canonical-name questions before they come up.

Onboarding New Analysts to the Standard

A canonical-name standard is only useful when every analyst applies it identically. A short onboarding routine catches drift before it accumulates:

• Day one: Walk the new analyst through the standard, including the per-country conventions and the abbreviation decisions.
• First week: Have the new analyst canonicalize a set of 20 sample inputs against the standard and review the results together.
• First month: Spot-check their audit logs for canonical-name consistency; flag any deviations and discuss.
• Ongoing: Quarterly team review of the standard, with an open invitation to propose changes based on observed edge cases.

Treat the standard like a piece o