Fixing Multi-Location SEO on Your Website

How multi-location websites lose local visibility

Most chains, franchises and practice groups do not have a content problem so much as a plumbing problem. The information exists somewhere, usually in a head-office spreadsheet, but the website does not expose it in a way that search engines can use. The common patterns look like this:

• One "Find us" page for everything. Twelve addresses listed on a single contact page. None of the branches has a page of its own that a Business Profile can link to or that can rank for a search in its town.
• A map with no links. The locator is a JavaScript widget that loads branch pins from an API after the page has loaded. A person can click a pin; a crawler sees an empty <div>.
• Branch pages behind a query string. Each branch opens at /stores?id=317, sometimes with the same title tag on every one, and nothing links to those URLs except the widget.
• Copied branch pages. Every page has the same four paragraphs with the town name swapped. Search engines see a set of near-duplicates and may pick one to show and ignore the rest.
• Homepage markup listing every branch. A single JSON-LD block with an array of twenty addresses, which says nothing clear about any of them.
• Closed branches returning 404. A branch shuts, its page is deleted, and every link and bookmark to it breaks, while the Business Profile still points at the dead URL.

The Business Profile side of this, including business groups, bulk verification and store codes, has its own guide: managing multi-location Business Profiles. Everything below is about the website those profiles link to.

A site structure that scales from three branches to three hundred

Every branch needs one permanent, readable URL. How deep the structure goes depends on how many branches you have.

Some rules that save trouble later:

• Use the place, not an internal code, in the slug. /locations/harrogate-station-parade/ survives a change of store numbering; /store/0317/ tells nobody anything.
• Two branches in one town get a street or district in the slug, and the town page (if you have one) lists both.
• Region pages must earn their place. A region page is useful as a navigation step that lists branches with their key details. It should not pretend to be a location in its own right.
• Keep branch URLs out of query strings. If the platform insists on ?store= parameters for the interactive view, give each branch a clean static URL as well and make that the canonical.

Making the store locator crawlable

An interactive map is good for visitors on a phone who want the nearest branch. It is a poor way to tell a search engine which branches exist. The fix is not to remove the map but to put a plain list of links beside it.

Test what a crawler sees

1. Open your locator page, then open browser developer tools and disable JavaScript (in Chrome, the command menu has a "Disable JavaScript" option), and reload.
2. If the branch names and links vanish, a crawler that does not run scripts sees nothing. Google does render JavaScript, but rendering is deferred, and links that only appear after a search box is used or a map is panned are never discovered.
3. Use URL Inspection in Search Console and view the crawled page to see what Google actually rendered.

What to put in the HTML

Output the branch list on the server, as ordinary anchor links, grouped by region if the list is long:

<section aria-labelledby="all-branches">
  <h2 id="all-branches">All branches</h2>
  <h3>North Yorkshire</h3>
  <ul>
    <li><a href="/locations/harrogate/">Harrogate, Station Parade</a></li>
    <li><a href="/locations/ripon/">Ripon, Market Place</a></li>
  </ul>
  <h3>West Yorkshire</h3>
  <ul>
    <li><a href="/locations/leeds/kirkstall/">Leeds, Kirkstall Road</a></li>
  </ul>
</section>

The map can load from the same data and sit above the list. Links inside map pop-ups are fine as an extra, but should never be the only route to a branch page.

Platform notes

• Locator plugins and SaaS widgets. Many WordPress store-locator plugins and hosted locator services render only in the browser. Check whether yours can generate static branch pages or a server-side list; if not, add the list yourself from the same data.
• Shopify. Branch pages are often easiest as a page template driven by metaobjects, one entry per branch, with the locator listing them.
• Next.js, Nuxt and similar. Generate branch pages at build time or render them on the server, and make the locator index a server-rendered route rather than a client-only component.

Add every branch URL to your XML sitemap as well. A sitemap helps discovery but does not replace internal links, which also tell search engines how the pages relate.

What every branch page needs

Branch pages share a template. They should not share their text. Split the page into fixed elements that every branch has, and branch-specific material that makes each page worth visiting.

Title tags follow a pattern such as Brand, Harrogate Station Parade | Opticians in Harrogate, and the H1 names the branch plainly. Avoid putting a list of neighbouring towns in the title; the page is for the place where the branch is.

LocalBusiness markup per branch

Each branch page carries one LocalBusiness block describing that branch only. The brand is described once, as an Organization with its own @id, and each branch refers to it through parentOrganization. (Schema.org's older branchOf property has been superseded by parentOrganization.)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Optician",
  "@id": "https://example.co.uk/locations/harrogate/#branch",
  "name": "Clearview Opticians Harrogate",
  "url": "https://example.co.uk/locations/harrogate/",
  "telephone": "+44 1632 960412",
  "branchCode": "HGT01",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "7 Station Parade",
    "addressLocality": "Harrogate",
    "postalCode": "HG1 1AA",
    "addressCountry": "GB"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": 53.99312, "longitude": -1.53821 },
  "openingHoursSpecification": [
    { "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00", "closes": "17:30" },
    { "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday", "opens": "09:00", "closes": "16:00" }
  ],
  "parentOrganization": { "@id": "https://example.co.uk/#organization" }
}
</script>

• The @id includes the branch URL, so every branch has a distinct identifier that never collides with another.
• branchCode is a schema.org property for your internal reference. Using the same code as the store code on the branch's Business Profile makes cross-checking easier.
• Departments. A branch with a distinct unit inside it that has its own hours or phone number, such as a hearing centre in an optician, can list it under department as a nested LocalBusiness.
• The homepage carries the Organization block with the logo and sameAs links, not a list of every branch.

The finer points of types, hours and coordinates are the same as for a single business and are covered in the LocalBusiness schema guide.

One source of truth for branch data

With more than a handful of branches, the only reliable way to keep details correct is to hold them in one place and generate everything else from it. The same record should feed the branch page, its markup, the locator list and map, and the sitemap.

A workable data sheet has one row per branch and columns for: branch code, public name, street address, town, postcode, phone, email, latitude, longitude, weekly hours, special hours with dates, services offered, manager name, page slug, Business Profile link, status (open, opening soon, temporarily closed, closed) and date last checked.

• Small estates can keep this as a spreadsheet and update pages by hand, provided one person owns the sheet.
• WordPress sites can model branches as a custom post type with fields, so the template, markup and locator all read the same fields.
• Headless or custom sites can hold branches in the CMS or a JSON file checked into the repository, and build pages from it.

Openings, moves and closures on the website

A redirect to the nearest branch is right when customers of the old branch will realistically use the new one. If the nearest branch is an hour away, a page explaining the closure and listing options is kinder than a redirect that drops people somewhere unexpected.

The fix, step by step