Schema markup for multi-location franchise sites

Key takeaways

Schema is how you state facts unambiguously. For a franchise site the most valuable fact is which of your many locations a given page is about, and how it relates to the brand.
Model the brand as an Organization and each location as its own LocalBusiness, linked by parentOrganization — not one giant Organization with a list of addresses.
Use stable @id values as URLs and reference entities by @id instead of repeating them. This is what turns separate snippets into a connected graph.
The most common fatal error is inconsistency between your markup, your Google Business Profile and the visible page. Structured data that contradicts the page is worse than none.
Do not mark up reviews you aggregate yourself onto location pages and present as AggregateRating unless they genuinely meet the guidelines — this is the most frequent cause of a manual action on multi-location sites.

Structured data does one job: it removes ambiguity. A crawler reading a location page has to infer from prose that this page is about one specific branch of a larger brand, at a particular address, with particular hours. Schema states it outright, in a form that does not depend on interpretation.

That has always mattered for rich results. It matters more now, because an AI assistant composing an answer about your brand is doing entity resolution first — working out what your brand is, which locations belong to it, and which facts are reliable. Clean markup is the cheapest way to make that resolution go your way.

The model: one brand, many businesses

The structural decision that determines whether everything else works is how you represent the relationship between the franchisor brand and the individual locations. The correct model is one Organization for the brand and one LocalBusiness per location, each linked to the parent.

The common wrong model is a single Organization on every page carrying an array of addresses. That describes a company with many offices, not a brand with many independently operated locations, and it gives a crawler no way to associate a specific page with a specific place.

Page	Primary type	Key properties
Homepage	Organization	name, url, logo, sameAs, description
Location page	LocalBusiness subtype	name, address, geo, telephone, openingHoursSpecification, parentOrganization, areaServed
Location index	CollectionPage + ItemList	itemListElement referencing each location page
Service page	Service	provider referencing the Organization @id, serviceType
Article	BlogPosting	headline, author, publisher, datePublished, mainEntityOfPage
Any page with an FAQ	FAQPage	mainEntity with Question and acceptedAnswer

Use the most specific LocalBusiness subtype that genuinely applies — HomeAndConstructionBusiness, HealthAndBeautyBusiness, ProfessionalService and so on. Specificity helps, but accuracy helps more: a subtype that does not really describe the business is worse than the generic parent type.

Connecting it with @id

The single technique that separates competent franchise markup from a pile of disconnected snippets is using @id values to build a graph. Every entity gets a stable identifier, and everything that refers to it references that identifier instead of repeating the entity.

Conventions that hold up:

Make every @id an absolute URL with a fragment — the brand as https://example.com/#organization, a location as https://example.com/locations/springfield#business
Never change an @id once published. It is an identity, and changing it breaks every reference to it
Reference, do not duplicate. A location's parentOrganization should be { "@id": "https://example.com/#organization" }, not a second copy of the whole Organization block
Put one @graph per page containing every entity on that page, rather than several separate script blocks that do not know about each other

This is the difference between a crawler seeing forty unrelated businesses that happen to share a name, and seeing one brand with forty locations.

Location pages: the properties that earn their place

A location page carries the markup that most directly affects both local results and what an assistant will say about that branch. Not every property is worth the effort; these are.

address as a full PostalAddress, matching the Google Business Profile character for character. A suite number present in one and absent in the other is the classic silent mismatch
geo with latitude and longitude, which disambiguates locations in dense metros far better than an address string
telephone — the local number, not a central call-tracking number that differs from the profile
openingHoursSpecification, which handles overnight and split hours properly where the shorthand string form does not
parentOrganization referencing the brand @id, which is the property doing the franchise-specific work
areaServed where the location genuinely serves a territory rather than only its address, which is most service-based franchises
sameAs pointing at that location's own profiles — its Google Business Profile, its Facebook page — not the brand's

That last distinction matters and is frequently got wrong. sameAs on a location should reference that location's identities. Pointing every location at the brand's national social accounts tells a crawler that all forty locations are the same entity, which is the opposite of what you want.

What actually breaks

Markup that contradicts the page

