LocalBusiness Schema

TL;DR — LocalBusiness schema is code you add to a page that tells search engines the facts about a physical business — its name, address, phone number, and hours. Google only requires two things (name and address); everything else is optional but makes the result richer. It is not the same as setting up a Google Business Profile, and adding it doesn’t guarantee you a fancy search result — it just makes you eligible for one.

What LocalBusiness schema is

When a search engine reads your “Contact” page, it sees text. It can’t automatically tell your street address from your phone number from your opening hours the way you can. LocalBusiness schema spells it out in code: this is the name, this is the address, this is the phone number, these are the hours.

It uses the shared vocabulary from schema.org — the same vocabulary behind all schema markup — and you usually write it as JSON-LD, a small block of code that sits in the page without changing how it looks. Evidence for this claim Schema.org LocalBusiness is a subtype of both Organization and Place for describing a physical business or branch. Scope: Schema.org vocabulary; Google applies separate local-business search requirements. Confidence: high · Verified: 2026-07-14 Schema.org: LocalBusiness

What Google actually needs

Here’s the surprising part. schema.org defines dozens of properties you could add, but Google only requires two:

• name — the name of the business.
• address — the physical street address.

Everything else — phone number, hours, price range, map coordinates — is recommended. Evidence for this claim Google's LocalBusiness feature documentation requires name and address and recommends additional applicable business details. Scope: Google Search LocalBusiness requirements; eligibility and display are not guaranteed. Confidence: high · Verified: 2026-07-14 Google: LocalBusiness structured data You don’t have to include it, but the more accurate detail you add, the more complete your listing can look in search.

The two things beginners get wrong

1. Schema is not your Google Business Profile. These are two different systems. Your Google Business Profile (the free listing you claim at business.google.com) is what powers your pin on Google Maps and the “local pack” of three businesses under a map. LocalBusiness schema is separate code on your own website. One does not replace the other — you generally want both, and Google reconciles them separately.

2. Don’t mark up your own star rating. It’s tempting to add your own five-star average with aggregateRating, but Google’s own guidelines say that property is for sites that review other businesses (like a directory reviewing restaurants), not for a business rating itself. Marking up your own testimonials as a rating is a “self-serving review” and breaks the rules.

One more: use the specific type. If you run a restaurant, mark it up as Restaurant, not the generic LocalBusiness. Google explicitly asks for the most specific type that fits.

Want the full version — the exact property table, subtype selection, geo-coordinate precision, multi-location patterns, and how “NAP consistency” fits in? Switch to the Advanced tab.

TL;DR — LocalBusiness is a subtype of Organization and Place, so the full schema.org spec inherits dozens of properties — but Google requires only name + address and consumes ~12 recommended ones. The wins: use the most specific subtype (multiple types go in an array; additionalType isn’t supported), keep NAP consistent across your markup, Google Business Profile, and citations, and get the details right — geo needs ≥5 decimal places, priceRange must stay under 100 characters. Don’t mark up your own aggregateRating/review (that’s for sites reviewing other businesses; self-serving reviews break the guidelines), and don’t treat schema as a Google Business Profile substitute — they’re separate, reconciled separately, and valid markup only makes you eligible.

Where it sits: a subtype of Organization and Place

The single most useful thing to understand about LocalBusiness is its position in the schema.org hierarchy. It’s a subtype of both Organization and Place, which is exactly why it can carry general company properties (name, logo, sameAs) and location-specific ones (address, geo, openingHoursSpecification). That dual inheritance is also why the full spec is so large — it pulls properties from two big parent types.

That matters for how you think about the wider Entity & Identity schema picture. A company-wide Organization entity (sitewide, on the homepage) and a per-location LocalBusiness entity are related but distinct: one describes the company, the other describes a place you can walk into. For the company-level entity, see Organization schema; for the people behind it, Person schema.

The full spec vs. what Google actually consumes

This is the distinction most guides blur. schema.org/LocalBusiness inherits dozens of properties from Organization and Place. Google consumes a small subset. Don’t confuse “schema.org supports X” with “Google will do something with X.”

Required (only two):

• address (PostalAddress) — the physical location. Google’s advice: include as many address sub-properties as possible; the more you provide, the higher the quality of the result.
• name — the name of the business.

