For businesses with more than one physical address, the best approach is one LocalBusiness JSON-LD entity per location, placed on that location’s own page, using Schema as your field reference. Service-area businesses without a public storefront should skip the street address and use areaServed instead. JSON-LD is the format Google Search Central recommends for all of it.
TL;DR:
- Each page needs the exact business name, address, phone, canonical URL, hours when set, and coordinates that match its Google Business Profile listing.
- Businesses without public storefronts should omit street addresses and define actual coverage through areaServed, using cities, ZIP codes, or GeoShape.
- Assign every location node a unique @id or branchCode; never pool reviews across branches, because that can disqualify the location pages involved.
- Validate templates in staging, fix blocking errors before launch, then monitor Search Console weekly and synchronize schema with Google Business Profile periodically.
- Chains should maintain one canonical location dataset and generate pages from a template, so updates to hours and phone numbers propagate consistently.
Table of Contents
- How we structure sites and schema for multi-location businesses
- LocalBusiness fields every location page needs
- Marking up service-area and mobile businesses
- Copy-ready JSON-LD examples for locations and service-area businesses
- Testing and monitoring your schema over time
- Rolling out location schema across dozens of pages
- What we see go wrong most often
- Scaling location schema without the manual work
- FAQ
- Sources
How we structure sites and schema for multi-location businesses
Every physical location gets its own page, and every page gets its own LocalBusiness JSON-LD node. That’s the default we build toward, and it’s not just a schema preference. Google’s structured data guidelines expect each location to be represented as its own entity, which means cramming five branches into one array on a single page creates ambiguity about which address, phone number, and hours belong to which business.
A clean URL pattern makes this easier to maintain: /locations/austin-tx/ or /locations/branch-name/ keeps each page canonical and easy to template. When a page’s URL is unique and stable, the JSON-LD embedded on it inherits that clarity, and search engines stop guessing which node maps to which result.
We also treat node identity as a first-class concern. Each location’s JSON-LD should carry a unique @id or branchCode so nothing gets merged or confused during indexing, especially once you’re managing dozens of pages built from the same template.
- Give each physical location its own URL and its own JSON-LD node, never a shared array.
- Use a consistent URL pattern like
/locations/city-name/across every branch page. - Assign a unique
@idorbranchCodeto each node to prevent collisions. - Avoid embedding multiple LocalBusiness entities on one page unless they’re clearly nested under a parent organization.
LocalBusiness fields every location page needs
Google’s structured data documentation lists specific fields it expects for LocalBusiness rich results eligibility, and treating this as a checklist saves you from half-finished markup that never qualifies for enhanced display.
- name: the exact business name, matching your Google Business Profile listing.
- address: a full PostalAddress object with street, city, region, postal code, and country.
- telephone: including the country code, formatted consistently across every location.
- url: the canonical URL of that specific location’s page, not your homepage.
- openingHoursSpecification: structured hours, included whenever your business has set hours.
- geo: latitude and longitude, ideally to five or more decimal places for accuracy.
- image, hasMap, sameAs: recommended extras that strengthen eligibility for enhanced results.
- branchCode or globalLocationNumber: useful identifiers for chains, drawn from schema.org’s LocalBusiness properties.
Formatting consistency matters as much as field completeness. Keep addressCountry in ISO format, keep postal codes exact, and make sure every phone number and business name matches your Google Business Profile listing character for character.
Pro Tip: Mismatched NAP (name, address, phone) between your schema and your Google Business Profile is one of the fastest ways to undercut local ranking signals you’ve already earned.
Marking up service-area and mobile businesses
If you run a plumbing company, a mobile detailing service, or any business that serves customers without inviting them to a storefront, your schema needs a different shape. Google’s guidance is direct here: when there’s no public-facing address, omit streetAddress entirely and rely on areaServed to define your coverage.
areaServed can be expressed as a list of city names, a set of ZIP codes, or a GeoShape with a radius for broader territories. Whatever shape you choose, it needs to match what’s publicly listed on your Google Business Profile and directory citations. For deeper guidance on structuring these pages themselves, this breakdown of service area pages covers the content side of the equation well.
- Omit
streetAddresswhen you don’t operate from a public storefront customers can visit. - Use city names or ZIP codes for simple coverage areas,
GeoShapefor larger or irregular territories. - Match your schema’s service area to what’s listed on your Google Business Profile, not an aspirational territory.
- Never fabricate a street address just to satisfy a LocalBusiness template built for storefronts.
Copy-ready JSON-LD examples for locations and service-area businesses
A minimal single-location example looks like this:
{ “@context”: “https://schema.org”, “@type”: “LocalBusiness”, “@id”: “https://example.com/locations/austin-tx/#business”, “name”: “Example Co. - Austin”, “address”: { “@type”: “PostalAddress”, “streetAddress”: “123 Main St”, “addressLocality”: “Austin”, “addressRegion”: “TX”, “postalCode”: “78701”, “addressCountry”: “US” }, “telephone”: “+1-512-555-0100”, “url”: “https://example.com/locations/austin-tx/”, “geo”: { “@type”: “GeoCoordinates”, “latitude”: 30.26759, “longitude”: -97.74299 } }
For a service-area business, drop streetAddress and add areaServed:
“areaServed”: [“Austin, TX”, “Round Rock, TX”, “Cedar Park, TX”]
Pro Tip: Every location node needs its own @id and, where you have one, its own branchCode. Reusing the same @id across pages is the most common reason multi-location schema gets ignored at scale. For more worked examples across business types, our guide to LocalBusiness schema examples walks through several variations.
Testing and monitoring your schema over time
Before anything goes live, run it through the schema markup validator to catch syntax errors, then through Google’s Rich Results Test to confirm eligibility for enhanced display. Search Console’s structured data reports become your ongoing monitor after launch.
- Test every template in staging first, not after it’s already indexed across fifty location pages.
- Fix blocking errors immediately; these prevent rich results from appearing at all.
- Review warnings on a slower cadence; they flag missing recommended fields rather than disqualifying errors.
- Check aggregateRating and review markup separately: Google’s review snippet guidelines require ratings to be tied to the specific location, and aggregating reviews across branches risks disqualifying every location page involved.
Our SEO audit checklist for local service businesses covers the broader technical items worth checking alongside structured data.
Rolling out location schema across dozens of pages
Scaling past a handful of locations turns schema from a one-time task into an operational process.
- Build a canonical data source first: name, address, phone, hours, geo coordinates, and branch codes for every location in one place.
- Create a single page template that injects JSON-LD dynamically from that dataset, with logic that guarantees a unique
@idper page. - Automate generation for chains with many locations rather than hand-coding each page, which is where duplicate IDs and typos creep in.
- Run new or updated pages through staging validation before they go live.
- Set a monitoring cadence, weekly Search Console checks paired with a periodic sync against your Google Business Profile data, so drift between listings and schema gets caught early.
Pro Tip: Treat your location dataset as the single source of truth. When hours or phone numbers change, update it once and let the template push that change everywhere, instead of editing JSON-LD by hand on each page.
What we see go wrong most often
The failures we run into repeatedly aren’t exotic. They’re duplicated @id values across location pages, phone numbers that don’t match between schema and the Google Business Profile, and aggregateRating markup pooling reviews from five branches into one number. Each one is avoidable with a single data source and a template that enforces uniqueness.
Our priority order is always correctness first, consistency second, extras like images and FAQ markup last. Get the required fields right and matched to your listings before chasing enhanced display features. For teams managing many locations, building this kind of discipline into a repeatable local SEO strategy pays off far more than any single schema tweak.
— Cole
Scaling location schema without the manual work
Building correct JSON-LD for one location is straightforward. Doing it accurately for thirty, fifty, or two hundred locations, while keeping every address, phone number, and @id in sync with Google Business Profile, is where most teams lose hours they don’t have.
That’s the problem our platform at Stellor was built to solve. We publish 30 GEO and SEO-optimized pages a month, including location pages with schema already built in, run weekly technical audits that catch structured data errors before they cost you rankings, and track how your business shows up across ChatGPT, Claude, Perplexity, and Gemini so you know where you stand beyond Google alone. One-click fixes mean you’re not waiting on a developer every time a listing changes.
If you’re managing location schema by hand across a growing footprint, our all-in-one GEO + SEO platform replaces that manual process with a managed one, backed by a 4,000-site backlink network and a 3-day free trial with no card required.
FAQ
What is a mapping schema?
A mapping schema generally refers to structured data that defines geographic or location-based relationships between entities, such as linking a business to its coordinates or service area. In the context of local SEO, this usually means geo properties and areaServed fields within LocalBusiness markup, as defined by schema.org.
What is it called when a business has multiple locations?
This is typically called a multi-location business or a multi-unit business, common among franchises, retail chains, and service companies with several branches. Each location is usually represented as its own entity in both Google Business Profile and structured data.
Can I have two locations for my business on Google?
Yes, businesses with genuinely separate physical locations can create a Google Business Profile for each one, provided each listing represents a distinct, legitimate address. Schema markup should mirror this structure, with one LocalBusiness JSON-LD node per location page rather than combining locations into a single listing.
Can you give me an example of schema markup?
A basic example is a LocalBusiness JSON-LD block containing name, address, telephone, url, and geo properties for a single location. Google Search Central’s structured data documentation includes full examples showing the required and recommended fields in context.