LocalBusiness Schema

What LocalBusiness schema is

LocalBusiness is a schema.org type, a child of both Organization and Place, that describes a business customers physically visit or that serves a local area. Implemented as JSON-LD in a script tag, it hands Google a machine-readable fact sheet: legal name, street address, coordinates, phone, opening hours, price range, and what kind of business this actually is. Google documents it as a supported rich result feature, and it is one of the schema types where the payoff is concrete: it feeds the local knowledge panel, helps Google reconcile your website with your Google Business Profile, and makes your hours and details eligible to surface directly in search.

This check flags pages representing a local business, typically the homepage, contact page, or location pages, that carry no LocalBusiness markup, or carry a generic Organization type where a specific local subtype belongs.

Why it matters for local SEO

Let me set expectations honestly, because schema vendors oversell this: LocalBusiness markup is not a ranking factor for the local pack. Proximity, relevance, and prominence drive local rankings, and your Google Business Profile is the primary lever. What the markup does is different, and still worth the hour it takes:

• Entity confirmation. Google builds an entity graph of businesses. When your site's structured data, your GBP listing, and citations across the web all state identical name, address, and phone data, you make the entity unambiguous. Ambiguity is the enemy in local: mismatched data across sources makes Google less confident about every fact it shows.
• Rich result eligibility. Hours, price range, and review data (when you legitimately have on-page reviews) can surface in knowledge panels and rich snippets. Google's own local business documentation shows hours and business details pulled from markup.
• Multi-location disambiguation. For businesses with several branches, per-location pages with per-location markup are how you tell Google that the Austin office and the Dallas office are distinct entities with distinct hours and phones, rather than one blurry brand.
• AI surfaces read it too. Assistants and AI search features that ground answers in structured facts have an easier time recommending a business whose hours, service area, and category are machine-readable. Cheap insurance for wherever local discovery goes next.

The anatomy of a solid implementation

How to implement it, step by step

1. Pick the most specific subtype. Schema.org lists dozens of LocalBusiness children: Restaurant, Dentist, Attorney, AutoRepair, Plumber, HairSalon, and so on. Use the one that fits. Falling back to plain LocalBusiness is acceptable only when nothing closer exists. Specific typing is free relevance information; wasting it is just lazy.
2. Build the JSON-LD. Google requires name and address as a nested PostalAddress, and recommends geo coordinates, telephone, url, image, priceRange, and openingHoursSpecification. Copy the values from your Google Business Profile character for character, suite numbers and phone formatting included. This is the NAP consistency part, and it is where most implementations quietly fail.
3. Handle hours properly. Use openingHoursSpecification with dayOfWeek, opens, and closes in 24-hour format. For a 24/7 business, use opens 00:00 and closes 23:59. Remember this markup does not update itself for holidays; GBP special hours handle that.
4. Place it once per entity. Homepage for a single-location business. For multi-location businesses, each location page gets its own markup with that location's data, and each should link to its own GBP listing. Do not stamp the same head-office address on every page of the site through a theme-wide plugin default.
5. Connect the graph. Give the business an @id, point url at the canonical page, and use sameAs for your GBP-adjacent profiles (Facebook, Yelp, industry directories). This helps stitch the entity together across the web.
6. Validate and monitor. Run the page through Google's Rich Results Test for eligibility and the Schema Markup Validator at validator.schema.org for syntax. After deployment, watch Search Console's enhancement and structured data reports for parsing errors. Screaming Frog with structured data extraction enabled will audit markup across all location pages in one crawl.

Property reference

Do this, not that

What good looks like

Each location has one canonical page carrying one JSON-LD block with a specific subtype, NAP identical to its Google Business Profile, coordinates, structured hours, and an @id tying the entity together. The Rich Results Test passes clean, Search Console shows zero structured data errors, and when you search the business name, the knowledge panel shows the right category, current hours, and the right website link. Nothing about the markup contradicts anything Google can see elsewhere. Boring, consistent, and machine-verifiable is exactly the goal.

FAQ