SEO for a business with many locations: one page per place, done properly
The URL structure, what has to differ on every location page, a profile per site, the locator and internal linking, and the self storage case where all of it bites at once.
Published by AI Knows Us · Updated 13 October 2026
Multi location SEO comes down to one rule applied consistently: every physical location gets its own indexable page, at a predictable URL, carrying information that is only true of that location, and its own verified Google Business Profile. Everything else follows from that. The failure mode is equally consistent: a template with the town name substituted in, forty times. Those pages compete with each other, say nothing a person in that town needs, and get consolidated or dropped. The work is not forty pages of content. It is a structure that scales plus a short, specific, genuinely local block on each page.
This page covers the architecture for many locations. For the single location method, from profile to map pack, see local SEO.
Pick the URL structure once
| Pattern | Use when | Watch for |
|---|---|---|
| /locations/manchester/ | One site per city, one service | Two sites in one city need a branch segment |
| /locations/manchester/trafford-park/ | Several sites per city | Keep the city hub page as a real page, not a redirect |
| /storage-units/manchester/ | The service word carries the search demand | Multiple services need one path each, which multiplies pages |
| Subdomain per city | Separate legal entities or separate systems | Each subdomain builds authority on its own |
Lowercase, hyphenated, no location ID numbers in the path, and never change it later. A location URL is the most redirected URL on a multi site business, because the naming was decided after the first ten openings instead of before.
What has to differ on every location page
- The address and an embedded map, as text in the HTML, not only inside a script.
- A local phone number that rings that site, with call tracking that preserves the real number on the page.
- Opening hours for that site, including the holiday variations, which are the most common inaccuracy.
- Named people. The manager, the team, with photographs taken at that building.
- What is actually available there. Services, unit sizes, stock lines, equipment. A site that does not offer a service should not have that service listed.
- Directions a local would give. The junction, the retail park, the landmark, the bus route, the parking.
- Reviews from that location only. Rolled up company reviews on a branch page read as corporate and convert worse.
- Photographs of that building, inside and out. Stock imagery is the fastest way to look like a template.
A realistic budget is one hundred and fifty to three hundred words of genuinely local text per page, plus the structured facts. That is achievable at forty locations if you write five a week; it is not achievable if you try to write forty long essays.
The locator page and the internal links
- Build a locator page that lists every location as an ordinary HTML link. A map widget that renders links only in JavaScript hides the whole estate from a crawler.
- Group by region or county with a hub page per group, so no page has two hundred links in a list.
- Link each location page to its three nearest neighbours. Real users who found the wrong branch need that, and it distributes signals across the estate.
- Put every location URL in the sitemap, with lastmod kept accurate.
- Link from the service pages to the locations that offer the service, and back.
Internal linking covers the audit that finds orphaned location pages, which is the single most common defect on a large estate.
The markup for a branch
Each location page carries its own LocalBusiness block, with a branch code and a link back to the parent organisation, so the whole estate reads as one company with many sites:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "SelfStorage",
"@id": "https://example.com/locations/manchester/trafford-park/#branch",
"name": "Northvale Storage, Trafford Park",
"branchCode": "MCR-02",
"parentOrganization": {
"@type": "Organization",
"name": "Northvale Storage",
"url": "https://example.com/"
},
"url": "https://example.com/locations/manchester/trafford-park/",
"telephone": "+44 161 496 0120",
"address": {
"@type": "PostalAddress",
"streetAddress": "4 Ashburton Road West",
"addressLocality": "Manchester",
"postalCode": "M17 1RU",
"addressCountry": "GB"
},
"geo": { "@type": "GeoCoordinates", "latitude": 53.4631, "longitude": -2.3261 },
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],
"opens": "08:00",
"closes": "18:00"
}]
}
</script>
On the locator page, declare the estate as a list so a crawler sees the full set in one pass:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "ItemList",
"name": "Northvale Storage locations",
"itemListElement": [
{ "@type": "ListItem", "position": 1,
"url": "https://example.com/locations/manchester/trafford-park/" },
{ "@type": "ListItem", "position": 2,
"url": "https://example.com/locations/manchester/ancoats/" },
{ "@type": "ListItem", "position": 3,
"url": "https://example.com/locations/leeds/holbeck/" }
]
}
</script>
Replace SelfStorage with the type that fits your business. Google's reference for the family is its local business structured data documentation, and LocalBusiness schema explained covers the properties worth filling.
One profile per location, managed as a set
- A separate verified profile for every staffed site, each pointing at its own location page rather than the home page.
- Bulk management once you pass ten locations, through Google's bulk location management, which keeps names, categories and hours consistent from one spreadsheet.
- The same name format everywhere. Google's guidelines for representing your business set out what belongs in the name field, and adding a keyword to it is the most common cause of a suspension on a large estate.
- Categories chosen per site, because branches genuinely differ.
- Reviews answered per location, by someone who works there.
- Citations fixed per location, not per brand. Local citations covers the audit.
The self storage case, where it all bites at once
Self storage searches split three ways, and a site needs a page for each: the facility page for "storage units in Trafford Park", the unit size pages for "10x10 storage unit" and "small storage locker", and the use case pages for "storage during a house move" or "business stock storage". The unit size pages are where storage operators under build, and they are where the price comparison happens.
Four things decide the result. Live unit availability and price on the facility page, because a visitor who has to call to find out leaves. Access hours and drive up access stated plainly. Climate controlled units flagged per site, since not every facility has them. And a reservation flow that works on a phone in one screen. Marketing for storage facilities covers the proximity and phone call side of the same problem.
SEO for a business with many locations: asked and answered
Should every location have its own page even in the same city?
Yes, when each is a real staffed site with its own address. Give the city a hub page as well, and link the hub to each branch.
How do I avoid duplicate content across location pages?
Keep the shared service explanation on the service page and link to it, then fill the location page with facts that are only true of that site. The structured block does the rest.
What about a service area business with no shopfront?
Build pages for the areas you genuinely serve, with evidence of work done there, and configure the profile as a service area business. Do not create an address you do not occupy.
Can one Google Business Profile cover several branches?
Each staffed location needs its own profile to appear in its own map results. One profile for several sites limits you to one location's visibility.
How many location pages can one team maintain?
As many as your data allows. Hours, availability and staff should come from one system and render into the page, so a change is made once. Hand edited location pages stop being accurate at around twenty sites.
Which comes first, the pages or the profiles?
Pages first, so each profile has a specific URL to point at. A profile pointing at the home page wastes the strongest link you control.
The question a locator page cannot answer
A locator page tells a visitor where your branches are. It cannot tell you which of them an assistant recommends when someone near a particular street asks for a self storage unit or a clinic. That decision is made elsewhere, from profiles, reviews and the pages for each place.
Ask the question site by site in ChatGPT, Gemini and Perplexity. The strong locations and the invisible ones will not be what your regional manager expects. AI Knows Us runs the same question for each address across the assistants and logs the sources, so a profile per location can be compared with a reply per location.