Local business schema markup that's actually correct

LocalBusiness schema is a block of structured data — almost always written as JSON-LD — that states your business's name, address, phone number, hours and category in a format machines can parse directly, rather than infer from surrounding page text. It's worth being precise about what that buys you: valid markup helps search engines and AI systems read your page accurately. It does not guarantee a rich result, a knowledge panel, or an AI citation. Those outcomes depend on far more than markup, and no legitimate source can promise them.

A single-location example you can adapt

Pick the most specific type schema.org offers for your business — Restaurant, HairSalon, Store, Dentist — rather than the generic LocalBusiness type. Schema.org's own reference lists dozens of subtypes, and the more specific one gives search engines a clearer read on what you actually do.

Source: Schema.org: LocalBusiness type

{ "@context": "https://schema.org", "@type": "Restaurant", "@id": "https://example.com/#business", "name": "Example Restaurant", "image": "https://example.com/photo.jpg", "address": { "@type": "PostalAddress", "streetAddress": "123 Main St", "addressLocality": "Springfield", "addressRegion": "IL", "postalCode": "62704", "addressCountry": "US" }, "telephone": "+1-217-555-0100", "url": "https://example.com", "priceRange": "$$" }

Place the script in the page <head> (or just before the closing </body> tag), always starting with "@context": "https://schema.org". Give it a stable @id — a permanent URL fragment such as https://example.com/#business — so every other page that references this business points at the exact same entity.

What Google's documentation actually asks for

Google's structured data guidelines for LocalBusiness walk through the properties to add and how to validate them, and they're explicit that the most specific applicable subtype should be used rather than a generic fallback.

Source: Google Search Central: Local Business (LocalBusiness) structured data

• name — your exact business name, matching your website and your Google Business Profile.
• address — a PostalAddress object with streetAddress, addressLocality, addressRegion, postalCode and addressCountry as separate fields, not one combined string.
• telephone — include the country code so international crawlers and assistants parse it correctly.
• url — your canonical page URL, matching what's in your sitemap.
• image — at least one representative photo, ideally consistent with your Google Business Profile.

Beyond those, geo (a GeoCoordinates object), openingHoursSpecification, priceRange and sameAs (links to your official social and directory profiles) all meaningfully improve how confidently a machine can read your listing. Most small businesses only need a handful of the dozens of properties schema.org defines for LocalBusiness — reaching for every optional field rarely helps, and a malformed field (a badly formatted time string is a common one) can cause that property to be ignored entirely.

Adding it to your site

• Manual insertion — if you can edit template files or header includes, paste the JSON-LD directly into the page. This gives you full control over the @id structure.
• CMS plugins (Yoast, Rank Math, Schema Pro and similar) can generate this markup from a settings panel. Running two SEO plugins at once is a common cause of duplicate or conflicting schema on the same page — check for that specifically.
• Sitewide templates let you inject the core business JSON-LD once at the header or footer level, then override only what changes per page, like a specific location or service.

Insert JSON-LD server-side or as static, inline markup rather than relying entirely on client-side JavaScript to build it after the page loads — some crawl and parsing paths don't fully render JavaScript first. Confirm this by using "View Page Source" (not just your browser's inspector) to check that the JSON-LD is present in the raw HTML that gets delivered, not only in the rendered DOM.

Multi-location businesses need a different pattern

The common shortcut — copying one JSON-LD block across every location page and swapping the address — technically parses, but it creates ambiguity about which entity is which, especially when a search engine tries to reconcile your markup against separate Google Business Profile listings for each location.

• Give every physical location its own distinct JSON-LD block with its own stable @id, such as https://example.com/locations/springfield/#business.
• Use parentOrganization or branchOf to connect each location back to the parent business, so the hierarchy is explicit rather than implied.
• For services offered across locations, reference the location's @id from a Service object rather than repeating the full name and address on every service page.
• If your CMS holds locations in a database, generate the JSON-LD from that same database so one field update — a new phone number, changed hours — propagates everywhere automatically instead of requiring hand edits per page.
• Review each location's schema against its live listing data on a set schedule; hours change and phone numbers get ported, and markup that contradicts your Google Business Profile is worse than no markup.

Validating what you publish

Two tools check different things, and it's worth running both. Google's Rich Results Test tells you whether your markup is eligible for the enhanced display features Google currently supports — it flags Google-specific requirements, not just general syntax. A schema.org validator checks pure vocabulary correctness: whether your property names and types match the published spec.

• Run every new or edited page through Rich Results Test before publishing, not after.
• Check Search Console's structured data reports weekly for the first month after a deployment, then monthly.
• Revalidate any time hours, address or phone number change — these drift out of sync with visible content more than any other field.
• Treat errors and warnings differently: errors typically block rich result eligibility; warnings flag missing recommended fields that limit display options without breaking anything.

What breaks this, in practice

• A mismatch between your JSON-LD and your Google Business Profile — "123 Main Street" versus "123 Main St" — undermines the entity confidence schema is supposed to build. Pick one canonical format and use it everywhere.
• Choosing a generic LocalBusiness type when a specific subtype exists, which discards information search engines use to match your business to relevant queries.
• Marking up reviews that aren't genuine, visible on the page, or collected according to the platform's own review markup policies — this risks a manual action, not just a missed rich result.
• Letting your JSON-LD contradict your visible page — different hours in the markup than on the homepage — which reads as a red flag rather than picking one to trust.
• Injecting schema only through client-side JavaScript with no server-rendered fallback, so it's invisible to crawl paths that don't execute scripts.

Where schema actually sits in local SEO

Structured data is a reinforcement layer, not a foundation. It clarifies entity identity and strengthens machine-readable signals, but it does not by itself move a business up in local search results — that's driven far more by your Google Business Profile completeness, proximity to the searcher and review volume. If your Business Profile is incomplete or reviews are thin, fix those first; schema adds a real but smaller improvement in how confidently machines and AI tools can quote your business facts once the fundamentals are solid.