LocalBusiness Schema Across Multiple Locations: The JSON-LD Patterns That Actually Validate

The LocalBusiness schema helps search engines understand each branch, office, store, clinic, or service location on a website. For multi-location brands, the goal is to use a clear and repeatable JSON-LD pattern that matches each real location page.

TL;DR

• Use one LocalBusiness schema block per location page when the page represents one real branch or office.
• Choose the most specific, accurate Schema.org type when possible, but keep the data honest and consistent.
• Validate the template before rollout so one schema error does not spread across dozens or hundreds of pages.

Refresher: which Schema.org types fit which businesses

We use the  LocalBusiness schema when a page represents a real local business location. This may include a store, office, restaurant, clinic, gym, repair shop, dealership, salon, branch, or service business with a public location.

Schema.org defines LocalBusiness as a physical business or branch of an organization. This makes it useful for multi-location websites because each branch can have its own structured data.

The best practice is to use the most specific, accurate business type when one fits. Google’s Local Business structured data guide also recommends using the most specific subtype possible.

For example:

Business type	Schema.org type to consider
Restaurant or cafe	Restaurant, Cafe, or Coffee Shop
Auto repair shop	AutoRepair
Retail store	Store or a more specific store subtype
Hardware store	HardwareStore
Furniture store	FurnitureStore
Gym or fitness center	Exercise Gym or Health Club
Law office	LegalService or Attorney
Real estate office	RealEstateAgent
Plumbing business	Plumber
Electrical business	Electrician

The type should describe what the location actually is. If no specific subtype fits, it is better to use a broader but accurate type than to force the wrong one.

This is also where many schema mistakes begin. A business should not choose a subtype just because it has a better keyword. The schema should describe the real business, not rewrite the business category for SEO.

One LocalBusiness per page vs. an organization with multiple locations

For multi-location websites, we need to separate the full brand from each location.

The homepage usually represents the entire company. A location page represents one branch. A city or state page may list several locations, but it usually does not represent one specific business location.

A clean setup usually looks like this:

• The homepage uses the Organization schema for the full brand.
• Each location page uses a single LocalBusiness schema block for that branch.
• A city, state, or directory page links to location pages instead of trying to describe every branch as the main entity.
• Service-area pages should not invent a storefront if the business does not have a public office there.

This matters because the LocalBusiness schema should support the page’s main purpose. If users land on a branch page, they expect to see the address, phone number, hours, services, and contact details for that branch. The schema should match that same information.

For developers, this structure also makes the schema easier to manage. Each location page can pull from the same CMS fields or location database. That database should include the location name, address, phone number, URL, hours, coordinates, services, and parent brand details.

The most important rule is consistency. The visible page, Google Business Profile, internal location database, and JSON-LD should all describe the same location.

Required and recommended properties

Google’s Local Business structured data documentation explains which properties are required and recommended for LocalBusiness markup. Required fields help identify the business. Recommended fields give search engines more useful details about the location.

For most multi-location pages, we should include:

Property	Why it matters
@context	Tells parsers the vocabulary is Schema.org
@type	Defines the business category
@id	Gives the location a stable entity ID
name	Shows the public name of the location
url	Connects the schema to the location page
telephone	Shows the location’s public phone number
address	Provides the full NAP details
geo	Gives the exact latitude and longitude
openingHoursSpecification	Shows regular business hours
image	Adds a relevant location image
parentOrganization	Connects the branch to the wider brand

The @id is especially useful for multi-location brands. It gives each branch a stable identity in the schema.

A good @id pattern looks like this:

https://www.example.com/locations/midtown/#localbusiness

This should be unique to the location and should not change whenever the page template changes.

The business name should also stay clean. Use the real public-facing name of the location. Do not add extra services, cities, or keywords that are not part of the actual name.

Use a natural name like:

Example Brand – Midtown

Avoid keyword-stuffed names like:

Best Same-Day Repair and Installation Company in Midtown

That second version may look optimized, but it makes the schema less trustworthy. It can also create mismatches between the schema, visible page, and business profile.

Service, Place, OpeningHoursSpecification, GeoCoordinates patterns

LocalBusiness schema often works best when it includes supporting details that make the location clearer. The most common patterns include Service, Place, OpeningHoursSpecification, and GeoCoordinates.

Service

Use Service when the location page lists services available at that branch. 

For example, a home service location may offer installation, repair, inspection, and maintenance. A retail location may offer in-store pickup, consultations, repairs, or delivery support. A clinic may offer appointments, screenings, and other location-specific services.

The key is to keep services specific to the branch. Do not copy every company-wide service into every location page if some locations do not offer them.

For most pages, services can be connected to the LocalBusiness block through makesOffer. This helps show which services are tied to that specific location.

Place

