Brass embossed dog-tag plate stamped with clean ordered blank fields

LocalBusiness Schema: The Complete Setup

Local SEO Guide

LocalBusiness Schema: The Complete Setup

LocalBusiness schema hands Google and every AI assistant your business facts in a format they don’t have to guess at. It takes thirty minutes to do right, and one common mistake in it can earn you a manual action.

By Rahul Saini, Author at Search Counsel Co. Last updated [JULY] 2026.

Featured answer: what is LocalBusiness schema and what does it need?

LocalBusiness schema is JSON-LD structured data that tells search engines your business name, address, hours, phone, and location. Google requires only two properties, name and address, but you should use the most specific subtype available (Dentist, Plumber, Restaurant) and add geo coordinates, opening hours, telephone, and sameAs links. Never mark up your own star ratings.

Required

Two things

Name and a full address. That’s the minimum Google asks for. Everything else is upside.

The Trap

Your own stars

Marking up your own aggregateRating is self-serving review markup. It can trigger a manual action.

The Rule

Be specific

Dentist, not LocalBusiness. The subtype tells Google what you actually are.

What It Isn’t

A ranking lever

Schema clarifies facts that should already be visible. It won’t rescue a thin page.

Without structured data, Google reads your contact page and infers. Sometimes it gets your address right. Sometimes it decides your phone number is the one in a testimonial. Schema removes the guessing, and it’s one of the few things in local SEO that’s entirely within your control, costs nothing, and stays done. Here’s the whole setup, including the mistake that most plugins will happily make for you.

Key takeaways

  • Only two properties are required: name and a full PostalAddress. Everything else is recommended, and worth adding.
  • Never mark up your own star ratings. Google’s guidelines state aggregateRating and review in LocalBusiness are for sites that review other businesses. Self-serving review markup can trigger a manual action, and several popular plugins add it by default.
  • Always use the most specific subtype (Dentist, Plumber, Restaurant), never the generic LocalBusiness type when a better one exists.
  • Schema clarifies; it does not rank. Google’s policies require markup to represent content visible to users, and rich results are never guaranteed.
  • Your markup must match your Google Business Profile character for character. A mismatch is a machine-readable contradiction, and worse than no markup at all.
  • Service-area businesses still include their real address in the markup, plus areaServed to describe coverage.
  • Multi-location pattern: Organization schema on the homepage, one LocalBusiness block on each location’s own page. Never identical markup sitewide.

Article note: Written by Rahul Saini at Search Counsel Co. Property requirements follow Google’s Local Business structured data documentation and the schema.org LocalBusiness definition, which are the only authorities that matter here. For schema fundamentals beyond the local application, see our complete guide to schema markup.

How we researched this

Every factual claim on this page is traced to a named primary source, listed with a link in the sources table near the end. Where the available studies disagree with each other, we say so and explain why rather than quoting the convenient figure. Where a claim rests on a practitioner survey rather than data from Google, it is labelled as such. Where a widely repeated claim is not supported by evidence, we say that too.

Local search changes without announcements, so figures are dated and re-verified on each update. If you find something here that is out of date, tell us and we will fix it.

1) What LocalBusiness schema does

LocalBusiness is a schema.org type describing a particular physical business or branch. It inherits from both Organization and Place, which is what makes it useful: it can carry who you are and where you are in one block.

What it feeds:

  • The knowledge panel that appears when someone searches your business name.
  • Local business rich results, including hours, ratings, directions, and booking actions.
  • Local carousels for queries like “dentists near me.”
  • The structured facts AI assistants read first when someone asks whether you’re open on Sunday.

What it does not do is rank you. Google’s structured data policies are clear that markup must represent content visible to users, and that rich results are never guaranteed simply because markup exists. Schema is a clarification layer. It works best reinforcing facts that are already on the page, and it will not compensate for a page with nothing on it.

2) Pick the right subtype first

This is the decision most people get wrong by defaulting to the generic type.

Google recommends using the most specific LocalBusiness subtype available. “Dentist” tells Google you’re a dental practice. “LocalBusiness” tells it you exist. There are dozens of subtypes: Restaurant, Dentist, Plumber, AutoRepair, LegalService, MedicalBusiness, ProfessionalService, HomeAndConstructionBusiness, RealEstateAgent, HealthAndBeautyBusiness, and more.

First decision, before the subtype: is LocalBusiness even right for you? If your business has a physical location customers can visit, yes. If you’re a purely online business with no address at all, the broader Organization type is the better fit. Service-area businesses that travel to customers sit in between, and section 7 covers them.

3) Required and recommended properties

