Schema.org JSON-LD: A Practical Guide for Local Business Sites (2026)

Most local business sites either have no structured data at all, or they have a plugin-generated blob that’s full of errors nobody checked. Both are worse than doing nothing, because broken markup sends Google conflicting signals. Here’s what actually matters in 2026, with code you can adapt today.

Schema.org markup is just a vocabulary. You describe your business, your services, your reviews, and your hours in a format search engines can parse without guessing. JSON-LD is the delivery method Google recommends, and it lives in a <script> tag in your page’s <head> or <body>. That’s the whole concept. Everything else is details.

Why JSON-LD Beats Microdata and RDFa

You have three ways to add structured data. Microdata uses HTML attributes sprinkled through your markup. RDFa does something similar with different attributes. JSON-LD is a separate block of JSON that doesn’t touch your HTML structure at all.

That separation is the reason to pick it. Your templates stay clean, your CMS doesn’t fight you, and you can generate the JSON from your database or your page data without rewriting markup. Google’s documentation explicitly recommends JSON-LD. Bing parses it fine. There’s no real argument for the other two in 2026 unless you’re maintaining a legacy site.

The Types That Actually Move the Needle

There are over 800 schema types. You need maybe five. Here’s what’s worth your time for a local or service-based business:

• LocalBusiness (or a subtype like Plumber, Attorney, Restaurant). This is your foundation. Name, address, phone, hours, geo coordinates, service area.
• Service. Describes what you sell, who provides it, and what area it covers.
• FAQPage. Still generates rich results in many cases, though Google has narrowed when it shows them. Worth having if you have genuine Q&A content.
• BreadcrumbList. Helps Google understand your site structure and can replace the URL in search results with a cleaner path.
• Article or BlogPosting. For your content pages, with author and date.
• Review or AggregateRating. Only if the reviews are real and visible on the page. More on this below.

Skip Organization if you already have LocalBusiness. They overlap and having both on the same page creates noise. Pick the most specific type that fits and go with it.

A Real LocalBusiness Example

Here’s a working block for a service business. Note the @id field. It gives this entity a permanent identifier you can reference from other pages on your site, which is how you avoid repeating the full business definition everywhere.

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "LocalBusiness",
 "@id": "https://example.com/#business",
 "name": "Example Plumbing Co",
 "url": "https://example.com/",
 "telephone": "+1-631-555-0100",
 "image": "https://example.com/images/storefront.jpg",
 "priceRange": "$$",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "123 Main St",
 "addressLocality": "Commack",
 "addressRegion": "NY",
 "postalCode": "11725",
 "addressCountry": "US"
 },
 "geo": {
 "@type": "GeoCoordinates",
 "latitude": 40.8429,
 "longitude": -73.2929
 },
 "areaServed": [
 { "@type": "City", "name": "Commack" },
 { "@type": "City", "name": "Huntington" },
 { "@type": "City", "name": "Smithtown" }
 ],
 "openingHoursSpecification": [
 {
 "@type": "OpeningHoursSpecification",
 "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
 "opens": "08:00",
 "closes": "17:00"
 }
 ]
}
</script>

Two things people get wrong here. First, the phone number format. Use E.164 with the country code. 631-555-0100 is ambiguous across borders. +1-631-555-0100 is not. Second, areaServed should list places you genuinely serve, not every town in a fifty-mile radius. Inflating it doesn’t help and can look manipulative.

Referencing the Business From Other Pages

On your service pages, don’t repeat the whole business block. Reference it by @id:

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "Service",
 "name": "Emergency Drain Cleaning",
 "provider": { "@id": "https://example.com/#business" },
 "areaServed": { "@type": "City", "name": "Commack" },
 "description": "Same-day drain cleaning for residential and small commercial properties.",
 "offers": {
 "@type": "Offer",
 "priceCurrency": "USD",
 "availability": "https://schema.org/InStock"
 }
}
</script>

This is how you build a connected graph instead of a pile of disconnected fragments. Google’s systems handle entity resolution better when your markup points to consistent identifiers. If you run a WordPress site, most SEO plugins let you inject this per-page, but they won’t build the relationships for you. That part is still manual work, and it’s a big chunk of what real Long Island SEO involves beyond keyword targeting.

The Review Markup Trap

Since 2019 Google has been explicit: self-serving reviews marked up on your own site are not eligible for review rich results. If you mark up your own testimonials as AggregateRating, you’re not getting stars in search. You’re just adding noise, and in some cases you’re risking a manual action if the reviews are fabricated.

What works: third-party review platforms that Google recognizes, and genuine Review markup where the review is displayed on the page with a real author. If you’re not sure whether your reviews qualify, leave them unmarked. It’s not worth the risk.

FAQPage in 2026

Google cut back FAQ rich results significantly. They now show mainly for well-known authoritative government and health sites. That doesn’t mean the markup is useless. It still helps Google parse your content and can feed AI-generated answer surfaces. But don’t add a fake FAQ section just to get rich results. If you have real questions customers ask, mark them up:

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "FAQPage",
 "mainEntity": [
 {
 "@type": "Question",
 "name": "How much does a new website cost?",
 "acceptedAnswer": {
 "@type": "Answer",
 "text": "Typical small business sites run $3,000 to $12,000 depending on page count, custom functionality, and content work."
 }
 }
 ]
}
</script>

How to Validate Without Wasting an Afternoon

• Schema Markup Validator (validator.schema.org). Checks syntax and vocabulary. Fast.
• Google Rich Results Test. Tells you which rich result types your page qualifies for. Not a completeness check.
• Search Console Enhancements reports. This is the one that matters long term. It shows what Google actually parsed from your live pages and flags errors.

Run all three. The validator catches typos, the rich results test tells you what you might get, and Search Console tells you what you actually got. I’ve seen markup pass the first two and still fail in Search Console because of a duplicate entity or a missing required property.

Common Mistakes I See

• Multiple LocalBusiness blocks on the same page with different data. Pick one.
• NAP data that doesn’t match your Google Business Profile. Mismatches hurt more than missing markup.
• Marking up content that isn’t visible on the page. Google requires parity between markup and page content.
• Using @type: Organization when you should use a specific local type. Specificity wins.
• Forgetting to update hours markup when hours change. Stale data is worse than none.

If you’re building this into a custom CMS or a headless setup, generating the JSON server-side from your business data is cleaner than hand-editing blocks per page. That’s the kind of thing that falls under custom web development rather than a plugin install, and it pays off when you have fifty or more pages to keep consistent.

FAQ

Does schema markup directly improve my rankings?

Not directly. Google has said structured data is not a ranking factor. What it does is help Google understand your content, which can earn rich results, improve click-through rate, and reduce ambiguity about your business. Those things compound into better performance over time.

Can I just use my SEO plugin’s built-in schema?

You can, and for simple sites it’s often fine. The problem is plugins generate generic markup that rarely connects entities properly and often duplicates types across pages. If your site is more than a handful of pages, it’s worth auditing what the plugin outputs and fixing gaps manually.

How often should I update my structured data?

Whenever the underlying facts change: hours, location, services, pricing ranges, or contact info. Set a calendar reminder to re-validate quarterly. Search Console will flag new errors, but it won’t flag stale-but-valid data.