LocalBusiness Schema for Service Businesses: A Practical JSON-LD Guide

Overview

LocalBusiness schema can help search engines understand factual information about a real business.

It cannot manufacture a location, create authority that does not exist or guarantee a Map Pack position.

That difference is the foundation of a safe implementation.

For service businesses, the trickiest part is usually not the JSON. It is deciding which real-world entity the markup describes, which facts are public and verifiable, and whether the business actually meets Google’s documented requirements for its LocalBusiness search feature.

What LocalBusiness schema is

LocalBusiness is a Schema.org type for a particular physical business or branch of an organization.

It can describe facts such as:

Google has its own LocalBusiness structured-data documentation for search features. Google’s documentation does not mean every valid Schema.org implementation receives a special search appearance.

Think of this as two overlapping layers:

A markup block can be syntactically valid Schema.org and still fail to satisfy Google’s documented feature requirements.

• business name;
• URL;
• physical address;
• phone;
• opening hours;
• geographic coordinates;
• image;
• price range;
• a more specific business subtype.

1. Schema.org vocabulary defines ways to describe entities and properties.
2. Google Search eligibility adds Google-specific requirements and guidelines for a particular search feature.

What LocalBusiness schema is not

LocalBusiness schema is not:

Structured data should describe what is true on the page and in the real business.

• a guaranteed local-ranking boost;
• a way to rank in a city where the business does not operate;
• a substitute for an accurate Google Business Profile;
• permission to publish a fake address;
• a review-star generator;
• a reason to copy every possible schema property into one giant object;
• a guarantee that Google will display a rich result.

Start with the actual business entity

Before writing JSON-LD, answer:

What real-world entity does this page represent?

For a single-location salon, it may be the salon at that address.

For a company with three independently operating branches, each location is a distinct local-business entity even though they share one brand.

For a mobile service business that does not receive customers at its base, the situation is different because the public location model and Google’s LocalBusiness rich-result address requirement can conflict with the temptation to hide or invent address information.

Do not start from “which schema will rank better?” Start from the entity.

Choose the most specific LocalBusiness type that fits

Google recommends using the most specific LocalBusiness subtype possible.

Examples in Schema.org include types such as:

The right type is the one that truthfully describes the business.

Do not select a subtype simply because:

If no narrow subtype fits well, use a broader truthful type instead.

• BeautySalon;
• DaySpa;
• HealthAndBeautyBusiness;
• HomeAndConstructionBusiness;
• ProfessionalService;
• Store;
• SportsActivityLocation.
• its label contains a keyword you want;
• a competitor uses it;
• a schema generator recommends it;
• it sounds more specific even though it is inaccurate.

Google’s current required properties matter

Google’s current LocalBusiness documentation lists these required properties for its LocalBusiness search feature:

Google describes address as the physical location of the business.

That creates an important implementation boundary for service-area businesses.

• name;
• address.

A basic storefront LocalBusiness JSON-LD example

The example below is fictional. Replace every value with real visible business information.

The code is not valuable because it is long. It is valuable only if the values are accurate.

{
  "@context": "https://schema.org",
  "@type": "BeautySalon",
  "name": "Harbor Beauty Studio",
  "url": "https://www.example.com/",
  "telephone": "+1-555-555-0100",
  "image": "https://www.example.com/images/studio-front.jpg",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "125 Example Avenue",
    "addressLocality": "Portland",
    "addressRegion": "OR",
    "postalCode": "97205",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 45.000000,
    "longitude": -122.000000
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday"
      ],
      "opens": "09:00",
      "closes": "18:00"
    }
  ]
}

Match structured data to visible business information

A practical rule:

If a customer would be surprised by a fact in the markup because the page says something different, fix the inconsistency.

Check:

Structured data should not become a hidden alternate version of the business.

The service-business homepage template can help make the public business identity clear before you start adding technical markup.

• business name;
• physical address;
• phone;
• opening hours;
• URL;
• location identity;
• business type;
• images;
• price indicators where used.

