Answers

Best schema markup for local business starts with one type, done properly

The best schema markup for a local business is a single JSON-LD block using the most specific LocalBusiness subtype available, not a stack of every type schema.org defines. Google requires only three properties to qualify for a rich result at all: type, name and a full address. The properties that actually help a business get found sit one tier up, in the recommended fields most sites skip.

By Rish Sadh, founderUpdated 29 Sep 2026

Short answer

Pick the most specific LocalBusiness subtype the business fits, a Restaurant, Dentist, ProfessionalService or Store rather than the generic parent type, and write it once in JSON-LD. Name the business, give its full postal address as a structured object, then add opening hours, geographic coordinates, a price range and sameAs links to verified profiles. The first three are required for eligibility. The rest are what actually makes the markup useful to a system deciding whether to surface the business.

What Google actually requires, versus what helps

Google's own structured data documentation lists three required properties for LocalBusiness: the type, the name, and the address. Miss any of them and the page is not eligible for a local rich result, whatever else the markup contains.

Address has to be a full PostalAddress object, with street, city, region and postal code as separate fields, not one line of plain text folded into a single string. That distinction trips up markup that looks complete at a glance but fails validation.

Everything past those three sits in a recommended tier: telephone, opening hours, geographic coordinates, an image and a price range. None of it is required for eligibility, but it is exactly what a system reads once a business has qualified, so skipping it is the most common way a technically valid block ends up doing little.

Required vs recommended properties
Property	Tier	What it does
type	Required	Names the exact business category, ideally the most specific subtype available
name	Required	The business name, matched exactly to how it appears elsewhere
address	Required	A full PostalAddress object: street, city, region, postal code, not one line of text
openingHoursSpecification	Recommended	Structured hours a system can check against a live question, not prose
geo	Recommended	Latitude and longitude, for distance and map-based queries
priceRange	Recommended	Sets expectation before contact, so the business is not surfaced for the wrong budget
sameAs	Recommended	Links to verified profiles, so a system can cross-check the same facts elsewhere

Pick the most specific type, and only the types that are true

Schema.org defines dozens of LocalBusiness subtypes for specific categories: Restaurant, Dentist, LegalService, HairSalon, and more. Using the exact match over the generic LocalBusiness parent costs nothing extra and gives a system a sharper category than a general-purpose type ever could.

The same discipline applies past the primary type. Review or AggregateRating markup with no real, visible reviews on the page is a mismatch, not a shortcut to stars in a result. Coverage should track what is genuinely true and shown on the page, not what a business could technically qualify for.

Properties, not props

A LocalBusiness type with no hours, no geo and no sameAs is barely more useful to a system than no schema at all.

Reidify ships Organization schema rather than LocalBusiness, because a design studio has no public storefront a customer walks into. The address and telephone properties work identically either way. A business with a physical address customers visit changes only the outer type, from Organization to LocalBusiness or a specific subtype, and adds the properties in the checklist below.

Reidify's own address block, Organization type

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Reidify",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Mumbai",
    "addressCountry": "IN"
  },
  "telephone": "+91 8356966211"
}

What to add beyond the required three

Each of these is optional for eligibility and does most of the actual work once a business qualifies.

Write hours as openingHoursSpecification, not prose
A structured OpeningHoursSpecification with dayOfWeek, opens and closes lets a system answer "is it open now" directly, which a sentence in the footer cannot.
Add geo coordinates
Latitude and longitude let a system reason about distance and location, useful for any query with a "near me" or neighbourhood framing.
Set a priceRange
A rough band such as "$" or a stated range sets expectation before contact, so the business is not surfaced for a budget it does not serve.
Link sameAs to verified profiles
Point sameAs at the Google Business Profile and the main active social accounts, so a system checking the business elsewhere finds the same facts rather than a gap.
Add an image
A representative photo gives a system something to attach to the entity, which a name and address alone do not provide.
Keep it current and validate after every change
Stale hours are worse than no hours: a block that claims the business is open when it is not tells a system checking it that the rest of the markup cannot be fully trusted either.

Why this is worth getting right, not just present

A minimal, valid LocalBusiness block clears the eligibility bar and stops there. The recommended properties are what turn that block into something a system can actually use to answer a real question: is it open now, how far away is it, what should this cost, does its profile agree with what the website says.

That last question, whether a business's facts agree across its website, its entity and its Google Business Profile, is the deeper mechanism behind how AI systems decide whether to name a local business at all. Complete, current schema is the part of that agreement a business controls directly, without waiting on a directory or a profile to catch up.

Common questions

Do I need the generic LocalBusiness type, or is there a more specific one?

Use the most specific subtype schema.org defines for the business, a Restaurant, Dentist, ProfessionalService or Store rather than plain LocalBusiness. It costs nothing extra to specify and gives a system a sharper category than the generic parent type.

What are the three properties Google actually requires?

Type, name and address, with address written as a full PostalAddress object carrying separate street, city, region and postal code fields rather than one line of plain text. Without all three, the page is not eligible for a rich result at all.

What should I add beyond those three required properties?

Opening hours as an OpeningHoursSpecification, geographic coordinates, a price range, and sameAs links to verified profiles such as the Google Business Profile and main social accounts. None of these are required for eligibility, but they are what a system actually has to work with once a business qualifies.

Should I add review or rating schema too?

Only if the business has real, visible reviews on the page the markup sits on. Rating or review schema with nothing matching visible on the page is a mismatch guidelines treat as a trust problem, not a shortcut to stars in search results.

What is the single most common mistake?

Stale opening hours. A schema block that still claims a business is open on a day it now closes, or at hours it changed months ago, tells a system that checks it against reality that the markup cannot be trusted, which undermines the properties that are still accurate.

See whether your local business schema actually holds up to a system checking it.

Get a visibility audit or talk to the studio