What is a local business schema? LocalBusiness Schema markup, and what it has to contain

People write the phrase two ways: local business schema in plain English, and LocalBusiness in the vocabulary's own spelling. They are the same thing. LocalBusiness is the schema.org type, and a local business schema is the block of structured data that uses it — the JSON-LD a site publishes so that a machine can take a business's facts as data instead of inferring them from prose.

Schema.org LocalBusiness is a standardized vocabulary of structured data tags that physical businesses embed in their website HTML (typically via JSON-LD) to explicitly declare their identity, location, hours, and services to search engine algorithms.

While human visitors read visual headlines and text paragraphs, search crawlers parse structured JSON-LD graphs, so the facts in the markup are read rather than inferred.

Which type to declare

LocalBusiness is the generic type, and for most local trades it is the right answer. It is not the most specific one available, though, and the specific one says more.

Dentist, LegalService, PlumbingContractor, AccountingService, GeneralContractor, Restaurant, BeautySalon — these are all subtypes of LocalBusiness. A machine reading one of them learns the trade as well as the location: the generic type says a business at this address, the subtype says a plumber at this address.

The rule is that the type has to be one the page can support. A site with no address, no telephone number and no opening hours cannot support LocalBusiness at all — there is nothing local about it — and declaring it anyway is a claim the markup cannot back. A site that does have those facts and no more specific trade gets LocalBusiness; a site that sets a business type gets that type. How to verify your LocalBusiness structured data sets out that rule as it actually runs.

What LocalBusiness Schema Does, and What It Does Not

When a user searches for a high-intent query like "dentist near me", the map result that answers it comes from a Google Business Profile, not from this page. The profile is the listing; the schema on your website is a declaration of the same facts.

That distinction decides what the markup is worth. Google's local ranking weighs three things:

1. Relevance: does the business match the requested service?
2. Prominence: is the business authoritative and verified?
3. Distance: is the business within the user's geographic radius?

A LocalBusiness block supplies the facts two of those are computed from — your category, your address, your coordinates — so Google does not have to infer them from prose, and so the listing and the website cannot quietly disagree. It supplies nothing for the second: prominence comes from reviews, citations and history, none of which markup can assert. And it does not create, reserve or populate a map result. What it does is make your site legible to a machine, and keep it in agreement with the profile you already maintain.

Essential Properties of a Complete Schema Graph

A comprehensive LocalBusiness JSON-LD markup must include:

• @type: Specific industry subtype (such as Dentist, LegalService, PlumbingContractor, AccountingService, GeneralContractor, Restaurant, BeautySalon) rather than generic Organization.
• name & url: Official commercial legal name and canonical URL.
• telephone: Standard E.164 formatted contact number for click-to-call mobile actions.
• address: Structured postal address with street, city, postalCode, and addressCountry.
• geo: Exact GeoCoordinates specifying latitude and longitude.
• openingHoursSpecification: Precise opening and closing hours for each day of the week.
• priceRange: Indicative pricing tier (e.g., "$$", "$$$").
• areaServed: The places the business covers, named as place entities.
• hasOfferCatalog: The services the business sells, as Service

entities in a catalogue.

• hasCredential: The licence, the certification or the insurance the

business holds, with a credentialCategory.

• amenityFeature: The physical features a customer filters on — parking,

showers, a waiting area.

• servesCuisine: The cuisine, for a business that serves one.

The same list as a document, which is what the markup actually looks like:

json
{
  "@type": "Dentist",
  "@id": "https://yourbrand.com/#organization",
  "name": "Your Brand Dental",
  "url": "https://yourbrand.com/",
  "telephone": "+1-555-0100",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "18 Example Street",
    "addressLocality": "Portland",
    "addressRegion": "OR",
    "postalCode": "97204",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 45.5152,
    "longitude": -122.6784
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Monday",
      "opens": "09:00",
      "closes": "17:00"
    }
  ]
}

Every property above is one the renderer emits, and every one of them is one you set — the @type is a subtype rather than Organization, and the @id is the entity the rest of the page's schema refers to.

The document a machine reads

Two things about the markup are worth separating, because they get confused more often than anything else in structured data.

The graph. The @id is not decoration. It is the identifier of the entity every other part of the page's schema refers to — the service catalogue, the credentials, the opening hours all hang off that one entity, and a consumer that reads the graph can follow them. Site structure, and where your copy lives covers which part of a site the block is written from.

The duplication. Every field above is a fact the page already shows somewhere else: the address in the footer, the hours on the contact page, the services on the pricing page. That is why the markup is derived rather than written. A hand-written block is a second copy of facts you will change, and two copies drift — which is the disagreement the markup exists to prevent.

How to check what you actually published

Structured data is the one part of a site you can check completely, because it is a document you can read. The short version of the procedure:

1. Fetch the published page, not the preview. The preview and the live

site can differ, and a schema that is only right in one of them is not right.

1. Find the <script type="application/ld+json"> block in the page source,

and read it as a document rather than as a string.

1. Check the type: LocalBusiness, Organization, or the subtype you

set? If you expected LocalBusiness and got Organization, the cause is almost always one of three fields — no address, no telephone, no hours.

1. Check that the address is complete. A postal address with a locality

and a region but no street address will not place a pin.

1. Check that the hours match the page. Hours that contradict the page

are worse than no hours.

1. Then run Google's Rich Results Test against the live URL. It tells you

whether the block parses and what it complains about. It does not tell you whether the business is real, which is the part that actually decides a local result.

How to verify your LocalBusiness structured data is the whole procedure, including the fields that decide the type.

Automated Schema on Zeso

On Zeso, site owners never write JSON-LD markup by hand. When you set your business hours, address, and service categories in your business profile, Zeso emits the Schema.org markup for you on every page, built from the same details the page already shows, so the two cannot drift apart. The type is set the same way: a business type in the profile gives you the subtype, and address, telephone and opening hours together make the entity a LocalBusiness rather than a generic Organization.