Recommended (the properties that actually enrich the result): aggregateRating, department, geo (with geo.latitude / geo.longitude), menu, openingHoursSpecification (with .opens, .closes, .dayOfWeek, .validFrom, .validThrough), priceRange, review, servesCuisine, telephone, and url.

The takeaway for prioritizing dev effort: nail the required pair, then add the recommended properties that make your listing more complete (hours and geo for a storefront; servesCuisine and menu for a restaurant). Filling in obscure inherited properties that Google ignores is wasted effort.

Choosing the right subtype

Google is explicit: use the most specific LocalBusiness sub-type possible — for example Restaurant, DaySpa, HealthClub. Generic LocalBusiness works, but a specific subtype gives engines more to work with.

A few practical mappings:

• Restaurant / café → Restaurant, CafeOrCoffeeShop, BarOrPub (under FoodEstablishment)
• Law firm → LegalService (or Attorney)
• Dentist / doctor → Dentist, Physician (under MedicalBusiness)
• Plumber / electrician / general contractor → HomeAndConstructionBusiness subtypes (Plumber, Electrician, GeneralContractor)
• Consultancy / agency with no better fit → ProfessionalService

If your business genuinely spans two types, specify them as an array — Google supports multiple @type values that way. Note that additionalType is not supported for this purpose, so don’t reach for it.

NAP consistency — schema, GBP, and citations

“NAP” (Name, Address, Phone) consistency is longstanding local-SEO best practice: the same name, address, and phone should appear identically across your on-page schema, your Google Business Profile, and directory citations (Yelp, BBB, industry directories). Mismatches — an old suite number here, a tracking phone number there — muddy the signals engines use to identify and trust a location.

One honest caveat: “NAP” is industry shorthand, not a Google spec term. Google’s LocalBusiness documentation doesn’t use the word. Frame it as well-established local-SEO consensus, not a quoted Google ranking factor. It still matters — arguably more than any single individual property — because it’s about the coherence of your entity across the web, not one field on one page.

The implementation details that trip people up

