LocalBusiness schema and how to implement it in 2026

Your website says who you are, where you are and when you open, but it says it in a format designed for people. LocalBusiness schema is the way to tell search engines too, in a language that leaves no room for interpretation.

It's one of those jobs that doesn't give you an immediate traffic boost, so it always gets put off. But it's the foundation Google uses to build its idea of what entity you are, and that idea shapes everything else.

There's also a lot of confusion around this markup. People credit it with effects it doesn't have and overlook what it actually contributes.

In this article I'll explain exactly what it is, which properties matter, how to implement it with JSON-LD and how to validate it. And also what not to expect from it, so you don't end up disappointed.

What LocalBusiness markup is and what it doesn't do

LocalBusiness is a type in the schema.org vocabulary that describes a business with a physical presence. It descends from Organization and Place, and inherits most of its properties from them.

Its job is to remove ambiguity. Where a human sees "Calle Mayor 3, open 9 to 2," a search engine sees loose text that it has to interpret. With the markup, it sees an address field and an hours field, with no margin for error.

Now the part almost nobody clarifies: this markup doesn't rank your profile on the map. The block of three local results is fed by your Google Business Profile, not by your website's code. If you were hoping to climb on Maps by implementing schema, it's not going to happen.

What it does contribute still matters:

• It reinforces the understanding of your entity and the consistency between your website and other sources.
• It enables rich results in traditional search when they apply.
• It gives AI systems and assistants clean data about your business.

That idea of an entity connects directly with the work on semantic SEO and entities, of which the markup is the most mechanical part.

The properties that really matter

Schema.org defines dozens of properties for LocalBusiness. In practice, this handful covers what matters:

The sameAs property deserves a special mention: it's where you declare your social media and directory profiles. It plays a role similar to local SEO citations, confirming that all those sources are talking about the same business.

And one rule that avoids half the problems: only mark up information that's visible on the page. If your hours don't appear on the website but do appear in the code, you're breaking the guidelines and exposing yourself to a manual action.

Use the specific subtype, not plain LocalBusiness

This is the detail that separates a correct implementation from an excellent one. LocalBusiness has dozens of more specific subtypes, and using the one that fits you communicates much better what you do.

Some examples:

• Dentist for a dental clinic
• VeterinaryCare for a veterinary clinic
• Locksmith for a locksmith
• Restaurant for a restaurant
• LodgingBusiness for a hotel
• HealthAndBeautyBusiness for a beauty center

If there's a subtype that fits your business, use it instead of the generic one. It's free and it's more precise.

A complete example in JSON-LD, which is the format Google recommends, is this simple:

1. Declare the context and the type: @context pointing to schema.org and @type with your subtype.
2. Add the basic data: name, phone number, url and image.
3. Structure the address with a PostalAddress object that includes street, city, province, postcode and country.
4. Add the hours with OpeningHoursSpecification objects, one for each block of days with the same hours.
5. Paste the block inside a script tag of type application/ld+json in the head of the page.

Validate it before you call it done

Markup with a syntax error doesn't just work worse: it doesn't work at all. And you can't tell at a glance, because it's not visible on the page.

There are two tools, and it's worth running both:

1. Google's Rich Results Test (search.google.com/test/rich-results): it tells you whether Google can read it and whether it triggers any rich result.
2. The Schema Markup Validator (validator.schema.org): stricter about the vocabulary, it detects misspelled or wrongly nested properties.

The most frequent errors are always the same:

• The address entered as plain text instead of as a PostalAddress object.
• Hours in a format that doesn't follow the specification.
• Marking up data that doesn't appear on the page.
• Making up an average rating in aggregateRating with no real reviews behind it, which, besides breaking the guidelines, can cost you a manual penalty.

After publishing it, check the Enhancements reports in Search Console after a few days: that's where the errors Google detects while crawling will show up.

Quick checklist

• ☐ Specific subtype chosen instead of generic LocalBusiness
• ☐ Name, address, phone number and url included and matching your Google profile
• ☐ Address structured as PostalAddress
• ☐ Hours in openingHoursSpecification
• ☐ Only data that's visible on the page
• ☐ Markup on a single page per location
• ☐ Validated in both tools, with no errors
• ☐ Search Console Enhancements reports checked a few days later

LocalBusiness markup isn't magic and it won't lift you on the map by itself, but it's the cleanest way to make sure search engines don't have to guess anything about your business.

Done once and done right, it takes minutes to maintain when your hours or phone number change.

If you'd rather not wrestle with code, with local brain you can generate and maintain your business's structured data without touching your website template, with the guarantee that what gets published matches the data on your Google profile.