Local schema markup (LocalBusiness) is JSON-LD that tells search engines your business’s exact name and full postal address. Add both right now, and use the most specific subtype your business qualifies for, such as Restaurant or Dentist, instead of the generic LocalBusiness type. That single move gives search engines accurate facts to work with and opens the door to richer search results.
What local business schema does for search and AI answers
LocalBusiness structured data comes from the Schema, a shared set of definitions that search engines and other systems used to read your website’s content as structured facts instead of guesswork. JSON-LD is the format we recommend for delivering that vocabulary, since it sits in a single script block and does not require tagging every visible element on the page.
Once in place, that markup feeds several places your business can show up: knowledge panels, “open now” labels in search results, local carousels, and increasingly, the AI assistants and generative answer features that pull business facts directly from structured data rather than crawling prose. A chatbot or AI search tool answering “is this pharmacy open right now” needs your hours in a predictable, machine-readable format to answer correctly.
What markup does not do is guarantee placement. Adding LocalBusiness schema makes you eligible for certain rich results and features, it does not select you for them. Google still weighs relevance, content quality, and other ranking signals before deciding what appears in a knowledge panel or carousel.
A few things to keep in mind as you plan your implementation:
- Markup must describe facts that are genuinely visible on the page, not information invented for search engines.
- The most specific subtype available unlocks category-specific properties, which can matter for how a restaurant, dentist, or spa appears in search features.
- Eligibility is necessary but not sufficient. Clean markup gets you considered, not guaranteed.
Required and high-value properties for your LocalBusiness markup
Google’s structured data guidance sets a clear baseline: the `name` and `address` properties are required for any LocalBusiness object. The address should be a full `PostalAddress` object, not a flat string, with distinct `streetAddress`, `addressLocality`, `addressRegion`, `postalCode`, and `addressCountry` fields. Skipping this structure, or collapsing it into one text field, is one of the most common reasons markup fails validation.
Beyond the required pair, a set of recommended properties meaningfully improves how your listing can appear:
- `url`: your canonical business website address, not a social profile or directory page.
- `telephone`: formatted with a country code so it resolves correctly regardless of where the searcher is.
- `geo`: latitude and longitude coordinates, ideally to five decimal places or more for location precision.
- `image`: a representative photo of your business, storefront, or primary product.
- `openingHoursSpecification`: structured hours rather than a plain-text description.
- `priceRange`: a short price indicator, kept under 100 characters.
Google’s own documentation names `name` and `address` as the only required fields for LocalBusiness (Google Search Central), with properties like geo and opening hours called out as recommended additions that improve quality and visibility. That distinction matters when you are prioritizing a backlog: get the required fields flawless first, then layer in the recommended ones.
A few formatting rules prevent silent failures. Opening hours should use 24-hour time values, since a validator will reject or misinterpret a 12-hour format with AM/PM text mixed in. Coordinates benefit from real precision rather than rounded estimates, since a geo value that only resolves to the city center defeats the purpose of including it at all. Your `priceRange` string needs to stay short and simple, something like “$$” or “$10-$30,” rather than a paragraph of pricing explanation. And the `name` value in your schema should match your Google Business Profile listing exactly. A mismatch between what your schema says and what your Business Profile says creates the kind of inconsistency that weakens local signals rather than strengthening them.
Ready-to-use JSON-LD examples for common business types
Seeing the structure in context makes it easier to adapt than reading property lists alone. Here is a single-location restaurant example that uses a specific subtype and includes the visual and menu-related properties that can matter for restaurant carousels:
{
"@context": "https://schema.org",
"@type": "Restaurant",
"name": "Example Bistro",
"image": "https://example.com/images/storefront.jpg",
"servesCuisine": "Italian",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street",
"addressLocality": "Springfield",
"addressRegion": "IL",
"postalCode": "62704",
"addressCountry": "US"
},
"telephone": "+1-217-555-0142",
"url": "https://example.com",
"priceRange": "$$",
"menu": "https://example.com/menu"
}A service-area business, one that travels to customers rather than operating from a storefront, drops the fixed address expectations and instead uses `areaServed`:
{
"@context": "https://schema.org",
"@type": "Plumber",
"name": "Example Plumbing Co.",
"areaServed": ["Springfield", "Riverton", "Chatham"],
"telephone": "+1-217-555-0199",
"url": "https://example.com"
}For hours that change seasonally, `openingHoursSpecification` with `validFrom` and `validThrough` dates is the more reliable pattern than the plain-text shorthand:
When you template this across pages, decide early whether a property should be a single object or an array. A business with one phone number and one address uses single objects; a multi-location brand with several service areas or multiple images typically needs arrays so each location page can pull its own values from a shared structure.
Getting local business schema live on your site
Implementation goes smoother when you treat it as a system rather than a series of one-off edits. A practical sequence looks like this:
- Pick a single source of truth. Whether that is CMS custom fields, a location database, or a dedicated business registry, every schema value should pull from one place rather than being typed separately into each page.
- Generate JSON-LD from that source instead of hand-writing it per page. Templating prevents the slow drift that happens when someone updates a phone number on the page but forgets the matching schema field.
- Assign stable `@id` values to your Organization and Location nodes so the same entity can be referenced consistently across your homepage, location pages, and related content, forming a connected graph rather than disconnected fragments.
- Build the template once in your CMS. WordPress sites typically handle this through a theme function, a structured data plugin, or a custom field group tied to a template partial; custom CMS platforms need an equivalent componentized approach so the markup updates automatically when the underlying content does.
- Run a deployment checklist before publishing: visible-content parity (nothing in the markup that is not on the page), an exact name and address match with your Google Business Profile, full coordinate precision, and phone numbers formatted with country codes.
- Incomplete `PostalAddress` objects missing one or more required sub-properties like `addressRegion` or `postalCode`.
- Geo coordinates with insufficient decimal precision to represent a specific location.
- Opening hours written in an invalid format, often 12-hour time values where 24-hour format is expected.
- Markup describing content that is not actually visible anywhere on the rendered page, which can make a result ineligible even when the syntax validates cleanly.
Pro Tip: Store your business name and address once in a CMS field group, then reference that field group in every template that needs schema, rather than retyping values page by page.
If your business operates across several locations, this same source-of-truth approach scales by treating each location as its own node connected back to a parent Organization. Our guide to multi-location SEO walks through the data governance side of that in more detail.
Validating and troubleshooting your structured data
Once markup is live, confirming it actually works matters as much as writing it correctly in the first place. Google’s Rich Results Test checks whether your markup is valid and shows which rich result types it qualifies for, while Search Console’s enhancement reports flag indexing and processing issues over time, which catches problems that only show up after a crawl.
Third-party validators, including tools like Greadme, run similar checks and tend to flag a consistent set of issues:
A schedule matters here too. Treat validation as an ongoing check rather than a one-time task: a quarterly audit, or an automated check tied to your content workflow, catches drift before it accumulates across dozens of pages.
Keeping schema accurate as your business and site grow
Markup that was correct on launch day degrades quietly if nobody owns it. A move, a new phone line, or a rebrand can leave your JSON-LD pointing at stale facts while the visible page has already been updated, and that kind of mismatch is exactly what weakens local signals over time.
Assigning clear ownership solves most of this. One person or team should hold responsibility for the schema on each node type, whether that is the main Organization entity or each individual location page, with a simple agreement about who updates what when business details change.
Reusing stable `@id` values across your site is the technical backbone of that ownership. A central entity registry, even a simple spreadsheet mapping each location to its `@id` and data fields, gives whoever maintains the site one place to check before making an update anywhere else.
For teams running regular site updates, folding schema checks into your existing content or deployment workflow, essentially a lightweight automated test that flags a missing required property before a page goes live, catches problems far earlier than discovering them in a Search Console report weeks later. Multi-location brands benefit from nesting department or sub-location objects consistently, so a shared registry can validate each child node against the same required fields as the parent.
What we check first and why: an agency checklist for schema rollouts
Before we touch a line of JSON-LD for a client, we reconcile citations and the Google Business Profile listing first. Schema that contradicts a mismatched directory listing or an out-of-date Business Profile just propagates the same error in a new format. Our citation audit process exists specifically to catch those mismatches before deployment.
From there, we build schema into the site template itself rather than treating it as an add-on, so it stays tied to the same conversion-focused layout and updates automatically as content changes. We monitor markup health alongside the rest of a client’s local presence, watching for the kind of drift that happens naturally as businesses add locations, update hours, or rebrand.
Schema alone will not win you the map pack
Structured data earns you eligibility, not placement. We have seen businesses with flawless JSON-LD still lose out to a competitor with stronger reviews, better citation consistency, or a more complete Google Business Profile, because schema is one input among several, not a shortcut past the others.
The practical move is coordination: treat schema, Google Business Profile accuracy, and review generation as one connected effort rather than separate projects handled by different people on different timelines. When that coordination becomes more than you can manage in-house, that is usually the point where bringing in a specialist pays for itself.
How we build and maintain local schema as part of your growth plan
We handle local schema implementation as one piece of a broader local visibility plan, not as an isolated technical task. That means reconciling your Google Business Profile and citations first, building JSON-LD into your site templates so it updates automatically, and layering in multi-location data management for businesses operating across several markets.
Review generation ties directly into this work too. Properties like `aggregateRating` depend on real, current review data, and our review automation service keeps that data flowing so your markup reflects accurate, up-to-date ratings rather than stale numbers.
If you want a clear picture of where your current schema, citations, and Business Profile stand before committing to anything, a Roadmap Analysis walks through all of it and hands you a custom 12-month growth plan . It is built so you can see exactly what needs fixing and in what order, before spending a dollar on implementation. Request your Roadmap Analysis and we will map out the specific steps your site needs.
Frequently Asked Questions
What is schema markup?
Schema markup is structured data, typically written in JSON-LD, that labels specific facts on a webpage, like a business name or address, so search engines can read them as data rather than plain text. The Schema.org vocabulary defines the standard set of types and properties used for this purpose, including LocalBusiness and its many subtypes.
Is schema markup still relevant?
Yes. Google’s own structured data documentation continues to require specific properties like `name` and `address` for LocalBusiness listings, and schema increasingly feeds AI-assisted search features that rely on structured facts rather than crawling unstructured page text. It remains a foundational part of how search engines and other systems interpret business information accurately.
Can you provide an example of schema markup?
A basic LocalBusiness example includes a `name`, a `PostalAddress` object with street, city, state, postal code, and country fields, plus recommended properties like `telephone` and `url`. A restaurant would use the more specific `Restaurant` subtype and add properties like `servesCuisine` and `menu` to take advantage of category-specific search features.
How do I know if my website has schema markup?
Run your page through Google’s Rich Results Test, which shows whether structured data is present and which rich result types it qualifies for. Search Console’s enhancement reports also flag existing structured data along with any processing errors over time.
Share This Article
Found this useful? Send it to another owner who is still the same questions keep coming up.
Share on Facebook · Share on X · Share on LinkedIn · Share on Pinterest
Want More Information? Let’s Talk.
If you would rather not take this on yourself, we handle it for you. Our Business Listings & Voice Search service takes care of the setup and the ongoing work, then reports back so you can see exactly what changed. You keep running your business; we keep this moving.
Call us at 631-825-9464 or reach out here. No pressure, no obligation, and you can ask us anything — including whether this is even worth doing for a business your size.
Looking ahead, request your roadmap analysis and we will map out a 12-month plan to close the conversion leaky bucket so more of the customers you already reach turn into booked work.
Written by Joe Leineke · Content on this blog is generated with AI assistance and independently reviewed and fact-checked by human marketing professionals for accuracy and quality.