LocalBusiness already acts as both a business and a place in Schema.org. In most cases, we do not need a separate Place object for the same branch.

Place-related details can usually sit inside the LocalBusiness block, including:

• address
• geo
• hasMap
• openingHoursSpecification

Use a separate Place object only when the page describes another location connected to the business, such as an event venue, service destination, or facility that is not the main branch.

OpeningHoursSpecification

OpeningHoursSpecification is used to describe when a place or service is open. For LocalBusiness schema, this usually means regular business hours by day.

This is cleaner than writing hours as plain text inside the schema.

Hours should match the visible page. If the page says the branch closes at 6 p.m., the JSON-LD should not say 7 p.m. If the location is closed on Sunday, do not mark Sunday as open.

For multi-location brands, hours should be managed carefully because different branches may have different schedules. One shared template is fine, but the values should come from each branch’s real data.

GeoCoordinates

Use GeoCoordinates to show the exact location of a branch. This is useful for businesses in shopping centers, office parks, medical buildings, campuses, and dense cities where several branches may be close to one another.

Google recommends using accurate latitude and longitude values for LocalBusiness markup. A city-center coordinate is not enough for a specific location page.

Use coordinates for the actual public location, not the wider service area.

 

Validation tools and common errors

Validation should happen before and after publishing.

Use Google’s Rich Results Test to check whether a page may be eligible for Google rich results. Use Schema Markup Validator to check the broader Schema.org structure.

A practical validation workflow looks like this:

1. Check the JSON-LD syntax before publishing.
2. Test the template in Google’s Rich Results Test.
3. Test the same page in Schema Markup Validator.
4. Publish a small batch of location pages first.
5. Use URL Inspection in Google Search Console.
6. Monitor structured data errors after deployment.
7. Roll out the template to the full location set once it is stable.

This step matters because one template issue can affect every location page using that template.

Common LocalBusiness schema errors

Using one schema block for every location on every page

A location page should describe the location shown on that page. Adding every branch to every page makes the page harder to understand.

Using the wrong business type

The schema type should match the actual business category. A store should not be marked as a restaurant. A service office should not be marked as a retail shop unless customers can actually visit and buy there.

Adding schema that does not match the visible page

Structured data should match what users can see. Do not add hidden hours, hidden reviews, fake service areas, or addresses that are not shown on the page.

Using one phone number for every branch without checking consistency

Some brands use a central call tracking number. That can be acceptable if it is the correct public number for the location. Problems happen when the schema, page, and business profile show different numbers.

Adding review markup without checking eligibility

Google has strict rules around review markup. Brands should be careful before adding review schema to their own location pages, especially if the reviews are first-party or self-serving.

Forgetting seasonal or holiday hours

Regular hours are useful, but wrong hours can create trust issues. If the website shows holiday hours, make sure the schema does not contradict them.

Using weak coordinates

Coordinates should point to the actual branch, not the city, ZIP code, or headquarters.

Code samples for the 5 most common verticals

Instead of using five separate JSON-LD blocks, it is better to use one reusable template and adjust it by business type.

Here is a general LocalBusiness JSON-LD pattern that can work across many location pages. In production, replace LocalBusiness with the most specific accurate subtype when possible.

<script type=”application/ld+json”>

{

  “@context”: “https://schema.org”,

  “@type”: “LocalBusiness”,

  “@id”: “https://www.example.com/locations/midtown/#localbusiness”,

  “name”: “Example Brand – Midtown”,

  “url”: “https://www.example.com/locations/midtown/”,

  “image”: “https://www.example.com/images/midtown-location.jpg”,

  “telephone”: “+12125550124”,

  “priceRange”: “$$”,

  “address”: {

    “@type”: “PostalAddress”,

    “streetAddress”: “123 Main St”,

    “addressLocality”: “New York”,

   “addressRegion”: “NY”,

    “postalCode”: “10001”,

    “addressCountry”: “US”

  },

  “geo”: {

    “@type”: “GeoCoordinates”,

    “latitude”: 40.75050,

    “longitude”: -73.99340

  },

  “hasMap”: “https://www.google.com/maps?cid=0000000000000000000”,

  “openingHoursSpecification”: [

    {

      “@type”: “OpeningHoursSpecification”,

      “dayOfWeek”: [“Monday”, “Tuesday”, “Wednesday”, “Thursday”, “Friday”],

      “opens”: “09:00”,

      “closes”: “18:00”

    },

    {

      “@type”: “OpeningHoursSpecification”,

      “dayOfWeek”: “Saturday”,

      “opens”: “10:00”,

      “closes”: “16:00”

    }

  ],

  “makesOffer”: [

    {

      “@type”: “Offer”,

      “itemOffered”: {

        “@type”: “Service”,

        “name”: “Consultation”

      }

    },

    {

      “@type”: “Offer”,

      “itemOffered”: {

        “@type”: “Service”,

        “name”: “Installation”

      }

    },

    {

      “@type”: “Offer”,

      “itemOffered”: {

        “@type”: “Service”,

        “name”: “Repair”

      }

    }

  ],

  “parentOrganization”: {

    “@type”: “Organization”,

    “@id”: “https://www.example.com/#organization”,

    “name”: “Example Brand”

  }

}

