Schema for Local Business: A Practical Guide for Owners

LocalBusiness schema is a block of JSON-LD code that tells search engines your exact business name, address, phone number, and hours in a format machines can read without guessing. The payoff is stronger entity signals, not a guaranteed spot in the local pack, but it’s one of the few technical SEO fixes a solo owner can complete in an afternoon. Your single highest-leverage move: pick the most specific Schema that matches your business (Restaurant, Dentist, LawOffice, not the generic “LocalBusiness”) and make sure the name, address, and phone in that code match your Google Business Profile character for character.
Here’s what a minimal, working version looks like:
{
"@context": "https://schema.org",
"@type": "Plumber",
"name": "Anderson Plumbing Co.",
"url": "https://andersonplumbing.com",
"telephone": "+1-313-555-0142",
"address": {
"@type": "PostalAddress",
"streetAddress": "412 Woodward Ave",
"addressLocality": "Detroit",
"addressRegion": "MI",
"postalCode": "48226",
"addressCountry": "US"
},
"openingHoursSpecification": {
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:00",
"closes": "17:00"
}
}
Three things to add before anything else:
- Name, address, phone (NAP) exactly as they appear on your Google Business Profile listing.
- The correct subtype, not a generic label. A dentist marked up as plain “LocalBusiness” loses access to properties like
medicalSpecialty. - Placement on your homepage or a dedicated location page, wrapped in
<script type="application/ld+json">tags, ideally right before the closing</body>tag.
Schema doesn’t rank you higher on its own. It removes ambiguity, so when Google or an AI assistant has to decide what your business is and where it operates, there’s no guesswork left to get wrong.
Key Takeaways
Matching your schema subtype to your business and keeping NAP identical across your site and Google Business Profile is the single highest-leverage local SEO fix available to small business owners.
| Point | Details |
|---|---|
| Pick the specific subtype | Use Restaurant, LawOffice, Dentist, or similar instead of generic LocalBusiness for stronger entity signals. |
| Match NAP everywhere | Your schema, site content, and Google Business Profile must show identical name, address, and phone. |
| Add JSON-LD correctly | Place one LocalBusiness block per location, with a stable @id, on the homepage or location page. |
| Validate before trusting it | Run every page through Google’s Rich Results Test and monitor Search Console monthly. |
| Consider professional help at scale | Proxiumdigital builds schema into new sites from the start and monitors NAP alignment monthly for multi-location clients. |
Table of Contents
- What Schema for Local Business Actually Does vs. Google Business Profile
- Which Schema.org Subtype Fits Your Business?
- The Properties You Should Never Skip
- Step by Step: Writing and Deploying Your JSON-LD Block
- Copy-Ready Examples for Common Business Setups
- Testing Your Markup and Fixing Common Errors
- Keeping Schema Accurate: Maintenance and Common Mistakes
- How Proxiumdigital Implements and Maintains LocalBusiness Schema
- What Small Business Owners Should Actually Prioritize
- How Proxiumdigital Can Handle Schema and Local SEO for You
- Sources
- FAQ
What Schema for Local Business Actually Does vs. Google Business Profile
Schema markup and your Google Business Profile solve two different problems, and mixing them up is the most common mistake owners make. LocalBusiness schema is structured data added to your website’s code that makes your business identity readable to machines. It strengthens entity understanding and NAP consistency, but it doesn’t by itself place you in the local pack. Your Google Business Profile is the system that actually controls map-pack eligibility, proximity ranking, and review display.
Think of it this way: schema tells search engines “here is exactly who we are and where we’re located, unambiguously.” GBP tells Google “here is where we want to compete for local visibility, and here’s proof from real customers.” One feeds machine understanding. The other feeds ranking mechanics.
Where each one pulls weight:
- Schema helps with: entity clarity, knowledge panel accuracy, and how AI tools like ChatGPT or Perplexity describe your business when asked.
- GBP is authoritative for: map-pack placement, distance-based ranking, and the review carousel searchers see first.
- Both need to agree: if your site’s schema lists a different phone number or suite number than your GBP listing, you’re actively working against yourself.
Google’s own guidance notes there are more than 4,200 GBP categories to choose from, and picking one precise primary category plus two to four secondary ones matters more for local relevance than most owners realize. Your schema subtype should echo that same precision. If your GBP primary category is “Family Law Attorney,” your on-site schema should specify LawOffice, not a bare LocalBusiness tag.
Pro Tip: Set a recurring calendar reminder to audit your schema against your GBP listing every quarter. A mismatched suite number or an outdated phone number is invisible to you but glaring to a search engine trying to verify your identity.
Treat schema as insurance against machines getting your business wrong. It’s not persuasion. It’s confirmation.
Validate everything you build using Google’s Rich Results Test and keep an eye on Search Console’s structured data reports for warnings after you deploy.
Which Schema.org Subtype Fits Your Business?
Generic LocalBusiness is a fallback, not a strategy. Schema.org maintains dozens of subtypes precisely because a restaurant, a law firm, and a plumbing company need different vocabulary to describe what they do. A restaurant marked up with the Restaurant subtype unlocks properties like servesCuisine and menu that a generic listing simply can’t use. A dentist tagged as Dentist instead of LocalBusiness gives search engines a direct hook into medical and healthcare-specific search features.

