An architecture, SEO & UX guide for multi-location websites

URL structure, location pages, schema markup, and location finder UX.

By George Leon on | Updated

Loading the Elevenlabs Text to Speech AudioNative Player...

Subdomains, subdirectories, or separate domains?

If you have a choice, choose subdirectories: (site.com/locations/nyc/) so all your location pages live under one roof.

Google’s Search Advocate John Mueller has said repeatedly that Google treats both structures equally, though his own advice leans toward keeping things together:

“If it’s the same site then try to put them on the same site.” (2018 Webmaster Hangout)

That official stance has been publicly contested for years. The core reason to prefer subdirectories is that link equity stays consolidated: every backlink to example.com strengthens all pages under it. Subdomains are treated as separate sites that must build their own authority from scratch (Google even requires separate Search Console verification).

Some interesting migration stats:

But you can build a clean multi-domain codebase

I have a client that wanted to preserve their existing strategy of using a unique domain for each location. So I rebuilt their websites all under one simple codebase to make maintenance a breeze:

This overcame the traditional problems with multi-domain setups: duplicated codebases, inconsistent updates, multiplied maintenance. Its true each domain still needs to build its own authority, but we’re fortunately not also fragmenting our engineering effort across 25 separate repositories and deploy pipelines.

The duplicate content question

There is no “duplicate content penalty.” Google’s canonicalization documentation (updated December 2025) doesn’t mention one.

Google clusters duplicate URLs and picks one to surface. Shared boilerplate across location pages (services, benefits, pricing) won’t get you penalized.

The real risk is doorway pages. Google’s spam policies call out “multiple domain names or pages targeted at specific regions or cities that funnel users to one page” by name. Google’s September 2025 Spam Update made this concrete, hitting businesses with cookie-cutter location pages that used identical templates and content order across cities.

“Having multiple domain names or pages targeted at specific regions or cities that funnel users to one page”

Google Spam Policies

The practical test: if swapping the city name is the only difference between two of your location pages, that’s the doorway pattern. Each page needs to stand on its own as a useful destination.

Content that’s naturally unique per location

Location page essentials

These are the elements that make a location page useful to both users and search engines. Some are officially documented by Google; others are widely accepted best practice.

Technical SEO

These are the signals that help Google find, crawl, and correctly index all your location pages. Getting them wrong means pages that don’t rank, don’t get indexed, or compete with each other.

Schema markup

Structured data helps Google understand your locations as distinct entities, not just pages. Done right, it can unlock rich results (enhanced search listings that display star ratings, hours, address, and other details directly in Google’s results) and connects each branch to your broader organization in Google’s knowledge graph.

Per Google’s docs, use the most specific LocalBusiness subtype available for each location (Dentist, Restaurant, AutoRepair, etc.) rather than the generic LocalBusiness. There are 30+ subtypes on schema.org, many with further sub-categories.

Add sameAs to each location pointing to its social profiles and Google Business Profile URL. Google documents this as the way to connect a location to its presence elsewhere on the web.

Using @id to link an Organization entity to its LocalBusiness branches is a widely used JSON-LD practice for expressing parent-child relationships in structured data, but it is not something Google’s own documentation specifically covers. It’s still worth doing since it makes the graph cleaner for any entity-aware processing, just don’t expect it to be a documented Google ranking signal.

How to build a location finder

I’ve built location finders for multi-location brands, and the same problems come up every time. Here’s what I’ve learned actually matters.

Lazy-load the map

Don’t load map scripts on page load. I show a static placeholder image and only load the map library (Mapbox, Google Maps, etc.) when the user actually interacts: clicks the map or focuses the search input. This keeps initial load fast, improves Core Web Vitals scores, and saves on API costs since bounce traffic and bots never trigger tile requests.

Block bots from loading the map

I use server-side bot detection to prevent map scripts from running for crawlers at all. Googlebot gets a fast, clean page and you’re not burning map API calls on non-human traffic. On high-traffic location hubs, bot crawls can add up to real costs fast.

Geolocation with a graceful fallback

If the user grants location access, center the map on them and show distances. If they deny it, don’t leave them with an empty or broken state. I zoom out to show all locations nationally and keep the location list empty until they search. Never assume you have their location.

Search by zip code or city

I accept both zip codes and city names. Those are the two most natural ways people look for nearby locations. When a search result has a bounding box (like a city), I zoom to fit that box rather than a fixed zoom level. A city search covers more ground than a zip code search and should feel that way.

The list drives conversions, not the map

The map gets attention, but the list is what people actually use to choose a location. I calculate real distances using the Haversine formula (a standard math formula for computing distance between two points on a sphere, i.e. the earth), filter by a reasonable radius (50 miles is a common default), and sort by proximity. Each location card should have one clear action: book, call, get directions.

One popup at a time

I keep only one popup open at a time and auto-pan the map so popups are never clipped by the container edge. Small details, but users notice when the interface feels broken.

Google Business Profile integration

Each location needs its own verified GBP listing. Per Google’s official GBP guidelines, you should not create more than one profile per location, and the website URL in each profile must represent that specific location. Pointing all your GBP listings to the homepage means searchers who click through land on a generic page with no location context, which hurts both user experience and the connection between your GBP listing and your location page.