# Multi-Location Schema Audit: Why Franchise Sites Get Structured Data Wrong Businesses with 2+ locations almost always have schema problems. One LocalBusiness for five branches, missing geo coordinates, NAP drift between pages. Author: J.A. Watte Published: April 29, 2026 Source: https://jwatte.com/blog/blog-tool-multi-location-schema/ --- 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](/tools/multi-location-schema-audit/) runs through a specific checklist for businesses with 2+ locations: 1. **Sitemap crawl.** Finds all location pages by parsing the sitemap and identifying pages that contain LocalBusiness schema. 2. **Per-branch schema validation.** Each location page gets checked for required properties: name, address, telephone, geo coordinates, openingHoursSpecification, and areaServed. 3. **Organization-level schema.** Checks for a parent Organization with `subOrganization` or `department` references linking to each branch. 4. **NAP cross-comparison.** Extracts name, address, and phone from every branch and flags inconsistencies: different brand name formats, shared phone numbers, missing addresses. 5. **Geo completeness.** Flags branches without latitude/longitude and service-area businesses without `areaServed`. 6. **`@id` uniqueness.** Confirms each branch uses a distinct `@id` value. 7. **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](https://www.amazon.com/dp/B0F3J35VMK) for anyone starting a web services practice from scratch. ## Run the audit The [Multi-Location / Service-Area Schema Audit](/tools/multi-location-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](https://schema.org/LocalBusiness) - Schema.org Organization type with subOrganization: [schema.org/Organization](https://schema.org/Organization) - Google's structured data guidelines for local businesses: [Google Search Central - Local Business](https://developers.google.com/search/docs/appearance/structured-data/local-business) - areaServed property specification: [schema.org/areaServed](https://schema.org/areaServed) - GeoCoordinates specification: [schema.org/GeoCoordinates](https://schema.org/GeoCoordinates) ## Related reading - [IndexNow Submission Audit: Stop Waiting for Search Engines](/blog/blog-tool-indexnow/) - [NAP Consistency: The Foundation of Local SEO](/blog/blog-mega-geo-aeo-pill-actions/) - [E-E-A-T Schema and Structured Data Patterns](/blog/blog-eeat-schema-structured-data/) - [Duplicate Title / Meta Description Audit](/blog/blog-tool-duplicate-title-meta/) - [Hotel and Motel Schema Audit](/blog/blog-tool-hotel-motel-audit/) *This post is informational, not SEO-consulting advice. Mentions of Google, schema.org, and third-party platforms are nominative fair use. No affiliation is implied.* --- Canonical HTML: https://jwatte.com/blog/blog-tool-multi-location-schema/ RSS: https://jwatte.com/feed.xml JSON Feed: https://jwatte.com/feed.json Hero image: https://jwatte.com/images/blog-tool-multi-location-schema.webp