The ultimate guide to local business schema markup
Search engines and AI assistants do not read your website the way a person does. They build a structured model of your business from the signals they can parse cleanly, and schema markup is how you hand them that model directly instead of hoping they infer it from your page copy. For a local business, the schema that matters most is LocalBusiness. This guide covers exactly how to implement it.
Local business schema is structured data, usually written in JSON-LD using the schema.org LocalBusiness type, that describes a business to search engines and AI systems in a machine-readable format. It declares facts like name, address, geo-coordinates, phone number, opening hours, and linked profiles so engines can identify the business as a distinct entity rather than guessing from page text.
What is LocalBusiness schema, and why does it matter?
LocalBusiness is a schema.org type for a physical, place-based business that serves customers at or from a specific location. Marking up your site with it hands search engines and AI assistants an explicit, parseable description of who you are and where you operate, rather than leaving them to infer it from prose. Clear structured data makes your business easier to identify, disambiguate, and cite.
Schema.org is a shared vocabulary, maintained collaboratively by Google, Microsoft, Yahoo and Yandex, for describing things on the web (schema.org, 2026). LocalBusiness is one type in it, sitting under the more general Organization and Place types. Adding it to your pages is not decoration. It attaches a formal set of statements a machine can read without ambiguity.
This matters more for local businesses than for most sites because of disambiguation. Page copy alone leaves an engine to guess which of many similarly named companies a page describes. Structured data removes the guesswork by stating the name, exact address, coordinates and phone number in dedicated fields the engine trusts.
That clean entity description feeds the systems that decide whether to show you. Google uses structured data to understand page content and to enable certain rich results (Google, 2026)[1], and AI assistants increasingly assemble answers from structured, corroborated facts. Getting LocalBusiness markup right is foundational, which is why we treat it as the base layer of the work on our schema markup services page.
What are the required and recommended properties of LocalBusiness markup?
Google recommends a core set of properties: name, address, and either geo-coordinates or a matching Google Business Profile so the listing can be identified. Beyond that, telephone, url, openingHoursSpecification, priceRange, image, and sameAs all sharpen the entity. The address itself is a nested PostalAddress, and coordinates are a nested GeoCoordinates object, so accuracy in those child fields is what makes the markup useful.
Start with identity. The "name" is your exact business name as it appears on your storefront and Google Business Profile, with no keyword stuffing appended. The "address" is not a string but a nested PostalAddress object with separate streetAddress, addressLocality (city), addressRegion (state), postalCode, and addressCountry fields (schema.org, 2026). Splitting the address into components is what lets an engine match it against map data.
Add location and contact. The "geo" property takes a GeoCoordinates object with "latitude" and "longitude" that should match the address. "telephone" carries a full international-format number, and "url" the canonical homepage. For hours, prefer "openingHoursSpecification", which uses OpeningHoursSpecification objects with dayOfWeek, opens, and closes, because it handles split shifts and per-day variation more cleanly than the older "openingHours" string.
Then enrich. "priceRange" gives a rough band, "image" points to a real photo, and "aggregateRating" can express a review score but only under the strict conditions covered below. Finally "sameAs" takes an array of URLs to your authoritative profiles: Google Business Profile, Facebook, LinkedIn, Yelp, industry directories. Those links help engines connect the entity you describe with one they already know.
Should you use a LocalBusiness subtype instead of the generic type?
Yes, when an accurate subtype exists. schema.org defines many specific subtypes under LocalBusiness, such as Restaurant, Dentist, Attorney, Plumber, and HomeAndConstructionBusiness. Using the most specific type that genuinely fits describes your business more precisely than the generic LocalBusiness. If no subtype matches your trade, using LocalBusiness itself is correct rather than forcing an inaccurate one.
schema.org organizes types as a hierarchy. LocalBusiness has a large tree of subtypes, each inheriting every property of its parents while sometimes adding its own (schema.org, 2026)[2]. A Restaurant is a LocalBusiness with extra properties like servesCuisine and menu, so declaring "@type" as "Restaurant" tells an engine everything LocalBusiness would plus that you serve food.
The practical rule is to pick the most specific type that is truthfully accurate, and no more specific. A family law firm is an "Attorney" or "LegalService", a clinic a "MedicalBusiness", a home remodeler a "HomeAndConstructionBusiness". A wrong subtype is worse than a general one, so never choose a type your business is not.
If your trade has no matching subtype, do not bend to a near-miss. The generic "LocalBusiness" type is a legitimate, fully supported choice. You can also express two truths at once by giving "@type" an array, for instance ["LocalBusiness", "ProfessionalService"], when both apply. What you should avoid is stretching a specific medical or legal subtype onto a business it does not describe.
JSON-LD or microdata: which format should you use?
Use JSON-LD. Google explicitly recommends JSON-LD for structured data, and it is far easier to maintain (Google, 2026). JSON-LD lives in a single script block in the page head or body, separate from your visible HTML, so it does not entangle markup with content. Microdata and RDFa are still valid schema.org syntaxes, but they interleave attributes through your HTML and are harder to keep correct.
JSON-LD stands for JavaScript Object Notation for Linked Data. In practice it is a single script tag, type "application/ld+json", holding a JSON object that opens with "@context" set to "https://schema.org" and "@type" set to your business type. Everything about the business lives in that one block. Because it is decoupled from the rendered HTML, you can generate it from a template and change it without touching layout.
Microdata, by contrast, decorates your HTML with itemscope, itemtype, and itemprop attributes spread across the elements that display each fact. It works, and Google still reads it, but every content edit risks breaking a property, and auditing it means reading the whole page rather than one block. RDFa is a third valid syntax with the same drawback. All three express the same schema.org vocabulary; they differ only in how they attach it.
One caution specific to JSON-LD: many crawlers and parsers do not execute JavaScript, so structured data injected client-side may never be seen. Render your JSON-LD in the initial server response rather than relying on a tag manager to build it after load. If the markup is not in the raw HTML, treat it as invisible to anything that does not run scripts.
How do you connect entities with @id?
The "@id" property gives a node a stable, unique identifier, usually a URL fragment like "https://example.com/#localbusiness". Once a node has an @id, other nodes can reference it by that id instead of redefining it. This lets you build one connected graph, linking your LocalBusiness, Organization, WebSite, and WebPage nodes together, so engines see a single coherent entity rather than scattered, unrelated blocks.
Without @id, each schema block is an island. Your homepage might declare a LocalBusiness and your about page a separate Organization, with nothing telling an engine they are the same company. Assigning a canonical "@id" to your primary business node, then pointing to it from elsewhere, stitches those descriptions into one entity. The id need not resolve to a real page; it just needs to be unique and consistent.
A common pattern links the layers of your site: the WebPage references the WebSite via "isPartOf", the WebSite references the Organization or LocalBusiness that publishes it, and a page about the business points to the LocalBusiness node with "@id". Using the same "@id" string across every page keeps the graph consistent site-wide, instead of minting a new, disconnected entity on each URL.
This is where local business schema stops being a per-page checkbox and becomes entity architecture. Engines reward clarity about who the entity is, and a well-linked graph is far clearer than isolated snippets. Internally you connect your own nodes with @id; externally you link your other profiles with sameAs; together they define one unambiguous business.
How should you handle address, geo, and opening hours accurately?
These three fields are where most markup quietly goes wrong. The PostalAddress must match your Google Business Profile and citations character for character. The GeoCoordinates must actually point at the address. Opening hours, ideally as OpeningHoursSpecification objects, must match your posted hours. Structured data that contradicts your real-world listings is worse than none, because it introduces conflict rather than clarity.
Address consistency is the whole point. The streetAddress, addressLocality, addressRegion, and postalCode in your PostalAddress should be byte-for-byte the same as your Google Business Profile and citations. "Suite 313" in your markup and "#313" on Google is the kind of small contradiction that blurs an entity. Pick one canonical format and use it everywhere.
Geo-coordinates should be pulled from a real lookup of your address, not typed from memory or copied from a nearby pin. A latitude and longitude that lands a block away, or in the wrong part of town, gives an engine a reason to distrust the rest of your data. Verify the point against a map before you ship it.
For hours, OpeningHoursSpecification handles reality better than the terse "openingHours" string. Each object takes a "dayOfWeek", an "opens" time and a "closes" time in 24-hour format, and you can add separate objects for split shifts or days that differ. Keep these synchronized with your Google Business Profile, because stale hours in schema are a factual error an engine can catch.
How do you validate LocalBusiness schema?
Validate in two places. The Schema Markup Validator at validator.schema.org checks that your markup is syntactically valid schema.org against the vocabulary. Google's Rich Results Test checks whether Google can read the markup and whether the page is eligible for any rich result. Passing the schema validator confirms correctness; the Rich Results Test confirms Google's specific requirements. Use both, because they answer different questions.
The Schema Markup Validator, at validator.schema.org, is the general-purpose tool (schema.org, 2026)[3]. Paste a URL or snippet and it parses every node, lists the types and properties it found, and flags anything that is not valid schema.org. It does not judge whether Google will show a rich result; it tells you whether your structured data is well-formed and uses real properties. That is the first gate to clear.
Google's Rich Results Test, at search.google.com/test/rich-results, answers the Google-specific question (Google, 2026)[4]. It reports whether Googlebot can fetch and render the page, which supported structured-data features the page is eligible for, and any errors against Google's own requirements, which are stricter than schema.org in places. Because it renders the page as Googlebot, it also reveals whether script-injected JSON-LD actually appears.
Once a page is indexed, the Rich Results status reports in Google Search Console track valid, warning, and error items over time, which is how you catch regressions after a template change. The sequence is simple: build the JSON-LD, clear the Schema Markup Validator, confirm eligibility in the Rich Results Test, then monitor Search Console. Validation is not one-time.
What are the most common LocalBusiness schema mistakes?
The frequent failures are predictable: marking up data that is not visible on the page, faking or self-serving aggregateRating, injecting JSON-LD only via client-side script, letting the address or hours drift out of sync with Google, and choosing an inaccurate type. Each either violates Google's guidelines or feeds engines a contradiction. Correct markup describes what is genuinely on the page and true in the world.
The rule engines enforce hardest is that structured data must reflect visible content and real facts. Do not mark up a phone number, rating, or address that does not appear on the page. The aggregateRating field is a particular trap: Google's guidelines require ratings to be genuine, sourced, and about the specific business, and marking up ratings a user cannot see can trigger a manual action rather than a star result.
The second cluster is technical invisibility and inconsistency. JSON-LD that only appears after a tag manager runs may never be read by crawlers that do not execute JavaScript, so render it server-side. An address, phone number, or set of hours that contradicts your Google Business Profile actively harms the entity clarity the markup exists to create. Consistency across schema, page, and profile is not optional.
The third is misuse of types and orphaned nodes: forcing an inaccurate subtype onto a business, or scattering unconnected LocalBusiness blocks with no shared @id. And do not expect deprecated features to return. Google restricted FAQ rich results to a narrow set of authoritative sources and retired HowTo results, so adding FAQPage markup for a rich result it no longer grants is wasted effort (Google, 2026)[5]. Mark up FAQs for accuracy and AI readability if you like, but not for stars that will not appear.
Turn on what makes AI recommend you.
AI recommends the businesses it can read, trust and quote. Flip on the four signals we engineer, and watch your visibility climb and the answer rewrite itself.
Illustrative · the four signals are the real system we build
This article, answered.
The questions readers ask about this topic, answered the way an answer engine would. No forms, no sales pitch.
Pick a question on the left — you'll get the direct answer, the way an answer engine would give it.
LAST UPDATED July 10, 2026 · WRITTEN BY JAMIE KLONCZ, FOUNDER · SEO ELITE AGENCY, NAPLES FL
Enter a path and click verify.