</script>

This template is general on purpose. The structure stays the same, but the business type and supporting details should change based on the location.

Vertical	Use this @type	Adjust these details
Restaurant or cafe	Restaurant or CafeOrCoffeeShop	Add cuisine, menu URL, reservations, and dining hours if accurate
Auto repair shop	AutoRepair	Add services such as diagnostics, oil changes, inspections, or repairs
Retail store	Store or a specific store subtype	Add store hours, departments, product categories, and price range
Home service business	Plumber, Electrician, HVACBusiness, or another subtype	Add service areas, public office details, and branch-specific services
Fitness or wellness location	ExerciseGym, HealthClub, or a relevant subtype	Add class types, appointment options, hours, and location-specific services

Restaurant or cafe locations

For restaurants and cafes, use a food-related subtype instead of the generic LocalBusiness type. Add details like cuisine type, menu URL, and reservation options only if they are accurate and supported by the page.

The schema should match the location page. If one branch has different hours or a different menu, the JSON-LD should reflect that branch, not the whole chain.

Auto repair locations

For auto repair businesses, use AutoRepair when the branch mainly provides repair or maintenance services.

The services should be specific and realistic. Examples may include diagnostics, oil changes, brake repair, inspections, or tire services.

If the location is mainly a vehicle sales branch, a dealership subtype may be more accurate.

Retail store locations

For retail locations, use Store or a more specific store subtype. Examples include HardwareStore, FurnitureStore, GroceryStore, ClothingStore, or ElectronicsStore.

Keep location schema focused on the store itself. Product schema belongs on product pages, not every location page.

Home service locations

For home service brands, choose the most accurate subtype, such as Plumber, Electrician, HVACBusiness, RoofingContractor, or another relevant type.

If the business has a public office, include the real address. If it does not have a customer-facing location, do not create a fake storefront. Use accurate service-area details instead.

Fitness or wellness locations

For fitness and wellness locations, use the subtype that best fits the business. A gym may use ExerciseGym or HealthClub, depending on the page and business model.

Location-specific details may include hours, class types, appointment options, phone number, address, and available services.

Implementation checklist for multi-location teams

Before rolling out LocalBusiness schema across many pages, test the template against real locations.

Use this checklist:

• Each location has one indexable URL.
• The page represents one real branch, office, store, or service location.
• The schema uses the most specific accurate business type.
• The @id is unique and stable.
• The name, address, and phone number match the visible page.
• The hours match the visible page and business profile.
• The coordinates point to the actual location.
• Services are specific to that branch.
• Review markup is used only when appropriate.
• The template validates before full rollout.
• Live URLs are tested after publishing.

For multi-location brands, schema should not be hand-edited page by page. It should come from clean CMS fields or a reliable location database.

That is what makes the setup scalable. The best LocalBusiness schema multi location strategy is consistent, accurate, and easy to update.

FAQ

Should every location page have LocalBusiness schema?

Yes, if the page represents one real local business location and includes matching business details. Use the most specific accurate LocalBusiness subtype when possible.

Should the homepage use LocalBusiness schema?

For a single-location business, LocalBusiness schema on the homepage can make sense. For a multi-location brand, the homepage usually works better with Organization schema, while each branch page uses its own LocalBusiness schema.

 

Can we add all locations to one page with JSON-LD?

You can describe several entities in JSON-LD, but it is not usually the best pattern for local SEO. A dedicated page for each location is clearer for users and search engines.

What is the best JSON-LD pattern for location pages?

Use one LocalBusiness subtype per location page. Include a stable @id, business name, URL, phone number, full address, coordinates, opening hours, and parent organization.

Do we need GeoCoordinates?

They are recommended, not always required. Still, they are useful for multi-location brands because they help clarify the exact location of each branch.

Should we use review schema on location pages?

Only when the reviews are visible, accurate, and eligible under Google’s structured data rules. Many brands should avoid marking up first-party reviews unless they have reviewed the guidelines carefully.

Which validation tool should we use?

Use Google’s Rich Results Test for Google-specific eligibility and Schema Markup Validator for general Schema.org validation. After publishing, use Google Search Console to inspect live URLs and monitor errors.

Sources

• Google Search Central, Local Business structured data
• Google Search Central, Intro to structured data
• Schema.org, LocalBusiness
• Schema.org, OpeningHoursSpecification 
• Google Rich Results Test
• Schema Markup Validator