• Geo coordinates need at least 5 decimal places. Google states the precision must be at least 5 decimal places for both latitude and longitude. A common slip is a CMS or geocoding tool rounding coordinates to 2–3 places — enough to put your pin in the wrong block.
• priceRange has a 100-character ceiling. It must be shorter than 100 characters; at 100 or more, Google won’t show a price range at all. Keep it short ($$, or $10–30), not a paragraph.
• openingHoursSpecification syntax and edge cases. dayOfWeek accepts full schema.org URLs (https://schema.org/Monday) or the short name (Monday). Google’s own examples use 24-hour opens/closes times without seconds (hh:mm); schema.org’s broader Time type also accepts hh:mm:ss if your generator adds it. Four patterns cover almost every case, straight from Google’s documentation: a normal day ("opens": "09:00", "closes": "17:00"), hours that cross midnight ("opens": "18:00", "closes": "03:00" for an overnight Saturday), open all day ("opens": "00:00", "closes": "23:59"), and closed all day ("opens": "00:00", "closes": "00:00"). For seasonal or holiday closures, add validFrom / validThrough in YYYY-MM-DD (Google’s own example uses "validFrom": "2015-12-23", "validThrough": "2016-01-05") — a nuance most basic implementations skip entirely.
• Department naming convention. When you nest a department, include the store name with the department name (e.g., “gMart” and “gMart Pharmacy”) — unless the department is its own independent brand (e.g., “Best Buy” and “Geek Squad”), in which case name it standalone.

Reviews and ratings: the self-serving-rating trap

This one wastes a lot of implementation effort. Google’s docs are clear that aggregateRating and review are recommended only for sites that capture reviews about other local businesses — a directory or review platform, not the business rating itself. A business marking up its own star average on its own page is doing a “self-serving review,” which violates Google’s review-snippet guidelines; Google stopped showing self-serving review stars for LocalBusiness/Organization years ago. Evidence for this claim Google's review snippet rules make self-serving reviews for LocalBusiness and Organization ineligible for the star review feature. Scope: Google Search review snippet eligibility policy; genuine third-party review contexts are treated differently. Confidence: high · Verified: 2026-07-14 Google: Review snippet structured data

So if you were planning to sprinkle your homepage testimonials into an aggregateRating: don’t. It won’t earn the stars you’re picturing, and it can cross the line from “no benefit” into “guideline violation.”

Multi-location businesses: one page vs. many

Competitors give hand-wavy advice here, so let me be concrete. The correct pattern depends on your architecture:

• One LocalBusiness per location page. The cleanest approach for a chain: each location gets its own page with its own LocalBusiness markup describing that address. You can tie them to the parent with parentOrganization / branchOf.
• Nesting under Organization. At the company level, you can express the brand as an Organization with locations as subOrganization.

What not to do: stack five unrelated LocalBusiness blocks flatly on your homepage. If a page has one address in the footer but five different LocalBusiness addresses in the markup, you’ve made it ambiguous which address the page is actually about. Mark up the location the page represents.

LocalBusiness schema vs. Google Business Profile

Say this plainly because most guides bury it: schema markup ≠ Google Business Profile. They are different systems that Google reconciles separately.

• Your Google Business Profile feeds Maps and the local pack directly through Google’s own systems. It’s the primary driver of “near me” and local-pack visibility.
• On-page LocalBusiness schema is a corroborating on-site signal Google may use for Knowledge Panels and enriched results. It is not a substitute for a Business Profile — and a Business Profile is not a substitute for on-page schema.

You want both, kept consistent (that’s the NAP point again). Neither one alone does the other’s job.

What it does — and doesn’t — guarantee

Valid, guideline-compliant markup makes a page eligible for a local Knowledge Panel or a business carousel — though “eligible” scopes differently per feature. Google’s restaurant carousel, for instance, is currently limited to a small set of participating restaurant providers, so valid Restaurant markup alone doesn’t get an arbitrary site into it. Beyond that scoping, eligibility still doesn’t guarantee display — Google says outright that it doesn’t guarantee that features consuming structured data will show up in results. And a note on the stats floating around competitor blogs: numbers like “30–50% more often in the local pack” or “20–35% CTR lift” circulate widely with no primary source. Treat them as unverified marketing claims, not Google-confirmed outcomes.

Validate before you ship

1. Add the required properties (name, address), then the recommended ones that fit your business.
2. Validate with the Rich Results Test and the Schema Markup Validator.
3. Deploy, then check with URL Inspection in Search Console and request a recrawl.
4. Monitor the structured-data reports in Search Console over time.

Validate, then deploy — not the reverse.

AI summary

A condensed take on the Advanced version:

• What it is: schema.org/LocalBusiness structured data (usually JSON-LD) describing a physical business — name, address, phone, hours, geo, price range.
• Hierarchy: a subtype of both Organization and Place, which is why it inherits dozens of properties and why the full spec is large.
• Full spec vs. Google: Google requires only name + address and consumes ~12 recommended properties (geo, openingHoursSpecification, priceRange, telephone, url, department, menu, servesCuisine, plus aggregateRating/review). Don’t assume “schema.org supports X” means “Google uses X.”
• Subtype: use the most specific subtype (Restaurant, LegalService, Dentist), not generic LocalBusiness. Multiple types go in an array; additionalType is not supported.
• NAP consistency: keep name/address/phone identical across markup, Google Business Profile, and citations. “NAP” is industry shorthand, not a Google spec term — but coherence matters more than any single property.
• Detail traps: geo needs ≥5 decimal places; priceRange must be under 100 characters or Google drops it; opening hours use hh:mm:ss and short or full dayOfWeek, with validFrom/validThrough for seasonal closures.
• Reviews: aggregateRating/review are for sites reviewing other businesses. Marking up your own rating is a self-serving review that violates Google’s guidelines (self-serving stars were dropped around 2019).
• Multi-location: one LocalBusiness per location page (tie with parentOrganization/branchOf) or nest under Organization via subOrganization. Don’t stack unrelated addresses flatly on the homepage.
• Schema ≠ Google Business Profile: separate systems, reconciled separately. GBP feeds Maps/local pack; on-page schema corroborates for Knowledge Panels. Want both.
• No guarantee: valid markup makes you eligible, not guaranteed. Ignore uncited “30–50% more local pack” / “20–35% CTR” stats — no primary source.
• Validate: Rich Results Test + Schema Markup Validator, then URL Inspection and Search Console reports. Validate, then deploy.

Official documentation

Primary-source documentation from the search engines and schema.org.

Google

• Local business (LocalBusiness) structured data — the source of truth: required/recommended properties, subtype guidance, geo precision, priceRange limit, department naming, and the validation workflow.
• Organization structured data — the company-level entity, for the LocalBusiness-vs-Organization distinction.
• Review snippet structured data — the guidelines behind the self-serving-review restriction on aggregateRating/review.
• Rich Results Test — checks rich-result eligibility and required-property errors.
• Schema Markup Validator — validates any schema.org type, including LocalBusiness.

schema.org

• schema.org/LocalBusiness — the full vocabulary: every inherited property from Organization and Place (the “full spec” side of the compare-and-contrast).

Bing / Microsoft

• Marking Up Your Site with Structured Data — Bing Webmaster Tools — Bing’s general structured-data guidance and validator (Schema.org / Microdata / RDFa / OpenGraph).
• Bing Places for Business — Bing’s separate listing product, the parallel to Google Business Profile (same “listing platform ≠ on-page schema” distinction).

Quotes from the source

On-the-record statements from Google’s LocalBusiness documentation. Where the page exposes the text, the link is a deep link that jumps to the quoted passage.

Google docs — what it enables

• “When users search for businesses on Google Search or Maps, Search results may display a prominent Google knowledge panel with details about a business that matched the query. When users search for a type of business (for example, ‘best NYC restaurants’), they may see a carousel of businesses related to the query.” Local business structured data

Google docs — subtype guidance

• “Use the most specific LocalBusiness sub-type possible; for example, Restaurant, DaySpa, HealthClub, and so on.” Jump to quote

Google docs — geo precision

• “The precision must be at least 5 decimal places.” Jump to quote

Google docs — self-serving reviews

• On aggregateRating and review: “This property is only recommended for sites that capture reviews about other local businesses.” Jump to quote

Properties cheat sheet

Required vs. recommended (what Google actually consumes)

Common LocalBusiness subtypes

Fast facts

• Required = 2 (name, address); everything else is recommended.
• Use the most specific subtype; multiple types go in an array; additionalType is not supported.
• Geo ≥ 5 decimal places; priceRange < 100 characters.
• aggregateRating/review = for sites reviewing other businesses, not self-reviews.
• Schema ≠ Google Business Profile — separate systems, reconciled separately.
• NAP consistency (industry term, not a Google spec word) across markup, GBP, and citations matters more than any single property.
• Valid markup = eligible, never guaranteed. Validate → deploy.

Anti-patterns: how LocalBusiness markup goes wrong

The mistakes I see most, and what to do instead.

1. NAP inconsistency. Your schema says “123 Main St, Suite 200,” your Google Business Profile says “123 Main Street,” and Yelp still has your old phone number. These mismatches undermine the whole point — engines use the coherence of your name/address/phone across the web to identify and trust a location. Fix: pick one canonical NAP and make the markup, the Business Profile, and every citation match it exactly.

2. Using the generic type when a specific one exists. Marking a restaurant as bare LocalBusiness when Restaurant exists throws away signal Google explicitly asks for. Fix: use the most specific subtype that fits (Restaurant, LegalService, Dentist); use multiple @type values in an array if you genuinely span two — but not additionalType.

3. Self-serving reviews. Marking up your own testimonials as aggregateRating/review to try to win star ratings. Google’s guidelines reserve those properties for sites reviewing other businesses; self-serving stars were dropped years ago and this can cross into a guideline violation. Fix: don’t self-rate. Earn genuine third-party reviews (which live on the review platforms, not your markup).

4. Stacking multiple locations on one page. Five different LocalBusiness blocks with five different addresses on one homepage, when the page really represents one entity (or none). It’s ambiguous which address the page is about. Fix: one LocalBusiness per location page (tie to the brand with parentOrganization/branchOf), or model the company as an Organization with subOrganization.

5. Confusing schema with a Google Business Profile. Assuming on-page markup will get you into Maps and the local pack, or that having a Business Profile means you don’t need schema. They’re separate systems that Google reconciles separately — GBP drives Maps/local pack, schema corroborates for Knowledge Panels. Fix: set up both and keep them consistent.

Bonus trips: rounding geo coordinates below 5 decimal places (wrong-block pin), a priceRange over 100 characters (Google silently drops it), and expecting a guaranteed rich result from valid markup (eligibility ≠ display).

Test yourself: LocalBusiness Schema

Five quick questions on LocalBusiness schema — required properties, subtypes, the review trap, and how it relates to a Google Business Profile. Pick an answer for each, then check.

Which LocalBusiness subtype should I use?

The article’s subtype guidance turns into a straightforward branch: match your business category to the most specific LocalBusiness sub-type schema.org defines, and only fall back to the generic type when nothing fits.

One page per location, or nest under Organization?

The other genuine fork in the article is architectural: how do you markup a business with more than one physical location?

Worked examples: LocalBusiness JSON-LD

Three annotated blocks, each built from the required and recommended properties covered above.

Example 1: minimum viable markup (required properties only)

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Riverside Dental Care",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "412 Riverside Ave",
    "addressLocality": "Columbus",
    "addressRegion": "OH",
    "postalCode": "43215",
    "addressCountry": "US"
  }
}

