Structured Data for Local Businesses: A Practical 2026 Guide
Structured data is JSON-LD markup that tells Google what your business is, where you serve, and when you're open. It won't lift rankings on its own, but it makes you eligible for review stars, hours, and FAQ rich results. Start with one accurate LocalBusiness block per location.
Part of the complete SEO guide.
On this page
- What structured data actually does (and doesn’t do)
- Start with LocalBusiness, done properly
- Use @id to tie everything together
- Ratings and reviews: the part people get wrong
- Service pages, FAQs, and breadcrumbs
- How to test before you ship
- Keep it consistent everywhere Your structured data needs to match your Google Business Profile, your site footer, and your contact page exactly. Same business name, same address, same phone. If your GBP says “Harbor Plumbing Co.” and your schema says “Harbor Plumbing and Heating,” you’re splitting your entity and weakening both. Pick the canonical version and use it everywhere, character for character. FAQ
- Do I need structured data if I’m a one-person business?
- Will structured data get me into AI search results?
- How often should I update it?
Most local business sites have either no structured data or a mess of it that contradicts itself. Google uses that markup to build knowledge panels, show review stars, and figure out your hours and service area, so getting it right is worth an afternoon. Here’s what actually matters in 2026 and how to implement it without guessing.
What structured data actually does (and doesn’t do)
Structured data is JSON-LD code you drop in the page that describes your business in a vocabulary Google understands. It does not boost rankings by itself. What it does is make you eligible for enhanced results: star ratings, business hours, price ranges, FAQ accordions, breadcrumbs. It also feeds the knowledge graph, which is how Google decides what entity your site represents.
If you run a service business on Long Island, that entity clarity matters. When someone searches “emergency plumber Nassau County” and your markup clearly states you serve Nassau and Suffolk with 24/7 availability, you’re giving Google a reason to surface you over a competitor whose markup is silent.
Start with LocalBusiness, done properly
LocalBusiness is the base type. Every local site should have exactly one of these per physical location. The most common mistakes I see: wrong @type (using generic LocalBusiness when a more specific subtype exists), missing geo coordinates, and hours written as free text instead of structured.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Plumber",
"@id": "https://example.com/#business",
"name": "Harbor Plumbing Co.",
"url": "https://example.com",
"telephone": "+1-516-555-0142",
"priceRange": "$$",
"address": {
"@type": "PostalAddress",
"streetAddress": "120 Main St",
"addressLocality": "Hicksville",
"addressRegion": "NY",
"postalCode": "11801",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 40.7684,
"longitude": -73.5251
},
"areaServed": [
{ "@type": "AdministrativeArea", "name": "Nassau County, NY" },
{ "@type": "AdministrativeArea", "name": "Suffolk County, NY" }
],
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "08:00",
"closes": "18:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Saturday",
"opens": "09:00",
"closes": "14:00"
}
]
}
</script>Use the most specific subtype you can. Google recognizes hundreds: Plumber, Dentist, Electrician, Restaurant, LegalService. If a precise type exists for your trade, use it. It costs nothing and gives Google more signal.
Use @id to tie everything together
That "@id" field above is worth calling out. It gives your business a permanent identifier. Every other piece of markup on your site (reviews, articles, service pages) can reference that same @id instead of re-declaring the whole business. This is how you avoid the “two different businesses” problem where Google sees conflicting data and trusts none of it.
Ratings and reviews: the part people get wrong
You cannot mark up reviews you collected on a third-party site and display them as your own on your site. That violates Google’s structured data policies and can earn a manual action. You can mark up reviews that are genuinely on your page, submitted by real customers, and visible to users.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "AggregateRating",
"itemReviewed": { "@id": "https://example.com/#business" },
"ratingValue": "4.8",
"reviewCount": "127"
}
</script>If your reviews are on Google Business Profile or Yelp, leave them there. Don’t copy the numbers onto your site as AggregateRating. The rich result will get pulled and you’ll wonder why your stars vanished.
Service pages, FAQs, and breadcrumbs
Three more types earn their keep for local service sites:
- Service schema on individual service pages, with
providerpointing back to your business@idandareaServedlisting the towns you cover. - FAQPage for genuine question-and-answer content. Google has scaled back FAQ rich results in search, but the markup still helps with entity understanding and can show in AI-driven answer surfaces.
- BreadcrumbList so Google shows a clean path instead of a raw URL in results.
One FAQ block per page, and the questions need to actually appear on the page as visible text. Marking up content that users can’t see is cloaking.
How to test before you ship
Run every page through Google’s Rich Results Test and the Schema Markup Validator. Then check the URL Inspection tool in Search Console to see what Google actually parsed after it recrawled. Those three tools catch 95% of problems: invalid JSON, missing required fields, and types Google doesn’t recognize.
Common failures I see constantly:
- Trailing commas in the JSON, which breaks the whole block silently.
- Multiple conflicting LocalBusiness blocks on the same page.
- Hours in 12-hour format with AM/PM instead of the required 24-hour ISO format.
- Phone numbers with parentheses and dashes instead of E.164 (
+15165550142). - Markup injected by a plugin that duplicates what’s already in the theme.
That last one is the most common on WordPress sites. Two plugins both outputting LocalBusiness schema is worse than having none. If you’re not sure what’s generating your markup, a quick audit is worth doing before you add more. If the site is built on a stack where you control the templates, hand-writing the JSON-LD is almost always cleaner than stacking plugins. That’s part of why I usually recommend custom web development for local businesses that care about this stuff, since you own the markup instead of fighting a plugin.
Keep it consistent everywhere
Your structured data needs to match your Google Business Profile, your site footer, and your contact page exactly. Same business name, same address, same phone. If your GBP says “Harbor Plumbing Co.” and your schema says “Harbor Plumbing and Heating,” you’re splitting your entity and weakening both. Pick the canonical version and use it everywhere, character for character.
FAQ
Do I need structured data if I’m a one-person business?
Yes, and you benefit most from it. Small operators rely on local search, and clear markup is how you compete with bigger firms that have more content and more backlinks. It’s a leveling tool.
Will structured data get me into AI search results?
It helps. AI answer engines lean on structured, unambiguous data to decide what a page is about and whether to cite it. Clean schema doesn’t guarantee inclusion, but messy or missing schema makes you harder to trust.
How often should I update it?
Whenever something changes: hours, address, services, pricing model. Set a reminder to re-validate quarterly. Stale hours in your markup are worse than no hours at all.