The logic is simple: the more specific the type, the more properties become available, and the more precisely a search engine (or an AI answer engine) can describe what you actually sell.
| Business Scenario | Recommended Subtype | Why |
|---|---|---|
| Sit-down restaurant or cafe | Restaurant |
Unlocks servesCuisine, menu, and acceptsReservations |
| Law firm or solo attorney | LawOffice or Attorney |
Matches legal-specific search intent and disclosures |
| Accounting or consulting firm | ProfessionalService or AccountingService |
Signals advisory, non-retail service delivery |
| Plumber, electrician, HVAC tech | Plumber, Electrician, HVACBusiness |
Enables service-area and emergency-service properties |
| Dental or medical practice | Dentist, MedicalClinic |
Connects to health-specific schema vocabulary |
| Retail storefront | Store or a narrower subtype like ClothingStore |
Enables product and inventory-adjacent markup |
| Business with no public storefront | Organization + areaServed |
Avoids implying a street address that doesn’t exist |
If your business genuinely doesn’t fit any named subtype, generic LocalBusiness is an acceptable fallback rather than forcing a bad match. Service-area businesses, mobile detailers, traveling tutors, remote consultants, deserve special mention here. When there’s no public-facing address customers walk into, Organization paired with areaServed is usually more accurate than LocalBusiness with a street address nobody visits.
Pro Tip: Search “[your business type] site:schema.org” before you write a single line of code. Schema.org’s type hierarchy has more granular options than most SEO guides mention, and finding the exact match takes two minutes.
The Properties You Should Never Skip
A handful of properties do almost all the work in LocalBusiness schema, and skipping any of them weakens the entire block. The essentials are name, url, telephone, address (structured as a PostalAddress object, not a plain string), geo (latitude and longitude), and openingHoursSpecification. Miss the structured address format specifically, and you lose most of the practical benefit, because search engines can’t parse a loose string the way they can parse discrete fields.
Recommended additions once the core is solid: image, priceRange, areaServed for businesses that serve a radius rather than a single point, and sameAs to link your official social profiles and directory listings back to the same entity.
| Property | Purpose | Example / Formatting Note |
|---|---|---|
name |
Legal or trading name | Match your GBP listing exactly, including punctuation |
address |
Structured location | Use PostalAddress with separate streetAddress, addressLocality, addressRegion, postalCode, addressCountry |
telephone |
Primary contact number | Include country code: +1-313-555-0142 |
geo |
Map coordinates | GeoCoordinates with decimal latitude and longitude |
openingHoursSpecification |
Trading hours | Use full day names (Monday) and 24-hour time (08:00, 17:00) |
priceRange |
General cost signal | Simple symbols like $$ or a stated range |
areaServed |
Service radius or region | City, region name, or radius description for mobile businesses |
sameAs |
Cross-platform identity links | Array of URLs: Facebook, LinkedIn, Yelp, industry directories |
One property deserves a hard warning: don’t fabricate aggregateRating or review data. Only mark up reviews that are real and genuinely visible on the same page. Inventing star ratings to make your listing look more trustworthy is a fast route to a manual action, and it undermines the entire point of structured data, which is accuracy.
Pro Tip: If your phone number appears differently on three different pages of your own site (one with dashes, one with dots, one with parentheses), fix that before you touch schema. Internal inconsistency confuses search engines just as much as external mismatches with your GBP profile.
Step by Step: Writing and Deploying Your JSON-LD Block
Building your first LocalBusiness block is mechanical once you know the sequence. Skipping steps, especially validation, is how broken markup ends up live for months without anyone noticing.
- Draft the JSON-LD using the required properties above, starting from a template rather than writing from scratch. Include
@context,@type,@id,name,url,telephone,address,geo, andopeningHoursSpecification. - Choose a stable
@id. Use your canonical page URL, often with a fragment like#business, so other schema types on your site (Organization, BreadcrumbList, Service) can reference the same entity without creating duplicate, conflicting records. - Check the JSON syntax with a linter before deployment. A single missing comma breaks the entire block silently.
- Deploy the script in the
<head>or immediately before</body>, wrapped in<script type="application/ld+json">tags. - Test the live page with Google’s Rich Results Test to confirm the markup parses correctly and displays the intended fields.
- Monitor Search Console structured data reports weekly for the first month, then monthly after that, watching for new errors or warnings.
| Step | Tool to Use | What You’re Checking |
|---|---|---|
| Syntax check | Any JSON validator | No trailing commas, matched brackets |
| Rich preview | Google Rich Results Test | Markup is recognized and parsed |
| Ongoing monitoring | Google Search Console | New errors, warnings, coverage drops |
Before you deploy on a larger site, keep a backup of the prior HTML and roll out changes in stages, one location page first, rather than pushing new schema to fifty pages simultaneously.
The
@idfield is the part everyone skips and the part that causes the most confusion later. Without it, you end up with three different schema blocks all technically describing the same business, and search engines have no reliable way to know they’re the same entity.
Copy-Ready Examples for Common Business Setups
Most SMBs fall into one of four scenarios, and each needs a slightly different schema structure.