Structured data must describe what a visitor can see. Hours in the markup that differ from the hours in the footer, a phone number that appears nowhere on the page, a service listed in schema and not offered — each of these is a guideline violation and, more practically, teaches a crawler that your markup is not reliable.

In a franchise system this usually happens through drift rather than intent: a location changes its hours on its Google profile, the website is generated from a database that was never updated, and the two diverge quietly for a year.

Self-serving review markup

AggregateRating on a location page, built from reviews collected on your own site, is the most reliable way for a multi-location brand to attract a structured data manual action. The guidelines around self-serving reviews are specific and enforcement is not gentle. If ratings live on third-party platforms, leave them there — the aggregation you can safely do is narrower than most brands assume, and it is worth checking current guidance before implementing rather than after.

Copy-paste across locations

Templated markup is correct — that is how you generate hundreds of pages. Templated markup where the variables did not all substitute is the failure: every location carrying the same geo coordinates, or the same @id, because one field was hardcoded in the template. Test more than one location page, and test one from the middle of the list rather than the first.

FAQPage everywhere

FAQPage markup is legitimate where a page genuinely has a question-and-answer section visible to users. It is not a device for adding keywords, and its use as one is why rich result eligibility for it has narrowed. Mark up real FAQs, keep the answers on the page, and do not add an FAQ section to a page purely to carry the markup.

Why this pays off more than it used to

Rich results were the historical reason to invest in structured data, and eligibility for them has narrowed over time. The stronger reason now is entity resolution: assistants and search systems are building a model of what your brand is and which facts about it are trustworthy, and markup is the highest-confidence input they have.

For a franchise brand this is unusually valuable, because the ambiguity is unusually high. Forty locations sharing a name, some independently owned, several in the same metro, a few with near-identical names to unrelated businesses — that is exactly the situation where explicit, consistent, connected markup changes what an assistant is willing to state about you.

The complementary half of that work is on-page: writing passages an assistant can lift and attribute, which is covered in getting cited, not just ranked, and checking what they currently say, which is covered in auditing what AI assistants say about your franchise.

A reasonable implementation order

Organization on the homepage, with a stable @id, correct logo and sameAs for the brand's real profiles
LocalBusiness on every location page, generated from the same data source that feeds the visible page so the two cannot drift
parentOrganization linking each location to the brand
A location index page with an ItemList referencing every location page
FAQPage on pages that genuinely have FAQs, including recruitment pages, where the answers are what an assistant is most likely to quote
Validate every template, then spot-check real pages from across the estate, then re-check after any CMS or template change

Do them in that order. The first three carry most of the value, and a site that does only those three correctly is ahead of most multi-location brands.

Questions we get asked

How should a franchise site structure schema for multiple locations?

One Organization entity for the brand, and a separate LocalBusiness entity on each location page linked back with parentOrganization. Avoid a single Organization carrying an array of addresses — that describes one company with many offices and gives a crawler no way to tie a page to a specific place.

What is the @id property for in structured data?

It is a stable identifier that lets entities reference each other instead of repeating themselves. Use an absolute URL with a fragment, never change it once published, and reference the brand from each location with { "@id": "..." } rather than duplicating the whole Organization block.

Can franchise location pages use AggregateRating markup?

Only where it genuinely meets current guidelines. Self-serving review markup — ratings you collect and publish yourself — is the most common cause of structured data manual actions on multi-location sites. Where ratings live on third-party platforms, leave them there and check current guidance before implementing.

Should each franchise location have its own sameAs links?

Yes. sameAs on a location page should point at that location's own profiles, such as its Google Business Profile and local social pages. Pointing every location at the brand's national accounts signals that all locations are the same entity, which undermines the distinction you are trying to make.

Does schema markup help with AI search visibility?

Indirectly but substantially. Assistants resolve what your brand is and which locations belong to it before composing an answer, and structured data is the highest-confidence input to that process. For a brand with many similarly named locations, it is the clearest way to make that resolution go your way.

Want this mapped to your system?

We will walk your recruitment funnel and your franchisee marketing on one call, and show you where it is leaking. No obligation.

Book a Demo