An Architecture, SEO & UX Guide for Multi-Location Websites

URL structure, location pages, schema markup, and location finder UX for businesses with multiple branches.

By George Leon on

Multi-Location Website Design Best Practices

Subdomains, Subdirectories, or Separate Domains?

Use subdirectories: example.com/locations/charlotte/. All your location pages live on one domain, under one roof.

Google officially says they handle subdomains and subdirectories equally. In practice, subdirectories tend to outperform subdomains because link equity stays concentrated. Link equity is the SEO value that flows through backlinks pointing at your domain. Every link to example.com benefits all pages under it, including your location pages. With subdomains, that value gets split.

Separate domains per location are a hard no. Each one starts from zero, multiplies your SEO workload, and fragments whatever you’ve built on your main domain.

The Duplicate Content Question

First, the misconception: Google has explicitly said there is no “duplicate content penalty” in the way most people mean it. Google will just pick which version to surface. Google is also smart enough to recognize that a multi-location business will naturally share content across its pages: often the same services, same brand, maybe even same pricing. That shared content won’t get you penalized.

The real risk is doorway pages. Google’s spam policies define these as pages created purely to rank for specific queries that offer no unique value to users, and they specifically call out “pages targeted at specific regions or cities” as a primary example. Pages that cross this line “may rank lower in results or not appear in results at all.”

The practical test: if the only difference between two of your location pages is the city name swapped in, that’s the doorway pattern. Google’s own guidance on overly similar pages is to either expand each one with genuinely unique content, or consolidate them into one page.

Content That’s Naturally Unique Per Location

Some 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.