Running one location is a solved problem. Add four more and the same tactics start working against you. Two branches compete for the same search, a templated page gets treated as duplicate content, and the Google Business Profile that used to rank quietly slides down. The frustrating part is that most of the damage comes from decisions made in a sitemap document months earlier, by someone reasonably choosing what looked tidiest at the time.
Multi location website SEO works when every branch gets its own indexable page with genuinely unique content, a consistent name, address and phone across the web, LocalBusiness schema per location, and a URL structure that keeps cities separate. Duplicated templates and single pages listing every city are the two failures that stop rankings.
Why do location pages compete with each other?
Search engines pick one page per site for most queries. Give them five pages that say roughly the same thing with the city name swapped, and they will either pick the wrong one or trust none of them. Internally this shows up as rankings that flicker between pages week to week, or as a single page absorbing all the local queries for towns it does not serve.
The root cause is almost always production method. A page built by find and replace has no reason to rank in one city over another, because there is nothing in it that belongs to that city. Add in near identical title tags, the same body copy, the same photos, and you have built the textbook version of the problem.
Genuine differentiation is the fix, and it is more work than templating but less than people fear. Each page needs facts that only apply to that branch. Staff names. The actual services offered there, which are rarely identical across branches. Local landmarks and the parking situation. Opening hours that differ. Reviews from customers of that location. Photos taken at that location, not the stock interior used on all five.
We send each branch manager a short form: five questions about services, quirks, local competitors and typical customers, plus a request for ten photos from a phone. It takes them twenty minutes and gives us enough raw material to write pages that cannot be mistaken for each other.
Which URL structure should you use?
There are four workable patterns and one that is not. Choose based on how many locations you have, whether services differ between them, and whether each branch operates as a distinct business in the customer's mind.
| Structure | Example | Works well when | Downside |
|---|---|---|---|
| Subfolder by city | /locations/austin/ | Most businesses, 2 to 200 branches | Needs discipline to keep content distinct |
| City plus service subfolders | /locations/austin/emergency-plumbing/ | Services differ by branch and each has search demand | Page count multiplies fast, thin pages appear |
| Flat city pages | /austin-office/ | Small counts, under roughly ten locations | Root gets cluttered as you grow |
| Subdomain per city | austin.example.com | Locations run as separate operations with own teams | Authority is split, more technical overhead |
| Separate domain per city | exampleaustin.com | Franchise with genuinely independent ownership | Every domain starts from zero, expensive to maintain |
Subfolders under a locations hub are the default recommendation for good reason. Everything sits on one domain, internal linking is simple, and a hub page gives search engines and users a clean map. Subdomains and separate domains only make sense when the business really is separate, and even then the cost is real. We have seen franchise groups running thirty domains where a single site with thirty folders would have ranked better and cost a fraction to maintain.
Whichever you choose, keep the pattern consistent. Mixed structures, where some cities live in folders and others at the root because they were added by different people over the years, create crawl confusion and internal linking that nobody can maintain.
What does a location page need to be genuinely unique?
Aim for at least 400 to 600 words of content that could not appear on another location page, plus the structural elements a local searcher needs. In our project work the pages that hold rankings share the same anatomy.
- A heading that names the service and city naturally, without keyword stuffing.
- Name, address and phone in text, not inside an image, matching your Google Business Profile exactly.
- An embedded map plus written directions, including the landmark people actually use.
- Hours for that branch, including holiday variations if they differ.
- The specific services offered there, and honest notes about what is not available at that location.
- Named staff, with photos where people are willing.
- Reviews or testimonials from customers of that branch.
- Photos of that building, inside and out, with descriptive file names and alt text.
- Parking, transit and accessibility detail, which is the most read and least written section.
- A location specific contact method, ideally a tracked number that routes to that branch.
Local context beats padded prose. A paragraph about the neighbourhood the branch serves, the events it sponsors, or the seasonal patterns it deals with is worth more than four paragraphs of generic service description that also appears on nine other pages.
How much does NAP consistency really matter?
Name, address and phone consistency is unglamorous and still one of the highest return jobs in local SEO. Search engines cross reference your details across directories, maps, aggregators and social profiles. Conflicting versions reduce confidence, and reduced confidence shows up as lower map pack placement.
The inconsistencies are usually mundane. Suite numbers written three ways. St versus Street. An old phone number surviving on a directory nobody has logged into since 2019. A location that moved two blocks and left a trail of the old address behind it. Pick one canonical format, write it down, and use it everywhere, including on the website footer and inside your schema.
Then audit. Search your phone number in quotes and see what comes back. Check the big aggregators, the industry directories that matter in your sector, and any franchise or partner listings. Fix the wrong ones and claim the duplicates. This is tedious and delegatable, and it moves rankings more reliably than another round of on page tweaking.
We build a single source of truth spreadsheet with the canonical name, address, phone, hours and geo coordinates per branch, then generate the website pages, schema and directory submissions from it. When a branch changes hours, one row changes and everything downstream follows.
How should schema handle multiple locations?
Each location page gets its own LocalBusiness markup, or the more specific subtype that fits your sector, such as Dentist, Restaurant or AutoRepair. Include the name, full postal address, telephone, geo coordinates, opening hours specification, the URL of that page and a unique identifier. Do not put every branch into the markup on a single page and expect it to work.
Two extra pieces help. Use the parentOrganization property to connect each location to the main company entity, and mark up the organisation once on the homepage or about page with sameAs links to your verified profiles. Where a branch serves a wider region than its address suggests, areaServed communicates that without you inventing pages for towns you have no presence in.
Validate what you publish, and keep the markup synchronised with the visible content. Hours in schema that disagree with hours on the page are worse than no markup at all, because the discrepancy erodes trust in everything else you declare.
What are the mistakes that keep costing rankings?
The first is one page listing every city. It looks efficient and it ranks for nothing, because a page mentioning twelve towns is not the best answer for any of them. Split it.
The second is spinning up pages for cities where you have no presence. Doorway pages built around we serve Plano, Frisco and Allen with no address, no staff and no reviews are exactly what quality systems are designed to catch. If you genuinely serve a region without an office there, say so on the nearest branch page using service area language rather than manufacturing a fake location.
The third is orphaned pages. Location pages linked only from a dropdown menu, or from a hub page that itself sits three clicks deep, get crawled rarely and rank poorly. Link them from the footer, from a proper locations hub, and from relevant service pages.
The fourth is neglecting the Google Business Profile while polishing the website. For local queries the profile often outweighs the page. Categories, photos, posts, product listings and a steady flow of reviews all matter, and the profile should point to the specific location page rather than the homepage.
The fifth is treating this as a one time project. Locations open, close, change hours and change managers. A structure that was accurate at launch drifts within a year. Someone needs to own it, and the ownership question is worth settling during the build phase rather than after handover. It is also worth aligning with whoever runs your local paid campaigns, since location pages usually double as landing pages for geo targeted ads, and the same page then has to satisfy both an organic reader and a paid click. Where those goals conflict, ordinary conversion testing on the contact section settles it faster than argument.
Frequently asked questions
Should each business location have its own page?
Yes. Every physical location with an address, staff and hours should have its own indexable page. One page listing several cities competes with itself and rarely ranks well for any. The exception is a service area business without premises, where a single honest coverage page works better than invented location pages.
How do I stop location pages cannibalising each other?
Give each page material that only belongs to that branch: its staff, its reviews, its photos, its hours, parking notes and the services actually offered there. Write unique titles and descriptions, link every page from a locations hub, and never reuse one body of copy with only the city name changed.
What URL structure is best for multiple locations?
City subfolders under a locations hub, for example /locations/austin/, suit most businesses from two to two hundred branches. Authority stays on one domain and internal linking stays simple. Subdomains or separate domains only make sense when branches genuinely operate independently, since each one has to build authority from nothing.
How much unique content does a location page need?
Roughly 400 to 600 words that could not appear on any other location page is a workable target, alongside the structural elements local searchers need. Substance matters more than length. Two paragraphs of genuine local detail outperform six paragraphs of generic service copy repeated on every branch page.
What schema should multi location websites use?
Each location page needs its own LocalBusiness markup, or a more specific subtype like Dentist or Restaurant, including name, full address, phone, geo coordinates, hours and the page URL. Link each to the parent company with parentOrganization, and mark up the organisation once with sameAs links to verified profiles.
Can I create pages for cities where I have no office?
Creating location pages for cities where you have no presence is a doorway page tactic that quality systems are built to detect. If you genuinely serve a wider region, describe the coverage on the nearest branch page and use the areaServed schema property. Honest coverage outlasts manufactured city pages.
The takeaway
Structure first, content second, maintenance forever. Pick one URL pattern and hold to it, give every branch page facts that belong only to that branch, keep name, address and phone identical everywhere, and mark up each location individually. Then assign an owner, because branches change and a location structure that nobody maintains quietly decays into the duplicate content problem you started with.