Multi-location businesses often make one schema mistake that creates confusion across the entire website: they copy the same LocalBusiness markup onto every location page and change only the city name—or sometimes change nothing at all.
That is not a multi-location LocalBusiness schema strategy. It is duplicated business data.
The better structure is one real location, one indexable page and one unique entity describing the branch’s actual address, phone, hours, coordinates and URL. Each branch then connects to the parent brand.
Google’s LocalBusiness documentation explicitly says to define each local business location as a LocalBusiness type and use the most specific accurate subtype available.
Direct answer: Create one indexable page for every genuine branch, store, clinic or customer-facing office. Add one location-specific LocalBusiness JSON-LD entity to that page, give it a unique @id, and connect it to the homepage’s parent Organization entity with parentOrganization. The schema must match the visible page and the real location.
What LocalBusiness schema does—and does not do
LocalBusiness describes a particular physical business or branch through facts such as its name, address, phone, hours, category and geographic position.
It can improve entity clarity and support applicable search features. It does not:
- Create a legitimate business location
- Make a virtual office eligible for local visibility
- Replace Google Business Profile or a useful location page
- Fix inconsistent NAP information elsewhere
- Make duplicate city pages valuable or guarantee rankings, rich results or leads
Schema describes reality; it does not create reality. It should be one layer in a broader multi-location local SEO system.
The correct multi-location entity structure
Use the homepage for the parent Organization and each location page for a distinct LocalBusiness—preferably a specific subtype such as Dentist, Restaurant or AutoRepair.
Parent Organization — homepage — #organization
├── Austin location — /locations/austin/ — #localbusiness
├── Dallas location — /locations/dallas/ — #localbusiness
└── Houston location — /locations/houston/ — #localbusiness
Each branch should have:
| Asset or property | Requirement |
| Location page | Unique, crawlable, indexable canonical URL |
| Entity | One location-specific LocalBusiness object |
| @id | Unique, stable URL-based identifier |
| NAP and hours | Exact branch name, address, phone and hours |
| Geo | Verified latitude and longitude |
| Type | Most specific truthful Schema.org subtype |
| Parent link | Reference to the main Organization @id |
| Platform data | Consistent with Google, Apple, Bing and key citations |
Do not add every branch’s full markup to every page. The Austin page should describe Austin; the hub can link to all branches.
Organization vs. LocalBusiness schema
| Page or business situation | Recommended focus | Why |
| Brand homepage | Organization | Defines the parent brand and its primary identity |
| Customer-facing headquarters | Organization plus an accurate HQ LocalBusiness, if clearly represented | Separates the brand from the location |
| Individual branch page | Most specific LocalBusiness subtype | Defines one physical branch |
| Location finder or hub | Parent organization and links to branch pages | Helps users navigate without duplicating every entity |
| Service-area business without a public office | Organization with truthful service information | Does not imply a visitable address |
| Distinct department within a larger business | department nested under the main location | Represents different hours, phone or operations at one address |
Google’s Organization guidance permits multiple addresses for organizations in multiple cities, states or countries. This does not replace location-specific entities for individual branches.
Build useful location pages before adding schema
A technically valid JSON-LD block cannot rescue a thin page. Each location page should visibly provide:
- Business or branch name, full address and public phone number
- Regular and special opening hours
- Services genuinely available at that branch
- Useful map, directions, access details and authentic photos
- Booking, appointment, quote or contact action routed to the correct location
- Relevant local information and service-page links
Do not create entities for PO boxes, mailboxes, staffless addresses, virtual offices or remotely served cities.
When launching a real branch, use this new-business-location SEO checklist before publishing the page and markup.
Managing several branches? Download the Multi-Location Schema Checklist to review page structure, NAP data, unique IDs, platform alignment and validation before a site-wide rollout.
Core LocalBusiness schema properties
Google requires name and address for LocalBusiness rich-result eligibility and recommends other applicable properties:
| Property | Purpose | Example |
| @context | Establishes Schema.org vocabulary | https://schema.org |
| @type | Identifies the business category | Dentist, Restaurant, AutoRepair |
| @id | Gives the branch a stable identifier | https://example.com/locations/austin/#localbusiness |
| name | States the real location name | Example Dental — Austin |
| url | Points to the branch’s canonical page | Fully qualified location URL |
| telephone | Provides the public contact number | Include country and area code |
| address | Defines the physical location | Complete PostalAddress |
| geo | Defines the verified map coordinates | GeoCoordinates |
| openingHoursSpecification | Defines branch-specific hours | Day and 24-hour time values |
| parentOrganization | Links the branch to the main brand | Parent Organization @id |
| image | Represents the actual branch | Crawlable, relevant image URL |
The url should be the fully qualified URL of the specific location, not automatically the homepage.
Use the most specific accurate subtype
Examples include Dentist, MedicalClinic, Restaurant, HairSalon, AutoRepair, Hotel and LegalService.
The specific type already inherits from LocalBusiness; adding both is unnecessary. Choose the type for accuracy, not perceived ranking value.
Location-specific LocalBusiness JSON-LD template
This is a planning template, not production code to paste across every branch. Replace every value with verified, visible location data.
{
“@context”: “https://schema.org”,
“@type”: “LocalBusiness”,
“@id”: “https://www.example.com/locations/austin/#localbusiness”,
“name”: “Example Business — Austin”,
“url”: “https://www.example.com/locations/austin/”,
“telephone”: “+1-512-555-0100”,
“image”: “https://www.example.com/images/austin-location.jpg”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main Street, Suite 200”,
“addressLocality”: “Austin”,
“addressRegion”: “TX”,
“postalCode”: “78701”,
“addressCountry”: “US”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: 30.26720,
“longitude”: -97.74310
},
“openingHoursSpecification”: {
“@type”: “OpeningHoursSpecification”,
“dayOfWeek”: [
“Monday”,
“Tuesday”,
“Wednesday”,
“Thursday”,
“Friday”
],
“opens”: “09:00”,
“closes”: “17:00”
},
“parentOrganization”: {
“@id”: “https://www.example.com/#organization”
}
}
Replace the generic LocalBusiness type with a current, specific subtype when one accurately fits. Do not use the deprecated generic ProfessionalService type. Use parentOrganization to connect a branch to the brand; the older branchOf property is superseded.
Homepage parent Organization example
{
“@context”: “https://schema.org”,
“@type”: “Organization”,
“@id”: “https://www.example.com/#organization”,
“name”: “Example Business”,
“url”: “https://www.example.com/”,
“logo”: “https://www.example.com/images/logo.png”,
“subOrganization”: [
{
“@id”: “https://www.example.com/locations/austin/#localbusiness”
},
{
“@id”: “https://www.example.com/locations/dallas/#localbusiness”
}
]
}
Homepage and branch markup can reference the same stable IDs in separate JSON-LD blocks.
Keep visible NAP, schema and listings aligned
Google’s structured-data policies require markup to represent the visible page accurately. For every location, compare:
| Source | What must align |
| Location page | Name, address, phone, hours, services and URL |
| JSON-LD | The same visible location facts |
| Google Business Profile | Real-world branch details and correct landing page |
| Apple Business | The same location identity and customer information |
| Bing Places | The same location identity and customer information |
| Citations and booking systems | Correct NAP, branch and customer route |
Use the NAP and local business schema guide for the wider process. For individual platforms, see the Google Business Profile setup guide, Apple Business Connect vs. Google Business Profile and the Bing Places guide.
With call tracking, document the canonical number and branch routing. Schema should not introduce a number customers cannot see or use.
Service areas, departments and practitioners
Service-area businesses
Do not create a LocalBusiness for every city served. Describe genuine coverage with visible copy and restrained areaServed data without implying a public office.
Departments at one address
Use department only for units with genuinely different names, phones, hours or operations—not to manufacture entities.
Practitioners and franchises
Create practitioner entities only for real professionals on relevant pages. For franchises, preserve local operational facts and connect the branch to the parent brand.
Common multi-location schema mistakes
| Mistake | Better implementation |
| Same JSON-LD on every branch page | Generate one unique entity per location |
| Same @id reused across locations | Create one stable URL-based ID per branch |
| Headquarters address or hours copied everywhere | Use actual branch data |
| Every location marked up on every page | Mark up the location the page describes |
| Fake locations or city entities | Use only genuine physical branches |
| Inaccurate coordinates | Verify the pin and coordinates manually |
| Invisible schema contradicts the page | Update the page and markup together |
| Self-serving rating markup | Do not add review stars for your own business merely to influence results |
| Schema treated as a ranking guarantee | Measure it as an entity-clarity and data-quality layer |
Google’s current LocalBusiness documentation recommends review and aggregateRating only for sites that capture reviews about other local businesses. Your own Google rating is not a shortcut to star markup on your branch pages.
Validation and rollout process
- Complete one representative location. Confirm visible NAP, services, canonical URL and conversion route.
- Validate the code. Use Schema Markup Validator for vocabulary and Rich Results Test for Google-supported features.
- Inspect rendered output. Confirm the CMS uses current branch data, not cached headquarters data.
- Test edge cases and IDs. Include different hours, phones or subtypes and search for duplicate @id values.
- Deploy in batches. Re-crawl pages, record the release and monitor Search Console.
- Audit quarterly and after changes. Recheck openings, closures, moves, rebrands and system migrations.
After rollout, connect QA to local SEO performance by location. Calls, forms, bookings and directions are the real success measures.
Multi-location schema checklist
<a id=”multi-location-schema-checklist”></a>
Entity structure
- Parent Organization exists on the homepage
- Every genuine branch has an indexable location page
- Every branch has one specific LocalBusiness entity
- Every location @id is unique and stable
- Each branch references the parent organization
Location accuracy
- Name, address, suite, phone and hours match the visible page
- URL points to the canonical location page
- Geo coordinates match the actual map pin
- Services, subtype and images are accurate for the branch
- Booking and contact actions route to the correct team
Platform and technical QA
- Website, Google, Apple, Bing and key citations align
- JSON-LD is valid and present in rendered HTML
- No duplicate IDs, fake locations, hidden conflicting data or self-serving ratings
- Representative pages pass manual and automated tests
- Search Console and location performance are monitored after launch
Frequently asked questions
Should every location have its own LocalBusiness schema?
Yes. Give every genuine branch a location-specific entity on a useful page with matching visible data.
Can I use one LocalBusiness block for all locations?
No. Each branch needs its own address, phone, hours, URL, geo data and @id.
Should the homepage use Organization or LocalBusiness?
Use Organization for the parent brand. Add a separate LocalBusiness only if the homepage clearly represents a customer-facing headquarters.
What is the best @id format?
Use a stable URL-based identifier such as https://example.com/locations/austin/#localbusiness.
Does LocalBusiness schema improve local rankings?
It can clarify the location and support applicable features, but it does not guarantee Maps rankings or leads.
Can I add every city I serve?
No. Do not create fake location entities for service areas. Describe only genuine coverage and avoid using schema as a shortcut for city rankings.
Should the schema match Google Business Profile?
Yes. Core location facts should be consistent across the visible page, markup, Google Business Profile, Apple Business, Bing Places, booking platforms and authoritative citations.
Build a location entity system, not a copied template
The purpose of multi-location schema markup is not to place more code on more pages. It is to give every real branch a clear, accurate identity and connect those identities to one parent brand.
Start with useful location pages. Assign stable IDs. Use the most specific accurate subtype. Keep visible NAP data, structured data and major listings aligned. Then validate the template against real operational differences before scaling it across the site.
Need a clean rollout? Download the Multi-Location Schema Checklist to audit page structure, location data, IDs, platform consistency and validation. If you need help reviewing the full system, book a Local Visibility Audit.
About Elham
Elham is an SEO, local SEO and growth strategist with more than 10 years of experience helping businesses improve search visibility, location architecture, Google Maps presence, structured data and qualified-lead measurement. She helps multi-location brands connect technical SEO, local listings, content and analytics into practical growth systems.