How to handle a service-area business

A service-area business may travel to customers and intentionally hide its residential or administrative address from the public.

The Google Business Profile service-area guide explains the profile-side distinction.

For structured data, use a conservative process.

Multiple locations need multiple real entities

A chain or multi-location business should not describe three branches as if they were one addressless super-location.

Google recommends defining each local business location.

For each real branch, keep the facts distinct:

• location-specific address;
• local phone where applicable;
• location URL;
• opening hours;
• geo coordinates;
• location-specific images where useful;
• location identity.

Use stable entity identifiers where appropriate

For more advanced implementations, an @id can provide a stable identifier for an entity.

A common pattern is an absolute URL with a fragment:

The identifier should be stable and point to the same conceptual entity over time.

Do not generate a new random identifier on every page load.

"@id": "https://www.example.com/locations/downtown#business"

Opening hours: encode the schedule you really publish

Opening-hours markup is useful only when it matches customer-facing hours.

If the business website says:

Monday–Friday, 9:00 AM–6:00 PM

but schema says:

Monday–Sunday, 24 hours

the problem is not that Google “misread” the page. The data is inconsistent.

For businesses with seasonal or special hours, maintain a process for updating visible information and structured data together when needed.

Structured data should not become a forgotten time capsule.

Phone and URL

Use the actual public business phone and canonical website URL for that location or business.

Avoid:

If a domain changes, update the structured data as part of the migration checklist rather than months later.

• tracking URLs that unexpectedly redirect through unrelated domains;
• phone numbers that belong to a former employee;
• URLs for a different location;
• HTTP versions when the site’s canonical public version is HTTPS.

Geographic coordinates

geo can describe a real physical location with latitude and longitude.

Use accurate coordinates for the business location, not the center of a city or a neighborhood you want to target.

If your map pin is wrong, fix the underlying location information rather than manipulating schema coordinates as a ranking tactic.

Images

Use real business images that are accessible to crawlers and relevant to the entity.

Good candidates can include:

Do not use an unrelated stock image merely because a schema generator requires an image field in its template.

• storefront exterior;
• interior;
• studio;
• team at work;
• representative location image.

Price range

priceRange is a descriptive property, not a substitute for a real pricing page.

If you use it, keep it truthful and consistent with the business.

For businesses debating how much price information to show publicly, the website pricing guide offers a separate decision framework.

Be extremely careful with reviews and aggregateRating

Review markup is one of the easiest areas to get wrong.

Google’s current LocalBusiness documentation describes aggregateRating as a recommended property only for sites that capture reviews about other local businesses.

That is an important guardrail for a business marking up its own website.

Do not paste an aggregateRating block onto your own LocalBusiness entity simply because:

Structured-data policies around reviews have changed over time, and self-serving review markup is a common source of confusion.

A customer testimonial section can still be useful to people. The testimonial placement guide focuses on the website-content side without promising search-result stars.

• you have a five-star Google rating;
• a schema plugin offers a “review stars” switch;
• a competitor has stars in an old screenshot;
• a generator says it can “unlock star ratings.”

Do not mark up content that is not really there

Google’s general structured-data guidelines require the markup to represent the page and comply with Search policies.

Avoid hidden fantasy data such as:

Structured data is machine-readable, not invisible.

• services the business does not offer;
• locations it does not operate;
• hours that are more generous than reality;
• fake prices;
• fake ratings;
• fake awards;
• misleading business categories.

Where should LocalBusiness schema go?

Google says LocalBusiness structured data can be added to a page on the site, and it makes sense to place it on a page that contains information about the business.

For a single-location service business, a strong home or location page is often the natural place.

For multiple locations, each location page can describe its real local entity.

Avoid spraying multiple contradictory LocalBusiness objects across every page.

Google’s Organization guidance also says Organization markup does not need to be repeated on every page.

The goal is a coherent entity model, not maximum JSON-LD volume.

LocalBusiness vs Organization schema

Organization describes the organization more broadly.

