Multi-Location Schema Audit: Why Franchise Sites Get St...

A business with one location gets schema right about half the time. A business with five locations gets it right almost never.

The pattern is predictable. Someone sets up a LocalBusiness schema block for the main office. They copy it to the other location pages and change the address. They forget to update the phone number on location three. They never add geo coordinates to any of them. The Organization-level schema still references only the headquarters. And nobody realizes that Google sees five pages all claiming to be the same business at slightly different addresses with conflicting phone numbers.

This is not a corner case. It's the default state for franchise, chain, and multi-office businesses.

The LocalBusiness vs Organization hierarchy

Schema.org gives you a clean way to represent multi-location businesses. The parent Organization describes the brand. Each location is a separate LocalBusiness (or a more specific subtype like Restaurant, DentalClinic, or AutoRepair) with its own address, phone, hours, and geo coordinates.

The relationship between them uses parentOrganization on each branch pointing up to the Organization, and department or subOrganization on the Organization pointing down to each branch.

In practice, here's what usually happens instead:

One LocalBusiness for all locations. The homepage has a single LocalBusiness block with the headquarters address. Individual location pages either have no schema at all or duplicate the same block with different addresses but the same @id.

No parent Organization. Each branch has its own LocalBusiness but nothing ties them together. Google doesn't know these five dental offices are the same brand.

Inconsistent @id values. Two location pages use the same @id (usually the homepage URL), which tells Google they're the same entity. They aren't.

Missing areaServed. Service-area businesses that go to the customer (plumbers, HVAC, landscaping) often skip areaServed entirely. Without it, Google has no structured way to know which ZIP codes or cities you cover from each branch.

NAP consistency across branches

NAP stands for Name, Address, Phone. It's the most basic local SEO signal, and multi-location businesses break it constantly.

The business name on the schema for the Portland branch says "Smith Dental." The Salem branch says "Smith Dental - Salem." The corporate page says "Smith Dental Group." Google sees three different business names and has to guess whether they're the same company.

Phone numbers are worse. The schema says one number, the page text says another, and the Google Business Profile has a third. Multiply that by five locations and you have fifteen potential phone number mismatches.

The audit catches these by extracting the name, address, and telephone from every location page's schema and comparing them for consistency. Are all branches using the same brand name format? Do any share a phone number that should be unique? Does the address in the schema match the address visible on the page?

Geo coordinates and service areas

Every LocalBusiness should have geo with latitude and longitude. Every service-area business should also have areaServed listing the geographic regions served.

The geo coordinates problem is straightforward: most sites don't include them. Some CMS platforms auto-fill them from the address via geocoding, but many don't. Missing coordinates mean Google can't verify the location's position on a map, which weakens local pack eligibility.

areaServed is where it gets more interesting. A plumbing company with three branches might serve overlapping territories. Each branch's schema should declare which cities or postal codes it covers. Without this, Google relies on the address alone, which works for storefront businesses but fails for service-area businesses that drive to the customer.

What the audit checks

The Multi-Location / Service-Area Schema Audit runs through a specific checklist for businesses with 2+ locations:

Sitemap crawl. Finds all location pages by parsing the sitemap and identifying pages that contain LocalBusiness schema.
Per-branch schema validation. Each location page gets checked for required properties: name, address, telephone, geo coordinates, openingHoursSpecification, and areaServed.
Organization-level schema. Checks for a parent Organization with subOrganization or department references linking to each branch.
NAP cross-comparison. Extracts name, address, and phone from every branch and flags inconsistencies: different brand name formats, shared phone numbers, missing addresses.
Geo completeness. Flags branches without latitude/longitude and service-area businesses without areaServed.
@id uniqueness. Confirms each branch uses a distinct @id value.
Schema subtype check. Flags branches using generic LocalBusiness when a more specific subtype (Dentist, Restaurant, Plumber, etc.) would be more appropriate.

The whole thing generates an AI fix prompt with the specific issues found, so you can hand it to a developer or paste it into your editor.

Who this is for

This tool is built for agencies managing multi-location clients, franchise operators, and anyone running a business with more than one physical address or service territory.

If you're building local-focused web properties for clients, the structured data layer is where most agencies stop after the first location and never come back. I wrote about this pattern and others in The $20 Dollar Agency for anyone starting a web services practice from scratch.

Run the audit

The Multi-Location / Service-Area Schema Audit takes a URL, finds your location pages, and compares them all. Free, browser-side, no login required.

Fact-check notes and sources

Schema.org LocalBusiness type and properties: schema.org/LocalBusiness
Schema.org Organization type with subOrganization: schema.org/Organization
Google's structured data guidelines for local businesses: Google Search Central - Local Business
areaServed property specification: schema.org/areaServed
GeoCoordinates specification: schema.org/GeoCoordinates

Multi-Location Schema Audit: Why Franchise Sites Get Structured Data Wrong