Property Status Notes
name Required Character-for-character identical to your Google Business Profile.
address Required A nested PostalAddress with streetAddress, addressLocality, addressRegion, postalCode, addressCountry.
telephone Recommended Your authoritative number, with country code. Not a tracking number.
geo Recommended GeoCoordinates with latitude and longitude. Pins you precisely.
openingHoursSpecification Recommended 24-hour format. Handles special and holiday hours too.
url Recommended The canonical URL for this location.
image Recommended Real photos of the business, multiple aspect ratios where possible.
priceRange Recommended A simple indicator, not a price list.
sameAs Recommended Your profiles elsewhere: social, industry directories, review platforms. This is your entity-disambiguation play.
aggregateRating / review Don’t See section 5. This is the one that gets people penalized.

4) The base markup, copy and paste

JSON-LD is Google’s recommended format. It sits in a script tag in your page’s head and never touches your visible content. Swap the values for your own and delete anything that doesn’t apply. Every value must also appear somewhere a customer can see it on the page.

Example 1: a storefront business (single location)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://example.com/#dentist",
  "name": "Sharma Dental",
  "image": [
    "https://example.com/photos/exterior.jpg",
    "https://example.com/photos/interior.jpg"
  ],
  "logo": "https://example.com/logo.png",
  "url": "https://example.com/",
  "telephone": "+91-141-555-0123",
  "priceRange": "$$",
  "description": "General and cosmetic dentistry in Malviya Nagar, Jaipur.",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Shanti Path, Malviya Nagar",
    "addressLocality": "Jaipur",
    "addressRegion": "RJ",
    "postalCode": "302017",
    "addressCountry": "IN"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 26.8505,
    "longitude": 75.8060
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
      "opens": "09:00",
      "closes": "18:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "09:00",
      "closes": "13:00"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/example",
    "https://www.instagram.com/example",
    "https://in.linkedin.com/company/example"
  ]
}
</script>

Notes on that block. The @id gives your business a stable identifier other schema on your site can point at, which is how you build a connected entity graph rather than a pile of unrelated blocks. sameAs is your entity-disambiguation play: it tells a machine that the business on your site, on Facebook, and on LinkedIn are one entity. And note what is absent: no aggregateRating. See section 5.

Example 2: a service-area business (no public address)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "@id": "https://example.com/#plumber",
  "name": "Ashfield Plumbing",
  "url": "https://example.com/",
  "telephone": "+44-20-7946-0123",
  "image": "https://example.com/photos/van.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "4 Bridge Road",
    "addressLocality": "Ashfield",
    "addressRegion": "Nottinghamshire",
    "postalCode": "NG17 1AA",
    "addressCountry": "GB"
  },
  "areaServed": [
    { "@type": "City", "name": "Ashfield" },
    { "@type": "City", "name": "Mansfield" },
    { "@type": "City", "name": "Sutton-in-Ashfield" }
  ],
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "Plumbing services",
    "itemListElement": [
      { "@type": "Offer",
        "itemOffered": { "@type": "Service", "name": "Emergency leak repair" } },
      { "@type": "Offer",
        "itemOffered": { "@type": "Service", "name": "Boiler installation" } },
      { "@type": "Offer",
        "itemOffered": { "@type": "Service", "name": "Bathroom fitting" } }
    ]
  },
  "openingHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday","Sunday"],
    "opens": "00:00",
    "closes": "23:59"
  }
}
</script>

Notes. The address is still there even though it’s hidden on your Google Business Profile. Structured data is not a public directory listing, and Google still needs to know where you are. areaServed is what describes your coverage, and hasOfferCatalog is the cleanest way to state what you actually do, which is the thing an assistant needs to match you to a query. The 24-hour openingHours block above is for a genuine 24-hour emergency service; do not use it unless you really do answer the phone at 3am.

Example 3: multi-location (homepage plus one location page)

On the homepage, describe the parent brand:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Sharma Dental",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "sameAs": ["https://www.facebook.com/example"]
}
</script>

Then on each location page, one LocalBusiness block that points back at the parent:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://example.com/locations/malviya-nagar/#dentist",
  "name": "Sharma Dental, Malviya Nagar",
  "parentOrganization": { "@id": "https://example.com/#organization" },
  "url": "https://example.com/locations/malviya-nagar/",
  "telephone": "+91-141-555-0123",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Shanti Path, Malviya Nagar",
    "addressLocality": "Jaipur",
    "addressRegion": "RJ",
    "postalCode": "302017",
    "addressCountry": "IN"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 26.8505,
    "longitude": 75.8060
  }
}
</script>

The mistake to avoid here is putting the same full LocalBusiness block on every page of the site. Ten locations means ten pages, ten distinct blocks, ten names that include the location identifier, and ten matching Google Business Profiles. Duplicating one block sitewide creates ambiguity rather than reinforcement.

A shorthand worth knowing, and why to skip it. There is a compact text form for hours: “openingHours”: “Mo-Fr 09:00-17:00”. It is valid and it is quicker. Use the full openingHoursSpecification version anyway, because it handles split shifts and holiday hours through validFrom and validThrough, and the shorthand cannot. Since being open at the moment of search is now a top-five local ranking factor, hours are not the place to save four lines.