• name and address are the only two properties Google requires — this passes validation, but it’s leaving the recommended properties (and a specific subtype) on the table.
• Even at this minimal level, Google’s advice is to include as many address sub-properties as you can — that’s why all five are filled in here instead of a single streetAddress line.

Example 2: a specific subtype with the recommended properties filled in

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Riverside Dental Care",
  "telephone": "+1-614-555-0142",
  "url": "https://www.riversidedentalcare.example/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "412 Riverside Ave",
    "addressLocality": "Columbus",
    "addressRegion": "OH",
    "postalCode": "43215",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.96199,
    "longitude": -83.00275
  },
  "priceRange": "$$",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
      "opens": "08:00:00",
      "closes": "17:00:00"
    }
  ]
}

• @type is Dentist, not generic LocalBusiness — the specific subtype Google asks for.
• geo.latitude/geo.longitude both carry 5 decimal places, matching Google’s minimum-precision requirement.
• priceRange is a short $$, well under the 100-character ceiling.
• openingHoursSpecification uses hh:mm:ss times and short dayOfWeek names, grouped for the days that share the same hours.

Example 3: a restaurant with a seasonal-closure and department nesting note

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "gMart Pharmacy",
  "servesCuisine": "American",
  "menu": "https://www.example-diner.example/menu/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "88 Harbor Rd",
    "addressLocality": "Portland",
    "addressRegion": "ME",
    "postalCode": "04101",
    "addressCountry": "US"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "https://schema.org/Monday",
      "opens": "11:00:00",
      "closes": "21:00:00",
      "validFrom": "2026-01-01",
      "validThrough": "2026-12-24"
    }
  ]
}