Single location, homepage markup. This is the simplest case: one JSON-LD block on your homepage with all core properties (name, url, telephone, address, geo, openingHoursSpecification). No special handling required beyond getting the fields right.
Multiple physical locations. The right pattern is one dedicated page per address, each carrying its own LocalBusiness block with its own @id, address, and phone number. Your homepage should carry an Organization schema that ties all locations together, often using sameAs or subOrganization to link them. Never combine five locations into a single JSON-LD block on one page. It fragments the entity signal instead of clarifying it.
Service-area business with no public address. Mobile pet groomers, traveling notaries, home cleaning services: these businesses should generally skip a street address entirely and use Organization with areaServed set to the cities, counties, or radius they cover. Listing a home address you don’t want customers visiting creates more problems than it solves.
Multiple departments at one location. A single building with a pharmacy, urgent care clinic, and lab shouldn’t carry three overlapping LocalBusiness blocks on one page. Create separate pages per department where practical, each with its own markup, or represent departments as a department property nested inside one parent LocalBusiness entity.
What actually changes between these templates: the phone number, address fields, geo coordinates, and whether areaServed replaces a street address. The property names and structure stay the same across all four.
Pro Tip: For multi-location businesses, name your @id values predictably (“https://yoursite.com/locations/detroit#business”, “https://yoursite.com/locations/ann-arbor#business”). It keeps your schema organized as you scale past three or four locations.
Testing Your Markup and Fixing Common Errors
Deploying schema without testing it is close to not deploying it at all, since broken JSON-LD often fails silently. Three tools cover almost every validation need: Google’s Rich Results Test shows you exactly how Google parses your live page and flags eligible rich results. Schema.org’s own validator checks raw syntax and property structure against the official vocabulary. Search Console’s structured data reports track errors and warnings across your entire site over time, which catches regressions after a site redesign or CMS update.
Common errors and how to fix them:
- Invalid JSON syntax (a missing comma or unclosed bracket) breaks the entire block. Run it through a linter before you ever deploy.
- NAP mismatch between schema and GBP (a different suite number or an old phone number) confuses entity matching. Copy the fields directly from your GBP listing rather than retyping them from memory.
- Malformed
openingHoursSpecification(using “Mon” instead of “Monday,” or 12-hour time instead of 24-hour) causes the property to be ignored or misread. - Multiple LocalBusiness blocks for one location on a single page dilutes rather than strengthens your entity signal. One block per location, always.
- Invented review or rating data risks a manual action and actively damages trust once discovered.
For staged rollouts, deploy to one page, wait a few days, check Search Console, then expand. A warning in Search Console usually means the markup works but is missing a recommended (not required) property. An error means the block failed to parse or is missing a required field, and that needs immediate attention.
Most schema problems aren’t dramatic. They’re small: a phone number typo, a “Mon” that should be “Monday,” a suite number that changed six months ago and never got updated everywhere.
Pro Tip: Bookmark your Search Console structured data report and check it the same day you make any change to your business hours, address, or phone number, not just on a routine schedule.
Keeping Schema Accurate: Maintenance and Common Mistakes
Schema markup isn’t a set-and-forget task. Update it the moment your hours, address, or contact details change, because stale schema actively misleads the systems reading it. A business that moved locations six months ago but never touched its JSON-LD is telling Google something false, quietly, on every page.
Best practices worth locking in:
- Pick one canonical NAP format (exact spacing, abbreviations, punctuation) and use it identically across your schema, your visible page content, and your GBP listing.
- Use a stable, predictable
@idfor every location so other schema types can reference it without duplication. - Default to the most specific schema.org subtype available rather than reaching for generic
LocalBusinessout of convenience. - Assign one person or team as the schema owner, so hour changes and address updates don’t fall through the cracks between departments.
Mistakes that actively backfire:
- Stale hours, especially around holidays, when a business shows “open” in schema but is actually closed. This creates a poor searcher experience and a credibility hit.
- NAP mismatches with GBP, the single most common and most damaging error, since it directly erodes entity confidence.
- Bulk-copying the same schema block across every page of a multi-location site instead of customizing each one.
- Inventing review or rating data that isn’t genuinely visible on the page.
- Multiple LocalBusiness blocks for a single physical location, which fragments rather than clarifies your entity signal.
Set a monthly audit: confirm hours match seasonal reality, confirm phone and address match GBP exactly, and spot-check that no duplicate LocalBusiness blocks crept in during a site update.
Pro Tip: Add a line to your website launch or update checklist that says “verify schema still matches GBP” right next to “check mobile responsiveness.” It takes thirty seconds and catches the mismatches that would otherwise sit unnoticed for months.
How Proxiumdigital Implements and Maintains LocalBusiness Schema
Fragmented services, one vendor builds the website, a different one handles SEO, are how most schema problems start in the first place. Proxiumdigital builds schema into the site from day one rather than bolting it on afterward, which is part of why the agency pairs custom web design with technical SEO under one workflow instead of splitting the work across separate vendors who rarely check each other’s output.
The process runs in five stages:
- Discovery. Collect the canonical NAP details and pull the exact category and listing data from the client’s Google Business Profile before writing a line of schema.
- Subtype selection. Match the business to the most specific schema.org type available rather than defaulting to generic LocalBusiness.
- Draft and deploy. Build the JSON-LD with a stable
@id, then push it live in stages, homepage first, then location pages, rather than all at once. - Validation. Run every deployed page through the Rich Results Test before calling the work complete.
- Monthly monitoring. Recheck GBP-to-site NAP alignment, review Search Console structured data reports, and update schema immediately when hours or addresses change, including seasonal adjustments.
Schema drift happens quietly. A phone number changes, a holiday schedule gets updated on Google Business Profile but never touches the website, and within a few months the two sources of truth disagree with each other in ways nobody notices until a customer calls the wrong number.
The monitoring checklist that keeps client schema accurate month over month includes scheduled GBP-versus-site NAP comparisons, Search Console error alerts, and a standing update protocol whenever a client changes hours, adds a location, or rebrands.
What Small Business Owners Should Actually Prioritize
If you’re running a five-person team and wearing six hats already, don’t try to do everything in this guide at once. Start with the homepage block, get your name, address, and phone matching your Google Business Profile exactly, and stop there for week one. That single fix delivers most of the practical benefit, and everything else is incremental improvement on top of it.
The decision of when to bring in outside help versus handling it yourself usually comes down to three factors: how many locations you’re managing, how comfortable you are editing raw code, and how much time you actually have to spend on quarterly audits. A single-location service business with basic HTML comfort can absolutely implement this without an agency. A ten-location franchise, or an owner who has never opened a <head> tag, is better served by an SEO agency that treats schema as part of ongoing site management rather than a one-time task.
Here’s your do-this-today list if you want quick wins before anything else:
- Verify your GBP listing’s name, address, and phone number are exactly right, including suite numbers and abbreviations.
- Add a basic LocalBusiness JSON-LD block to your homepage using the most specific subtype that fits your business.
- Run the page through the Rich Results Test and fix anything flagged as an error, not just a warning.
How Proxiumdigital Can Handle Schema and Local SEO for You
If DIY schema feels like one more thing competing for your attention against actually running the business, that’s the exact gap Proxiumdigital was built to close. Rather than treating structured data as an afterthought bolted onto a finished site, Proxiumdigital bakes schema, technical SEO, and site architecture together from the first build, so you’re not paying two vendors who never talk to each other and don’t catch each other’s mistakes.

The scope covers schema implementation for single and multi-location businesses, ongoing NAP monitoring against your Google Business Profile, monthly performance reporting, and the broader technical SEO and website management work that keeps structured data accurate as your hours, locations, or services change. For businesses in Michigan weighing the cost of doing this in-house against hiring it out, the pricing page breaks down what’s included at each service tier. If you’d rather have someone audit what’s already live on your site than start from scratch, request a consultation and get a clear read on what’s missing before you touch another line of code.
Sources
- Schema
- What Is Local Business Schema Markup? And How to Add It
- LocalBusiness Schema: Complete Guide (2026)
FAQ
What Is a Local Business Schema?
It’s JSON-LD structured data on your website that defines your business name, address, phone, and hours in a machine-readable format, which strengthens how search engines and AI tools understand your identity without directly controlling local-pack ranking.
How Do You Create a Local Business Schema?
Draft a JSON-LD block with the most specific schema.org subtype for your business, include name, url, telephone, a structured address, geo, and openingHoursSpecification, then deploy it in your site’s <head> and validate it with the Rich Results Test.
What Are the Four Types of Schema?
Schema.org offers hundreds of types, not just four, but common local business categories include LocalBusiness subtypes like Restaurant, ProfessionalService, Store, and HealthAndBeautyBusiness, each unlocking different type-specific properties.
How Do I Improve Local SEO Beyond Schema?
Schema strengthens entity clarity, but local SEO also depends on an accurate, fully optimized Google Business Profile, consistent NAP across directories, and ongoing technical SEO. Proxiumdigital handles all three together rather than treating schema as an isolated task.
Does Adding Schema Guarantee a Local Pack Ranking?
No. LocalBusiness schema strengthens entity understanding and NAP consistency, but Google Business Profile signals, proximity, and reviews remain the primary drivers of local-pack placement.