Every value in these blocks must match your Google Business Profile and appear on the visible page. Structured data that disagrees with your own contact page is worse than none at all, because you have now published the contradiction in the format machines trust most.

5) The ratings trap that earns manual actions

This is the most important section on this page, and most local schema guides get it backwards.

Google’s guidelines state that aggregateRating and review within LocalBusiness markup are intended for sites that review other businesses. They are not for a business publishing star ratings about itself. Self-serving review markup violates Google’s structured data guidelines and can trigger a manual action against your site.

And yet: half the “add local schema” tutorials online tell you to include your own 4.9-star average, and several popular CMS plugins will happily generate it for you by default. You did not write that code, you clicked a checkbox, and the liability is yours.

Go and check right now. Open your homepage source, search for “aggregateRating,” and see whether your site is currently telling Google how great your site thinks your site is. If it is, remove it. Ratings should reach Google from third-party platforms, which is exactly what your Google Business Profile and your review platforms are for.

6) Opening hours, done properly

Hours are worth extra care, because being open at the moment someone searches is now among the top handful of local ranking factors, and because wrong hours in structured data get read by AI assistants answering “are they open right now?”

  • Use 24-hour time. “17:00”, not “5pm”.
  • Group days that share hours into one specification object; give days with different hours their own.
  • Model split shifts (a restaurant closing between lunch and dinner) as two specification objects for the same day.
  • Add special hours for public holidays using validFrom and validThrough, before the holiday rather than after it.
  • Keep them synchronized with your Business Profile. If one says you close at six and the other says seven, you’ve created the exact ambiguity schema exists to eliminate.

7) Service-area businesses and areaServed

If customers don’t come to you, LocalBusiness gets awkward, because address is a required property and you don’t publish one.

The practical approach:

  • You still have a real address. Include it in your markup even though it’s hidden on your Google Business Profile. Structured data isn’t a public directory listing, and Google needs to know where you are.
  • Add areaServed to state the towns, regions, or postcodes you cover. This is the property that describes your coverage, and it’s what a machine reads when someone asks whether you serve their area.
  • Consider Service markup alongside it, with a provider pointing at your LocalBusiness and areaServed on the service itself. That’s the cleanest way to say “we do this specific thing, in these specific places.”
  • If you have no physical address whatsoever, the broader Organization type may be a better fit than LocalBusiness. Don’t invent an address to satisfy a schema validator.

Remember that areaServed in your schema doesn’t rank you in those areas any more than the service-area field on your Business Profile does. The pages do that. See location and service-area pages that rank.

8) Multi-location setups

The pattern is simple and consistently botched.

  • Organization schema on the homepage, describing the parent brand.
  • One LocalBusiness block per location, on that location’s own page. Each with its own name (including the location identifier, like “Sharma Dental, Malviya Nagar”), its own address, phone, hours, geo coordinates, and URL.
  • Never put identical full LocalBusiness markup on every page of the site. Duplicating the same block sitewide creates ambiguity rather than reinforcement.
  • Each location’s markup must match that location’s Google Business Profile. Ten locations means ten profiles and ten matching schema blocks.

9) Where to put it (and where not to)

  • Single-location business: the full block on the homepage, or on a contact or about page that describes the business. You don’t need it on every page.
  • Multi-location: Organization on the home page, LocalBusiness on each location page.
  • Don’t put full identical LocalBusiness markup on your homepage and your about page and every blog post. Duplicates confuse crawlers.
  • Don’t mark up information that isn’t visible on the page. Google’s policy requires markup to represent content users can actually see.

10) Test it, then monitor it

  1. Validate the syntax with the Schema Markup Validator. It checks your schema.org syntax but says nothing about rich-result eligibility.
  2. Check eligibility with Google’s Rich Results Test. This is the one that tells you whether Google will actually do anything with your markup. Fix every critical error; consider fixing the warnings.
  3. Inspect the live URL in Search Console to see how Google actually renders and reads the page, particularly if your schema is injected with JavaScript.
  4. Monitor the Enhancements reports in Search Console. This is where Google tells you your markup broke, usually because a developer changed a template.
  5. Re-check after every change to your hours, address, name, or site template.

11) The mistakes that break it

Mistake Consequence
Marking up your own star ratings Self-serving review markup. Can trigger a manual action.
Using generic LocalBusiness when a subtype exists You’ve told Google you’re a business. You haven’t told it what kind.
Schema that doesn’t match your Business Profile A machine-readable contradiction. Worse than saying nothing.
Identical full markup on every page Duplication and ambiguity.
Marking up invisible content Against Google’s structured data policies.
Stale schema after a move or hours change You’re now confidently publishing the wrong facts in a format machines trust.
A tracking number in telephone Breaks the consistency the whole exercise exists to establish.

