Before you go
Know What’s Costing Your Business Leads.
Get a practical Growth Plan that shows where your visibility, website and lead response may be limiting results—and which improvements deserve attention first.
No obligationNo shared leadsNo generic plan
Implementation-first guide for contractors to add and validate LocalBusiness JSON-LD. Add the four baseline fields, choose the right subtype, and run a...
Local business schema is a JSON-LD code block that tells search engines and AI systems exactly who your business is, where it operates, and how to reach it. The single most important action is adding a validated JSON-LD block with four baseline properties (name, address, telephone, and hours) plus the most specific business subtype you can find. Skip the generic version and skip guessing at formatting: both cost you visibility.
TL;DR:
- Precise NAP data matching your Google Business Profile, including address, phone, and hours, is crucial for local pack visibility and accurate AI citations.
- Using specific subtypes like Restaurant or AutoRepair instead of generic LocalBusiness unlocks category-specific properties that improve search relevance and rich result eligibility.
- Implement validating your JSON-LD schema with Google’s Rich Results Test and Schema.org validator regularly, especially after site updates or hours changes.
- Consistency in
@idvalues across pages and correct formatting of hours and address fields prevent common schema errors that weaken local SEO signals.- Treat your schema as the primary source of truth for your business data and update it first, ensuring all online profiles mirror your structured data for maximum visibility advantages.
Local business schema is a structured data format built on the Schema, a specification maintained collaboratively by Google, Microsoft, Yahoo, and Yandex. It sits underneath the broader Organization and Place types, inheriting their properties while adding location and hours specific to brick-and-mortar and service-area businesses. Think of it as a structured business card written in a language machines can parse instantly, instead of a paragraph they have to interpret.
Search engines and AI systems build what’s called an entity graph, a web of connected facts about a business, its location, and its relationships to other entities. Schema.org exists specifically to feed that graph consistently across billions of web pages. When your markup matches your actual business details, you’re handing search engines and large language models a verified data point instead of asking them to scrape and guess from your homepage copy.
That matters more now than it did five years ago, because AI Overviews and chat-based answer engines pull facts directly from structured sources rather than crawling prose. A clean LocalBusiness block with data that matches your Google Business Profile materially raises your odds of surfacing in AI Overviews and local pack results.
Three concrete outcomes follow from getting this right:
Google’s structured data guidelines split LocalBusiness properties into two tiers: what’s required for eligibility and what’s recommended for stronger results. Skipping the required tier means your page may not qualify for certain rich results at all, according to Google Search Central’s local business documentation.
The four baseline properties are non-negotiable:
PostalAddress object, never a flat string.Beyond that baseline, several properties consistently strengthen how confidently search engines and AI systems handle your listing:
| Property | Format | Why it helps |
|---|---|---|
| geo | latitude/longitude decimal | Anchors your business to a precise map point |
| url | canonical homepage or location page URL | Confirms which page represents the entity |
| image | absolute URL to a real photo | Required for many visual rich result types |
| sameAs | array of profile URLs (Facebook, GBP, Yelp) | Links your entity across the web for verification |
| aggregateRating | ratingValue and reviewCount | Signals credibility, but must match your actual review data |
| priceRange | symbol or range like "$$ " | Sets buyer expectations before the click |
| areaServed | city, region, or GeoShape | Critical for service-area businesses without a public storefront |
Formatting mistakes sink otherwise-correct markup more often than missing fields do. Use E.164 format for telephone numbers (a plus sign, country code, then digits with no spaces or parentheses). Use ISO 3166-1 alpha-2 codes for addressCountry (“US,” not “United States”). Time values in openingHoursSpecification need hh:mm:ss format, and the PostalAddress object must nest streetAddress, addressLocality, addressRegion, postalCode, and addressCountry as separate properties rather than one combined string.
Schema.org lists dozens of LocalBusiness child types, and picking the generic LocalBusiness type when a specific one exists is one of the most common ways businesses leave visibility on the table. A pizza shop marked up as plain LocalBusiness gets treated as a vague local entity. The same shop marked up as Restaurant unlocks category-specific properties and improves how AI systems select businesses for “best pizza in [city]” style queries, since specificity consistently strengthens category matching.
Subtype selection also opens the door to properties that generic LocalBusiness doesn’t support:
servesCuisine, menu, and acceptsReservations.medicalSpecialty and availableService.Check the Schema.org LocalBusiness type page for the full subtype tree before defaulting to generic. If your business genuinely doesn’t fit any listed subtype, generic LocalBusiness is an acceptable fallback. Just don’t reach for it out of laziness when a closer match exists three clicks away.
JSON-LD is the format both Schema.org and Google recommend over Microdata or RDFa, mainly because it’s easier to validate and doesn’t require inline HTML attribute changes scattered across a template. Here’s a skeleton pattern for a single-location business:
{
"@context": "https://schema.org",
"@type": "Restaurant",
"@id": "https://example.com/#business",
"name": "Example Business Name",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main St",
"addressLocality": "Charlotte",
"addressRegion": "NC",
"postalCode": "28202",
"addressCountry": "US"
},
"telephone": "+17045551234",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "09:00:00",
"closes": "17:00:00"
}
],
"geo": {
"@type": "GeoCoordinates",
"latitude": 35.2271,
"longitude": -80.8431
},
"url": "https://example.com",
"image": "https://example.com/storefront.jpg",
"sameAs": [
"https://www.facebook.com/examplebusiness",
"https://www.yelp.com/biz/examplebusiness"
]
}
Three implementation habits separate schema that actually works from schema that quietly fails:
@id per business entity, referenced consistently on every page. Duplicate @id values across pages dilute the entity signal instead of reinforcing it.Pro Tip: Store your NAP data in a single JSON file or database table and pull it into every page’s schema block programmatically. Manually editing five location pages every time your hours change is how mismatches happen.
For a service-area business with no public storefront, drop the address object or mark it explicitly as not applicable, and lean on areaServed with a list of cities or a GeoShape radius instead. For multi-location businesses, each location page gets its own LocalBusiness block with a unique @id, while the site’s Organization schema stays sitewide on the homepage.
Deployment strategy depends entirely on how many locations you run and whether you serve customers at a fixed address or travel to them.
LocalBusiness block on the homepage, ideally duplicated or referenced on the contact page for redundancy.LocalBusiness block on each location’s dedicated page, each with its own @id, address, and phone number, while a sitewide Organization schema block on the homepage ties the brand together.areaServed with named cities, counties, or a GeoShape radius, since publishing a fake or residential address to satisfy the address field creates its own NAP problems.On WordPress, most SEO plugins offer LocalBusiness schema modules, though many default to generic fields that need manual editing to reach subtype-level specificity. On headless frameworks like Next.js or Gatsby, JSON-LD typically gets injected through a shared layout component pulling from a centralized content model, which keeps every page’s schema synchronized without manual duplication. Whatever platform you’re on, a local SEO services partner or in-house developer should confirm the schema renders in the initial HTML response, not just in the rendered DOM after JavaScript executes.
Never publish schema changes without running them through a validation sequence first. Skipping this step is how businesses end up with silent errors that suppress rich results for months before anyone notices traffic dipped.
The workflow that catches the most issues, in order:
In the Rich Results Test, treat errors as blockers and warnings as items worth reviewing, though not always fixing immediately; a warning about a missing optional field like aggregateRating isn’t the same severity as a hard error on a required property. In the Schema.org validator, pay closest attention to type mismatch warnings, where a property expects one Schema.org type but receives another.
Once markup is live, monitor it through Search Console’s Enhancements reports, which flag new errors as Google recrawls your pages. Set a recurring calendar reminder, quarterly at minimum, to spot-check your schema again, since hours changes, address updates, or a CMS migration can silently break a block that validated perfectly the day you launched it.
Most schema failures trace back to a short list of repeatable errors, not exotic edge cases.
@id values. Copy-pasting the same block across location pages without updating the @id creates confusion about which entity a page actually represents.LocalBusiness when a specific subtype like Dentist or Plumber exists forfeits category-specific rich result eligibility.openingHoursSpecification objects with proper hh:mm:ss times breaks parsing entirely.aggregateRating in schema that doesn’t match your visible on-page reviews can trigger manual action risk under Google’s guidelines.Pro Tip: Before deploying any schema update, open your Google Business Profile and your website side by side. If the name, address, or phone number don’t match exactly, fix that first, since no amount of correct JSON-LD compensates for inconsistent NAP data across platforms.
A five-minute QA pass before every deployment: confirm the @id is unique and consistent, confirm the subtype is the most specific available, confirm hours use structured format, confirm NAP matches your Google Business Profile exactly, and run both validators before calling it done.
Way of Marketing runs local business schema audits as a standard part of technical SEO engagements for contractors and service businesses, because markup errors surface constantly during migrations, redesigns, and plugin updates. The process follows a consistent sequence rather than a one-off spot check.
@id values across all location pages so each entity resolves to exactly one canonical record.For single-location businesses, this process typically wraps within a single audit cycle. Multi-location clients take longer, since every location page needs its own validated block plus a reconciled Organization layer tying the brand together. Common findings during these audits are cataloged in more detail in Way of Marketing’s breakdown of audit findings for NC and SC businesses, where duplicate @id values and hours formatting errors turn up more often than almost anything else.
Most business owners still think of their website copy as their primary source of truth. That’s backwards now. AI systems and search engines increasingly trust the structured data behind the page more than the prose sitting on top of it, because prose requires interpretation and structured data doesn’t.
If you fix nothing else this year, fix these four things in order: make your NAP data identical everywhere it appears, pick the most specific subtype your business actually fits, add sameAs links to every legitimate profile you control, and get your geo coordinates exact rather than approximate. Those four moves solve more visibility problems than most technical SEO checklists twice their length.
Pro Tip: Treat your schema block as the single source of truth for your business facts, and update your website first when anything changes, not last. Every other platform, from Google Business Profile to Yelp, should mirror what your schema already says, not the other way around.
— Jason
Wayofmarketing is the alternative to guessing your way through structured data. For contractors and owner-operated businesses across the Carolinas, we run a full schema audit that checks your JSON-LD against your Google Business Profile field by field, fixes duplicate @id values, and builds out multi-location markup correctly the first time instead of patching it later. Most owners running their own website don’t have hours to spend cross-referencing validator warnings against Schema.org’s property list, and a single mismatched phone number can quietly cost you rich result eligibility for months.
Start with a conversion-focused audit of your current setup through our service page SEO breakdown, where schema, page structure, and conversion elements get evaluated together rather than in isolation. If you’re ready to see what a full local SEO engagement looks like, reach out through Wayofmarketing and we’ll walk your current markup line by line.
Local business schema is a JSON-LD structured data block based on the Schema.org LocalBusiness type that tells search engines and AI systems your business name, address, phone number, hours, and category in a machine-readable format.
A basic example includes @type: "LocalBusiness" (or a more specific subtype like Restaurant), a nested PostalAddress object, a telephone field in E.164 format (a plus sign, country code, then digits with no spaces or parentheses), and an openingHoursSpecification array listing structured hours, as shown in the JSON-LD template above.
Paste a validated JSON-LD block containing your NAP data and hours into your homepage or location page’s HTML, ideally rendered server-side, then confirm it passes both the Rich Results Test and the Schema.org validator before publishing.
Business schema is the general term for structured data types like Organization and LocalBusiness that describe a company’s identity, location, and operational details in a format search engines and AI systems can read directly rather than infer from page text.