• servesCuisine and menu are the recommended properties that matter most for a FoodEstablishment subtype like Restaurant.
• dayOfWeek here uses the full schema.org URL form instead of the short name — both are valid, this just shows the alternative.
• validFrom/validThrough mark a seasonal window in YYYY-MM-DD — the detail most basic implementations skip.
• The name value follows the article’s department-naming convention: “gMart Pharmacy” keeps the store name with the department name, the pattern to use unless the department is its own independently branded entity (like “Best Buy” and “Geek Squad”).

Three mental models for thinking about LocalBusiness schema

1. Full spec vs. what Google actually consumes. schema.org/LocalBusiness inherits dozens of properties from both Organization and Place, but Google requires only name + address and meaningfully consumes about a dozen recommended ones (geo, openingHoursSpecification, priceRange, telephone, url, department, menu, servesCuisine, aggregateRating/review). The framework: never assume “schema.org supports property X” means “Google will do something with property X.” Prioritize the required pair, then the recommended properties that fit your business, and treat obscure inherited properties Google ignores as wasted implementation effort.

2. Schema is not a Google Business Profile. These are two separate systems that Google reconciles independently. A Google Business Profile feeds Maps and the local pack directly through Google’s own systems — it’s the primary driver of “near me” and local-pack visibility. On-page LocalBusiness schema is a corroborating on-site signal Google may use for Knowledge Panels and enriched results. Neither substitutes for the other; the framework is “set up both, and don’t expect one to do the other’s job.”

3. NAP as coherence, not a single field. Name/Address/Phone consistency across your schema markup, your Google Business Profile, and directory citations isn’t about any one property being correct — it’s about the coherence of your entity across the entire web. A mismatched suite number or a stale tracking phone number in one place muddies the signals engines use to identify and trust a location, even if every individual field is technically valid on its own page. Treat “NAP” as well-established local-SEO consensus (the term itself isn’t in Google’s documentation), not a single checkbox to tick once.

Tools for validating LocalBusiness markup