12) Schema and AI assistants

The reason to bother with this in 2026 has shifted.

When someone asks an assistant “is there a vegan restaurant in Amsterdam open on Sunday” or “what time does the nearest hardware store close,” the answer is assembled from structured facts, not from reading your prose. Your schema is the cleanest, most machine-readable statement of who you are, where you are, and when you’re open that exists anywhere on your own property.

It also does entity work. The sameAs property, pointing at your profiles on other platforms, is how you tell a machine that the business on your website, the one on your industry directory, and the one on your Business Profile are all the same entity. That’s the corroboration problem from NAP consistency, solved explicitly rather than left to inference.

Treat schema as the machine-readable layer of your local presence, sitting under your listings and your pages. It won’t rank a bad page. It will make a good business legible to systems that would otherwise have to guess. Check where you stand with our free Local AI Visibility Grader.

13) Sources used for this guide

Source What it supports
Google Search Central: Local Business structured data documentation Required and recommended properties, the instruction to use the most specific subtype, and the guidance that aggregateRating and review are for sites reviewing other businesses.
Google structured data general guidelines Markup must represent content visible to users; violations can result in manual action; rich results aren’t guaranteed by markup alone.
Google Search Central: Organization structured data When Organization is the better type, and the multi-location pattern of Organization on the home page with LocalBusiness on location pages.
schema.org/LocalBusiness The type definition, its inheritance from Organization and Place, the available subtypes, and the areaServed and OfferCatalog patterns.

FAQ: LocalBusiness schema

What are the required properties for LocalBusiness schema?

Name and address, with the address as a nested PostalAddress object containing streetAddress, addressLocality, addressRegion, postalCode, and addressCountry. Everything else is recommended, but geo coordinates, telephone, opening hours, url, and sameAs are all worth adding.

Can I add my own star rating to my LocalBusiness schema?

No. Google’s guidelines state that aggregateRating and review in LocalBusiness markup are intended for sites that review other businesses, not for a business publishing ratings about itself. Self-serving review markup violates the structured data guidelines and can trigger a manual action. Several popular plugins generate it by default, so check your source code.

Should I use LocalBusiness or a more specific type?

Always the most specific subtype that accurately describes you: Dentist, Restaurant, Plumber, LegalService, AutoRepair, and so on. Google explicitly recommends this. The generic LocalBusiness type tells Google you exist without telling it what you do.

Does LocalBusiness schema improve my rankings?

Not directly. Schema is a clarification layer that makes your facts machine-readable and makes you eligible for rich results and knowledge panel details. Google’s policies state that markup must reflect content visible to users and that rich results aren’t guaranteed. It won’t rescue a thin page.

How do I add schema for a service-area business with no public address?

Include your real address in the markup even though it’s hidden on your Google Business Profile, and add areaServed to describe the towns or regions you cover. Consider Service markup with a provider reference alongside it. If you have no physical address at all, the Organization type may fit better than LocalBusiness.

Where should LocalBusiness schema go on my site?

For a single location, on the homepage or a page describing the business, such as contact or about. For multiple locations, use Organization schema on the homepage and one LocalBusiness block on each location’s own page. Don’t repeat identical full markup across every page.

Does my schema need to match my Google Business Profile exactly?

Yes. Name, address, phone, and hours should be character-for-character identical. A mismatch between your own structured data and your Business Profile is a machine-readable contradiction, and it’s more damaging than having no markup at all.

What format should I use, JSON-LD or microdata?

JSON-LD. It’s Google’s recommended format, it sits in a script tag without touching your visible HTML, and it’s far easier to maintain than microdata woven through your markup.

How do I test my LocalBusiness schema?

Use the Schema Markup Validator for syntax and Google’s Rich Results Test for rich-result eligibility. They answer different questions. Then use URL Inspection in Search Console to see how Google actually renders the page, and monitor the Enhancements reports for errors that appear after template changes.

How often should I update my schema?

Whenever your hours, address, phone number, name, or services change, and re-test after any change to your site template. Outdated schema creates exactly the same trust problem as an outdated Business Profile, except it’s the version machines trust most.

Conclusion: get the type right, get the data consistent, validate

That’s the entire playbook. Choose the most specific subtype that describes you, populate the required properties and as many recommended ones as apply, make every value match your Business Profile and your visible page, and never, ever mark up your own reviews.

It takes half an hour, it doesn’t need touching again until something about your business changes, and it’s one of the few pieces of local SEO that is entirely and permanently within your control. Go and check your source code for “aggregateRating” first. That one’s urgent.

Editorial note: This guide is general marketing information. Google’s structured data requirements and rich result eligibility change over time. Always validate against the current Google Search Central documentation and the Rich Results Test before deploying.

Scroll to Top