Schema markup is the difference between Google guessing what your business does and Google knowing exactly what your business does. For local businesses, that distinction controls whether you show up with a rich, detailed listing or a bare-bones blue link that nobody clicks.
This guide covers the specific schema types that matter for local businesses, how to build them from scratch in JSON-LD, and how to catch the errors that tools miss but Google doesn’t.
What Schema Markup Does for Local Businesses (and What It Doesn’t)
How Search Engines Read Structured Data vs Plain HTML
Search engines are good at reading text. They can figure out that “123 Main Street” is probably an address and “9am-5pm” is probably business hours. But “probably” is doing heavy lifting in that sentence.
Structured data removes the guessing. When you wrap your business name, address, phone number, hours, and services in schema markup, you hand Google a labeled dataset instead of a paragraph to interpret. The markup says: this is the business name, this is the phone number, these are the hours on Tuesday. No ambiguity.
Google, Bing, and AI platforms like ChatGPT and Perplexity all parse schema markup. When these systems need to recommend a dentist or explain which plumber is open on Saturday, they pull from structured data first because it is machine-readable by design.
JSON-LD remains Google’s recommended format in 2026. Microdata and RDFa still work, but they are harder to maintain and carry higher structural error risk because they are interleaved with HTML rather than sitting in a clean data block.
The Difference Between Rich Results and Ranking Boosts
Schema markup does not directly boost your ranking position. Google has said this repeatedly, and the data supports it. What schema does is qualify your listing for rich results: star ratings, business hours, price ranges, and other visual elements that appear directly in search results.
Rich results change click behavior. A listing showing 4.7 stars, “Open now,” and a price range gets clicked more than a plain blue link. That higher click-through rate sends behavioral signals back to Google, which can indirectly improve rankings over time.
The distinction matters because businesses that implement schema expecting an instant ranking jump will be disappointed. The payoff is in visibility, click-through rate, and increasingly, in AI citation. AI Overviews and conversational AI tools prioritize structured data as a source signal. Businesses with clean schema get cited more often in AI-generated answers.
Which Schema Types Matter for Local Businesses
LocalBusiness and Its Subtypes (Restaurant, MedicalBusiness, LegalService, etc.)
LocalBusiness is a subtype of both Organization and Place in the schema.org hierarchy, which means it inherits properties from both. This is the foundation schema for any business with a physical location or defined service area.
The most common mistake is using generic LocalBusiness when a more specific subtype exists. Google prefers specificity. Use Dentist, not LocalBusiness, for a dental clinic. Use Restaurant, not LocalBusiness, for a restaurant.
Available subtypes include: Restaurant, DaySpa, HealthClub, LegalService, Dentist, HVACBusiness, RealEstateAgent, AutomotiveBusiness, ProfessionalService, MedicalBusiness, Store, FinancialService, and dozens more. Check schema.org/LocalBusiness for the full list.
Do not replace LocalBusiness with Organization for a physical business. Organization lacks location-specific properties, and using it weakens the local signals Google extracts from your markup.
GeoCoordinates and PostalAddress: Getting the Location Layer Right
The address property uses PostalAddress, and the geo property uses GeoCoordinates. Both are required for complete local schema.
PostalAddress includes: streetAddress, addressLocality (city), addressRegion (state), postalCode, and addressCountry. Every field should match your Google Business Profile exactly. Character-for-character consistency matters because Google cross-references these data points.
GeoCoordinates take latitude and longitude. Use your exact business location coordinates, not an approximation. Google Maps can give you precise coordinates by right-clicking your location and copying them.
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street",
"addressLocality": "Macon",
"addressRegion": "GA",
"postalCode": "31201",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 32.8407,
"longitude": -83.6324
}OpeningHoursSpecification: Why Your Hours Markup Probably Has Errors
Hours markup is where most schema implementations break. The OpeningHoursSpecification format requires separate entries for each unique schedule pattern.
Common errors: listing hours as a single string instead of structured entries, forgetting to mark closed days, using 12-hour format instead of 24-hour format (schema uses 24-hour), and failing to update holiday hours.
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:00",
"closes": "17:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Saturday",
"opens": "09:00",
"closes": "13:00"
}
]If your business is closed on Sunday, you simply omit Sunday from the specification. Do not create an entry with opens and closes set to the same time. Google interprets that inconsistently.
AggregateRating and Review Markup: What Google Still Supports
Google still supports AggregateRating markup for LocalBusiness, but the rules have tightened. The rating shown in markup must match ratings visible on the page. If your markup says 4.8 stars from 127 reviews, those numbers need to appear in the page content where users can see them.
Marking up ratings that are not visible on the page violates Google’s guidelines and risks a manual action.
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.8",
"reviewCount": "127",
"bestRating": "5"
}Self-served review markup (where you control the reviews displayed) faces more scrutiny than third-party review markup. Google’s preference is that review stars come from independent platforms.
Step-by-Step Implementation
JSON-LD vs Microdata: Which Format to Use and Why
Use JSON-LD. The decision is straightforward in 2026.
JSON-LD sits in a script tag, separate from your HTML. You can add it, edit it, and debug it without touching page layout. Microdata is embedded directly in HTML elements, which means every content change risks breaking the markup, and every markup change risks breaking the layout.
JSON-LD can be placed in the head or body of the page. There is no performance difference because JSON-LD is a data linking format that does not trigger server requests or render-blocking behavior.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Dentist",
"name": "Macon Family Dental",
...
}
</script>Building Your First LocalBusiness JSON-LD Block from Scratch
Here is the minimum viable schema for a single-location local business. Every property listed below is either required or strongly recommended by Google:
{
"@context": "https://schema.org",
"@type": "Dentist",
"name": "Macon Family Dental",
"image": "https://www.maconfamilydental.com/images/office-front.jpg",
"url": "https://www.maconfamilydental.com",
"telephone": "+1-478-555-0123",
"priceRange": "$$",
"address": {
"@type": "PostalAddress",
"streetAddress": "456 Cherry Street",
"addressLocality": "Macon",
"addressRegion": "GA",
"postalCode": "31201",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 32.8407,
"longitude": -83.6324
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:00",
"closes": "17:00"
}
],
"sameAs": [
"https://www.facebook.com/maconfamilydental",
"https://www.instagram.com/maconfamilydental"
]
}For a single-location business, the recommended minimum schema stack is: WebSite + Organization + LocalBusiness (or subtype) + Service schemas. These can coexist on the same page without conflict when each has a unique @id.
Adding Service, Menu, and PriceRange Properties
The hasOfferCatalog property lets you list specific services with pricing:
"hasOfferCatalog": {
"@type": "OfferCatalog",
"name": "Dental Services",
"itemListElement": [
{
"@type": "Offer",
"itemOffered": {
"@type": "Service",
"name": "Teeth Cleaning",
"description": "Professional dental cleaning and examination"
}
},
{
"@type": "Offer",
"itemOffered": {
"@type": "Service",
"name": "Dental Implants",
"description": "Single tooth and full arch implant placement"
}
}
]
}priceRange uses dollar signs ($, $$, $$$, $$$$) as a relative indicator. It is deliberately vague because Google does not enforce or display exact pricing from this field.
For restaurants, use the Menu, MenuSection, and MenuItem schema types instead of generic service markup.
Multi-Location Schema: One Page per Location or Nested Markup
Each physical location needs its own page with its own LocalBusiness schema block. Do not nest multiple locations into a single page’s schema. Google processes one primary entity per page.
Each location page should contain: a unique LocalBusiness (or subtype) block with that location’s specific name, address, phone, hours, and coordinates, a unique @id that distinguishes this entity from other locations, and cross-references to the parent organization using the parentOrganization property.
{
"@type": "Dentist",
"@id": "https://www.example.com/locations/macon/#dentist",
"name": "Example Dental - Macon",
"parentOrganization": {
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "Example Dental Group"
}
}CMS plugins like Rank Math, Yoast, and Schema Pro can automate multi-location schema. But plugins often create duplicate schemas when not configured properly. Always audit plugin-generated markup by viewing page source and checking for multiple JSON-LD blocks that describe the same entity.
Testing and Validation
Google Rich Results Test vs Schema.org Validator: What Each Catches
These are different tools that catch different problems. Using only one leaves gaps.
Schema Markup Validator (validator.schema.org) validates all schema.org types regardless of Google support. It checks syntax, missing required properties, deprecated elements, and format compliance. It replaced the old Structured Data Testing Tool in August 2021. Use this first to catch structural errors.
Google Rich Results Test (search.google.com/test/rich-results) only validates schema types that Google supports for rich results. It shows whether your markup qualifies for rich result display and provides a SERP preview. Use this second to verify eligibility.
The key difference: the Rich Results Test only cares about Google’s subset of schema. The Schema Markup Validator catches everything, including types that AI platforms like ChatGPT and Perplexity rely on for entity understanding but Google does not display as rich results.
Best practice workflow: fix syntax and nesting issues with the Schema Markup Validator first, then verify rich result eligibility with the Rich Results Test, then monitor live performance via Google Search Console’s Enhancements report.
Common Errors That Pass Validation but Fail in Practice
A schema block can be syntactically perfect and still cause problems. These are the errors that validators miss but Google catches:
Marking up invisible content. If your schema describes a 4.8-star rating but no rating appears on the visible page, Google may flag this as a guidelines violation. Every data point in schema should have a visible counterpart on the page.
Rating mismatches. Your markup says 4.8 stars from 127 reviews. Your page shows 4.6 stars from 89 reviews. Google sees the conflict.
Copying templates without editing. The schema shows “Your Business Name” or “123 Example Street” because someone pasted a template and forgot to fill it in. This happens more often than it should.
Multiple business types on one page. A page with both a Restaurant and a Dentist schema block confuses Google’s entity processing. One primary business type per page.
Duplicate schema across pages. If every page on your site has identical LocalBusiness markup pointing to the same entity, Google may ignore all of it. The homepage or dedicated location page should carry the primary LocalBusiness schema.
Using the wrong business subtype. A Dentist marked as MedicalBusiness misses subtype-specific rich result eligibility. Always use the most specific available type.
Monitoring Schema Performance in Search Console
Reading the Enhancements Report for Local Markup
Within 48 to 72 hours of deploying schema on a live page, Google Search Console’s Enhancements report begins showing how Google interprets your markup. Navigate to Enhancements in the left sidebar and look for your specific markup type.
The report shows three categories: Valid (working correctly), Valid with warnings (working but could be improved), and Errors (broken or non-compliant).
Click into any error to see which pages are affected and what specifically is wrong. Common issues include missing required fields, invalid URLs, and format errors in date or time values.
Monitor this report monthly. Schema can break silently when CMS updates change page structure, when developers modify templates, or when CDN caching serves stale versions of pages.
When Google Ignores Your Markup and What to Do About It
Google may index your schema without error but choose not to display rich results. This is not a bug. Google’s algorithms decide whether rich results serve the user for a given query.
Reasons Google might ignore valid markup:
The page has low authority or thin content. Schema enhances already-solid pages. It cannot compensate for weak content.
The markup is technically correct but Google does not support rich results for that specific schema type. The Schema Markup Validator may show it as valid while the Rich Results Test shows no eligibility.
Google is testing. Rich result display can fluctuate during algorithm updates. If your markup was displaying rich results and stops, check Search Console for new errors before assuming a policy change.
Common gotcha: schema that works in a local development environment may fail in production due to CDN caching, build process differences, or JavaScript rendering issues. Always test the live production URL, not a staging or local version.
If rich results disappear and no errors show in Search Console, wait two weeks before making changes. Temporary fluctuations are normal. If the issue persists, re-validate your markup, check for recent site changes that might have affected the schema, and resubmit the affected pages for indexing.
This guide covers LocalBusiness schema and its subtypes only. For FAQPage schema implementation, see our FAQ Schema guide. For Event schema, see our guide on turning local events into SEO assets. Schema types serve different purposes and should not be mixed without understanding their interaction patterns.
Schema specifications evolve. The implementation details in this guide are current as of February 2026. Google’s structured data documentation at developers.google.com/search/docs/appearance/structured-data/local-business is the authoritative source for any changes to supported properties or validation rules.