How should a multi-location business build location pages?
A multi-location business should build location pages as a system: one locator page that lists every branch, and one page per location generated from a shared CMS template. The template keeps the brand consistent and saves work, while required unique fields make sure every page says something real about that branch. Our hub on local business website design covers the wider playbook; this guide is the template itself.
The reason to get this right is simple. Each branch competes in its own local search results, and a visitor choosing between your branch and a competitor down the road needs local answers: the exact address, today's hours, who works there, what's offered at that site and what nearby customers say. A page that only repeats the homepage with a different city name gives them none of that.
What URL structure should location pages use?
Location pages should use a short, predictable URL pattern under one folder, such as /locations/denver/ or /locations/denver-highlands/ for cities with several branches. A consistent pattern makes the site easy to navigate, easy to maintain and easy for search engines to understand.
- Single branch per city: /locations/city/
- Several branches in one city: /locations/city-neighborhood/ or /locations/city/neighborhood/
- Regions with many branches: an optional region page, /locations/region/, listing the branches in that area
- Locator page: /locations/ with a search by ZIP or city, a list of every branch and links to each page
Keep URLs stable. If a branch moves address within the same town, keep the URL and update the content. If a branch closes, redirect its page to the nearest open branch or the locator page, and say clearly that it has closed.
What goes in a location page template?
A location page template contains fixed brand blocks that repeat on every page and unique blocks that each branch must fill in. The table below is the template we'd start from for a service or retail business; adjust the fields to your industry.
Block | Shared or unique | What it contains |
|---|---|---|
Header and primary action | Unique data, shared layout | Branch name, tap-to-call number, book or quote button |
Address, map and hours | Unique | Full address, map link, weekly and holiday hours |
Local intro | Unique | Two or three sentences on this branch: area served, what's special here |
Services offered here | Shared list, unique selection | Services available at this branch, linked to service pages |
Team | Unique | Manager and key staff with photos and short bios |
Local reviews | Unique | Reviews from this branch's customers, linked to its profile |
Photos | Unique | Exterior, interior, team; helps people recognize the place |
Practical details | Unique | Parking, transit, accessibility, nearby landmarks |
Local FAQ | Mostly unique | Questions specific to this branch, such as parking or availability |
Brand promise and booking | Shared | Guarantees, booking widget, nearby branches |
How do you set up location pages in a CMS?
Set up location pages in a CMS as a collection where each item is a branch, with structured fields for every piece of data and a single page template that renders them. Structured fields beat a free-text body because they keep pages consistent, feed the locator and structured data, and let you update hours across the site in one place.
Define the collection
Create a Locations collection with fields for name, slug, address parts, coordinates, phone, email, weekly hours, holiday hours, booking link and profile link.
Add unique content fields
Local intro, team members (linked to a Staff collection), photo gallery, practical details and local FAQ items. Mark the important ones as required.
Connect services
Link each location to the services it offers via a reference field, so service pages can show where they're available and location pages can list services.
Build the template
Design one page layout that renders every field, hides empty optional blocks gracefully, and keeps the call and booking actions visible on mobile.
Build the locator
A /locations/ page that lists every branch from the same collection, with search by city or ZIP and a map if it helps.
Set permissions and review
Give local managers access to their own branch's hours, team and photos, and keep the template and brand blocks with head office.
Framer, Webflow and headless CMSs behind Next.js can all handle this. The deciding factors are how many locations you have, how often data changes and whether hours should sync from another system. Large networks with frequent changes tend to suit a headless setup; our guide to multi-page website pricing shows how page count affects the build.
How do location pages connect to Google Business Profile and schema?
Each location page should be the website link on that branch's Google Business Profile, and each page should carry its own structured data describing that branch. That way, search engines connect the profile, the page and the branch details as one record.
Use the same branch name, address, phone number and hours on the page, the profile and the main directories. Mark up each page with LocalBusiness structured data, or a more specific type such as Dentist or Restaurant, including the address, phone, opening hours and coordinates, all generated from the CMS fields so they never drift from what's shown on the page. Google's documentation on local business structured data lists the supported properties.
Hypothetical example: the CMS record for one clinic branch
For example, suppose a physiotherapy group has nine clinics. One collection item looks like this: name "Riverside clinic", slug riverside, full address and coordinates, phone, weekly hours plus two holiday closures, booking link, and the link to its own Google Business Profile. Unique fields include a three-sentence local intro mentioning the free parking and the riverside path, the clinic lead and three physiotherapists from the Staff collection, six photos, three local FAQ items and the services offered there. The template renders it all, the locator lists it, and the structured data is built from the same fields. This is an illustration, not a real business.
How do franchise location pages differ?
Franchise location pages follow the same template but need clearer rules on who controls what, because franchisees often want their own pages and the brand needs consistency. The answer is shared control: head office owns the template, brand blocks and service descriptions, and franchisees own their local fields.
Set permissions so franchisees can edit hours, team, photos, local intro and local FAQ, but not the layout or brand claims. Add a light review step for local text, especially claims about prices, guarantees or results. Make sure every franchisee's Google Business Profile points to its page on the main site rather than a separate microsite, which splits authority and confuses customers. Our guide to multi-location gym and franchise websites covers this for fitness brands specifically.
How do location pages fit into the rest of a website?
Location pages should sit in the site structure as a clear branch of the navigation, linked from the header, the footer, every relevant service page and the locator. They shouldn't float on their own, reachable only through search.
Link each location page to the services it offers, and each service page to the locations where it's available. Add a "Nearby locations" block on each page so visitors who land on the wrong branch can find the right one. Plan this in your sitemap before design starts; our sitemap template is written for SaaS sites, but the hierarchy principles apply. For single-site businesses with several service areas rather than branches, use service area pages instead, as covered in our checklist of service business website pages. Restaurant groups should also read our guide to restaurant website design, which covers per-location menus and booking.
Write the local intro and FAQ answers in an answer-first style, so each block makes sense if lifted out on its own. Our guide to answer-first page structure explains how.