• Rich-Result Eligibility Checker — my own free tool. Paste your LocalBusiness JSON-LD, an HTML page, or fetch a live URL, and it shows exactly which required fields are missing and which recommended ones you’re leaving out, specific to the local-business rich result. It runs entirely in your browser, so nothing you paste in leaves your machine.
• Schema Markup Validator — also mine. Validates the JSON-LD’s schema.org vocabulary directly (not just the Google-specific subset), checks cross-block @id references if you’re linking LocalBusiness to a parent Organization, and gives you back a corrected, copy-pasteable block.
• Rich Results Test — Google’s own tool. Use it after the two above to confirm Google’s live parser agrees the page is eligible.
• URL Inspection (Search Console) — after deploying, check how Google actually crawled and rendered the page, and request a recrawl.

Pitch: run the Rich-Result Eligibility Checker or the Schema Markup Validator before you ship a change, then confirm with the Rich Results Test and URL Inspection after — that’s the same sequence the Validation Tests lens below walks through in detail.

Proving your LocalBusiness markup change worked

Test 1: required-property and syntax validation

Test to run: Paste the updated JSON-LD into my Rich-Result Eligibility Checker or Schema Markup Validator. Expected result: No missing-required-field errors on name or address, and the tool shows the local-business rich result as eligible. Failure interpretation: A flagged missing property means it genuinely isn’t present in the markup you shipped — re-check the JSON-LD source rather than assuming a caching issue. Monitoring window: Immediate — the tool reads the markup directly, no crawl wait required. Rollback trigger: Validation still fails after a direct fix to the template — revert the change and re-diff against the last known-good JSON-LD.

Test 2: Google’s own Rich Results Test agrees

Test to run: Run the live URL through Google’s Rich Results Test. Expected result: The page is detected as eligible for the local business result, with the required and recommended properties Google’s parser sees matching what you shipped. Failure interpretation: If Google’s tool disagrees with the two tools above, the live page likely differs from what you validated — check for a caching layer or a build step serving stale markup. Monitoring window: Immediate. Rollback trigger: The eligible-page check still shows missing required fields after a deploy — the fix didn’t reach the live page.

Test 3: Search Console structured-data reports over time

Test to run: Search Console’s structured-data / Enhancement reports for the affected URLs, after requesting a recrawl via URL Inspection. Expected result: The URL count with LocalBusiness errors drops to zero, and previously flagged pages move into the valid bucket. Failure interpretation: Still flagged after a recrawl means either the fix hasn’t propagated to the version Google fetched, or a different required property is also missing — re-run Test 1 against the exact URL Search Console lists. Monitoring window: 2–4 weeks — structured-data report updates lag behind a single recrawl. Rollback trigger: Error counts climb instead of falling after the change ships broadly — revert and re-validate before rolling forward again.

LocalBusiness Schema

LocalBusiness schema (schema.org/LocalBusiness) is structured data — usually JSON-LD — that describes a physical business to search engines: its name, address, phone, hours, geo-coordinates, and price range. Google requires only name and address, consumes about a dozen recommended properties, and treats it as a corroborating signal, not a substitute for a Google Business Profile.

Related: Schema Markup, Entity & Identity Schema, Organization Schema, Person Schema

LocalBusiness Schema

LocalBusiness schema is the schema.org/LocalBusiness vocabulary you add to a page — usually as JSON-LD — to describe a physical business to search engines: its name, address, telephone, openingHoursSpecification, geo coordinates, priceRange, and more. It’s a subtype of both Organization and Place, so it inherits general company properties (name, logo, sameAs) plus location-specific ones (address, geo, hours).

The thing to keep straight: the full schema.org spec defines dozens of inherited properties, but Google consumes far fewer. Google requires only two properties — name and address — and rewards roughly a dozen recommended ones (geo, openingHoursSpecification, priceRange, telephone, url, department, menu, servesCuisine, plus aggregateRating/review for sites that review other businesses). Using the most specific subtype (Restaurant, DaySpa, LegalService) and keeping name/address/phone consistent across your markup, Google Business Profile, and directory listings matters more than filling in every property.

LocalBusiness schema is not the same as a Google Business Profile listing. The Business Profile feeds Maps and the local pack directly through Google’s own systems; on-page schema is a separate, corroborating signal Google may use for Knowledge Panels and enriched results. Valid markup only makes a page eligible — Google never guarantees a rich result will show.

Related: Schema Markup, Entity & Identity Schema, Organization Schema, Person Schema

Changelog