Guides

Local Business Schema: Facts a Search Engine Can Read

Local business schema is structured data, written in schema.org's LocalBusiness vocabulary, that states the hard facts about a physical or service-area business in a form search engines read without interpretation: name, address, phone, hours, geographic coordinates, and the category you operate under. It does not change a single pixel of what a human sees on the page.

The point is disambiguation. Your homepage might mention your city, your phone number, and your hours in three different places, formatted three different ways. Schema puts those facts in one labeled, machine-readable block so a crawler does not have to guess which string is the address and which is a nearby landmark. Think of a crawler reading your site the way a stranger would, with no prior knowledge of your trade, your city, or which of the three phone numbers on the page is the one to call. The markup settles every one of those questions in advance. That certainty is what makes the markup worth adding, and it is the whole reason the format exists.

What local business schema actually is

Schema.org is a shared vocabulary maintained by the major search engines. LocalBusiness is one type inside it, a subtype of Organization that adds the properties a storefront or service business needs: a postal address, opening hours, and a service area. You express it in JSON-LD, a small script block that sits in the page's HTML and carries the data as labeled key-value pairs.

LocalBusiness also has hundreds of more specific subtypes. Dentist, Plumber, AutoRepair, Attorney, HairSalon, and Restaurant each inherit everything LocalBusiness offers and add fields that fit the trade. Using the most specific type that genuinely describes you beats defaulting to the generic one, because it tells the engine exactly what kind of entity it is reading.

What belongs in the markup

A complete block mirrors the facts a customer needs to find you and act. At minimum, include:

@type: the most specific LocalBusiness subtype that fits your business.

name: your exact trading name, spelled the same way everywhere else online.

address: a PostalAddress object with street, locality, region, postal code, and country as separate fields, not one run-on string.

telephone: the number in international format, matching the one on your contact page.

openingHoursSpecification: each day's hours, including seasonal and holiday variation where it applies.

geo: latitude and longitude, so maps can place you precisely instead of geocoding a street string.

url and image: your canonical site address and a representative photo or logo.

sameAs: links to your verified profiles, which help engines tie the markup to the same entity elsewhere.

Two optional properties come up constantly. areaServed names the cities or regions you cover, which matters for service businesses without a walk-in storefront. priceRange expresses a rough cost tier in relative terms, never a quoted figure. Add them when they are true, and leave them out when they are not. Hours deserve particular care, because an openingHoursSpecification block can carry regular weekly times together with dated exceptions for holidays, so the facts a searcher reads late on a public holiday match the door they will actually find open.

One block per location

A business with several branches should not cram every address into a single block. Give each location its own page and its own LocalBusiness block, each with its own geo coordinates and hours. That way an engine can treat every branch as a distinct place and connect a nearby searcher to the closest one.

How engines and AI assistants use it

Structured data does not earn a position. It earns comprehension. When the facts in your markup agree with your Google Business Profile and the visible text on the page, the engine assembles a confident picture of your business as one entity. That confidence is what engines and assistants rely on when they build map features, the knowledge panel, and the short factual answers that AI tools stitch together from trusted sources.

The reverse is the real risk. If your schema lists one address and your Business Profile lists another, you have handed the engine a contradiction to resolve, and it may resolve it by trusting neither. Consistency across your site, your markup, and your third-party listings is the entire game. The markup is only ever as useful as it is accurate.

This matters more as search shifts toward answers. AI assistants and large language models lean on structured, trustworthy data when they decide which business to name in a response. Clean local business schema gives them a tidy set of facts to quote, rather than leaving them to scrape a contradiction out of your page and your listings. It is not a guarantee of being cited, but it removes a reason to be skipped.

JSON-LD is the format to use

Google recommends JSON-LD over the older microdata and RDFa approaches. JSON-LD keeps the data in one script block instead of threading attributes through your visible HTML, which makes it far easier to maintain and far harder to break during a redesign. It can live in the head or the body; position does not matter as long as it is present in the served HTML.

Validation is not optional. Before a block goes live, run it through Google's Rich Results Test, which parses the markup the way the crawler does and flags any missing required field, then confirm the vocabulary itself against the schema.org validator. Catching a warning before launch costs a few minutes. A silent error can sit undetected for months, quietly telling engines something false about the business it describes.

Mistakes that quietly cost you

Defaulting to generic LocalBusiness when a precise subtype exists for your trade.

Marking up facts that appear nowhere on the visible page, which breaks Google's structured data guidelines.

Letting the name, address, or phone drift out of sync with your Business Profile and directory listings.

Packing one block for a multi-location business instead of one block per location page.

Inventing a review or star rating in markup. Rating and review fields carry their own strict rules, which our review schema guide covers in full.

Most of these come from treating schema as a checkbox rather than a description. The markup is a claim about reality. When the claim and reality match, it works quietly in the background. When they drift apart, it does nothing at best and undercuts your credibility at worst.

How we build and maintain it

Ninetyfifth Marketing treats local business schema as part of a site's technical foundation, not a plugin bolted on at the end. Because we optimize only the sites we build, the markup is generated from the same source of truth as the visible content, so the two cannot silently disagree. When your hours or service area change, both update in the same edit. That single source of truth is the difference between markup that stays honest for years and markup that rots the first time someone edits the footer.

The deliverable is a validated JSON-LD block for each location, mapped to the most specific type, kept in step with your Business Profile, and checked against Google's Rich Results Test and the schema.org validator before it ships. For the full scope of technical and local work that sits alongside it, see our SEO service details and pricing.

Questions

Is local business schema a ranking factor?

No. Structured data is not a ranking signal on its own. It helps search engines understand and trust the facts about your business, which can make you eligible for richer results and clearer entity matching, but it does not move you up the list by itself. Accuracy and consistency are what make it worthwhile.

What is the difference between LocalBusiness schema and my Google Business Profile?

Your Business Profile is a listing you manage inside Google's own system. Local business schema is markup on your website that states the same facts in a format any search engine can read. They should always agree with each other. When they match, you reinforce a single consistent picture of your business; when they conflict, you create doubt.

Which LocalBusiness type should I use?

Use the most specific subtype that honestly describes what you do, such as Dentist, Plumber, or Restaurant. If no specific subtype fits, fall back to the generic LocalBusiness type. The more precise you are, the more clearly an engine understands the kind of business it is reading, so avoid defaulting to the generic type out of habit.

Can I add star ratings to my local business schema?

Only if the ratings are real, collected by you, and shown on the page itself. Review and rating fields have strict guidelines, and inventing them or pulling them from third-party sites can trigger a manual penalty. When in doubt, leave ratings out and handle them through the proper review markup rules instead.

Where do I put the schema on my site?

Place a JSON-LD script block on each page that represents a location, usually your homepage and any dedicated location pages. For a single-location business, your homepage or contact page is the natural home. For multiple locations, give each its own page and its own block so engines can tell the branches apart.