LocalBusiness is a subtype of organization/place concepts focused on a local physical business.

A company can have an organization-level entity and local branch entities without forcing every page to pretend it represents the same thing.

For example:

Keep the model understandable.

• home page: Organization or main business identity;
• Downtown location page: LocalBusiness entity for Downtown;
• Riverside location page: LocalBusiness entity for Riverside;
• service page: Service information connected to the correct provider where appropriate.

LocalBusiness schema does not replace Google Business Profile

A Business Profile and website structured data are different systems.

A business should keep both accurate.

A good local workflow includes:

The published local SEO guide for service businesses provides the broader system. This Guide stays focused on structured-data implementation.

• accurate Business Profile name;
• correct category;
• correct storefront/service-area setup;
• useful services;
• current website link;
• useful location/service content;
• consistent public business information;
• technically valid structured data where appropriate.

LocalBusiness schema does not guarantee Map Pack rankings

Avoid statements such as:

Structured data can help systems understand declared information. That is not the same as a guaranteed ranking outcome.

Use it because accurate machine-readable information is good technical hygiene, not because a generator promises a ranking shortcut.

• “Add schema and rank in the Map Pack.”
• “Schema is a direct local ranking factor.”
• “JSON-LD guarantees AI citations.”
• “Adding every nearby city to areaServed expands your ranking radius.”

How to validate your markup

Use two different validation questions.

A validation workflow

Do not treat “0 syntax errors” as proof of ranking eligibility.

1. Put the JSON-LD on a testable page.
2. Confirm the page is accessible.
3. Run the Rich Results Test.
4. Review errors separately from warnings.
5. Compare required fields with the current Google documentation.
6. Run a Schema.org validator when you need broader vocabulary checks.
7. Inspect the live rendered/source page to ensure the deployed markup is the version you tested.
8. Confirm the visible business information matches.
9. Re-test after significant website/template changes.

Common LocalBusiness schema mistakes

Example: a one-location beauty studio

A useful implementation sequence:

No ranking promise is needed.

1. confirm the studio is a genuine customer-facing location;
2. choose an accurate subtype such as BeautySalon if appropriate;
3. publish the correct name and address visibly on the site;
4. add matching LocalBusiness JSON-LD;
5. include useful recommended properties that are accurate;
6. validate;
7. keep the Business Profile and website aligned;
8. re-test after an address, phone or hours change.

Example: a mobile cleaning company

The company travels to customers and does not receive customers at its home base.

A safe sequence:

That is more honest than converting the owner’s kitchen table into a public “office” in JSON-LD.

1. keep the customer-facing website honest about the service area;
2. do not publish a private home address merely to satisfy a rich-result field;
3. use truthful organization/service structured data where appropriate;
4. understand that omitting a physical address means you should not promise eligibility for Google’s current LocalBusiness rich-result feature;
5. build useful service-area content instead of fake location signals;
6. validate whatever structured data you do publish.

Example: a three-location studio brand

For three genuine branches:

The service page template can then connect services to the appropriate business context without turning every service page into a duplicate location page.

1. create or maintain useful location pages;
2. give each location its actual name/address/hours/contact information;
3. use the appropriate local subtype for each location;
4. give each entity a stable identifier;
5. validate each page;
6. keep cross-location facts consistent where they truly are shared;
7. do not merge all addresses into one LocalBusiness object.

Maintenance checklist

Review structured data when:

Structured data is part of the website’s operational truth.

• the business moves;
• a phone number changes;
• hours change materially;
• a location opens or closes;
• the canonical domain changes;
• the brand name changes;
• a location page URL changes;
• a template migration changes structured-data output;
• the business adds/removes a meaningful public service;
• Google updates its structured-data documentation.

Build the website truth first

Good schema starts with good source information.

OneStudio helps service businesses manage customer-facing website content, online booking and business operations in one system. It does not need to be presented as a schema “ranking button.” Use OneStudio features to keep the underlying website and customer journey useful, then add structured data that accurately describes what is actually there.

Questions businesses ask