How can you make your hyper-local content URLs discoverable without sacrificing traffic?

Why does Google insist on unique URLs for local content?

The search engine can only index what it can discover and identify as a distinct resource. When you display different content for Paris and Lyon on the same URL via JavaScript or server geolocation, Googlebot only sees one page.

It cannot guess that your content varies based on the user's location. Without a distinct URL, there is no distinct indexing — and thus no specific ranking for "plumber Lyon" if everything goes through /services-plumbing.

What does Martin Splitt mean by "discoverable"?

A discoverable URL is one that Googlebot can find without user interaction. This comes through two main channels: the XML sitemap that lists all your pages or traditional HTML link navigation.

If your system requires selecting a city from a dropdown menu to show /city/paris, but that link doesn’t exist anywhere in plain HTML in the source code, it is not discoverable. Google does not fill out forms. Links must exist in plain text in the initial DOM.

What is the ideal navigation structure for this type of content?

The classic solution remains the regional hub page: /cities/ lists all your cities, each city links to /city/paris, /city/lyon, etc. Each city page then contains its own internal links to local services or products.

Another viable option: the footer with links to all geographic variations. Less elegant for UX but perfectly functional for crawling. The main thing is that these links exist in the source HTML, not injected later by client-side JavaScript.

• One URL = one specific local content: /paris/plumber ≠ /lyon/plumber
• Comprehensive sitemap: list all local variants with their full URLs
• Native HTML internal links: no JavaScript dependency for navigation between local versions
• Avoid URL parameters: prefer /city/paris to ?city=paris for clarity and control
• Strict canonicalization: each local page must point to itself as canonical

Is this statement consistent with practices observed on the ground?

Absolutely. We regularly see sites with geolocated dynamic content that never rank for their local variants, precisely because they use a single URL with JavaScript to switch the content. Google indexes the default version, and that's it.

Sites that perform best on local queries all have a clean URL architecture: Seloger, Leboncoin, Pages Jaunes — they all use distinct URLs by city or department. This is not a coincidence. It's the only way to allow Google to understand and index geographic granularity.

What common mistakes should be avoided with this type of architecture?

The first mistake: creating 200 city pages with duplicated content by just changing the city name in the H1. Google hates this, and you risk a massive dilution of your crawl budget. Each local page must have truly differentiated content — local reviews, specific addresses, hours, testimonials.

Second trap: improperly managed URL parameters. If you use ?city=paris, ensure that Search Console is set up to treat this parameter as changing the content, not as a simple filter. Otherwise, Google might decide to ignore it and only crawl one version. [To verify]: Google has never clearly documented the threshold at which too many local variants become counterproductive — field tests suggest that beyond 500 nearly identical pages, it becomes risky.

When could this recommendation pose a problem?

For sites with thousands of possible locations — think of Airbnb or Booking with every neighborhood of every city — creating a URL for each variant can explode your crawl budget and dilute your authority. Prioritization is needed: unique URLs for major cities, regional grouping for smaller ones.

Another limitation: sites with a strong UX component wanting a smooth experience without page reloads. You can technically keep your SPA with JavaScript geolocation for UX, but you'll need to implement server-side rendering or pre-rendering to serve Googlebot distinct URLs with the appropriate content. This is feasible, but it significantly complicates the technical architecture.

What should you prioritize auditing on your existing site?

Start by checking if your local pages have distinct URLs. Test in private browsing without geolocation: can you directly access each city version via a unique URL? If not, that’s a red flag.

Next, open your XML sitemap: do all your local pages appear there? Use Search Console to see how many URLs are discovered vs indexed. If you have 100 city pages in your sitemap but Google only indexes 10, there’s a problem with duplicate or quality content.

How to restructure an existing architecture without losing traffic?

If you're transitioning from a JavaScript system to unique URLs, set up 301 redirects from your old generic URL to the most relevant local version (often the capital or the largest city). For users coming from another location, use client-side JavaScript to suggest the right version — but keep the URL distinct.

Implement hreflang by city if you have multiple languages, or very strict canonical tags to prevent Google from considering your pages as duplicates of each other. Deploy gradually: start with 10-20 test cities, measure the impact in Search Console, and then scale.

What technical optimizations ensure maximum discoverability?

Your sitemap must include all local URLs with consistent priority and update frequency. If you regularly add new cities, automate sitemap generation to avoid omissions.

On the navigation side, create a hub page /cities/ that lists all your locations with a traditional HTML link to each page. If you have too many cities for one page, segment by region or department. The important thing: everything must be crawlable within 3-4 clicks maximum from the homepage.

• Check that each local page has a unique and clean URL
• Include all local URLs in the XML sitemap
• Create a clear internal navigation with HTML links to each variant
• Differentiate the content of each local page (not just the city name)
• Set up canonicals so that each page points to itself
• Test discoverability with a crawling tool (Screaming Frog, Sitebulb) to confirm that all URLs are accessible