Most tutorials on schema LocalBusiness open with an optimistic premise: add a few fields to your HTML and Google will reward you with a Knowledge Panel. The reality is considerably more nuanced. According to Semrush data from 2025, 67% of websites with LocalBusiness schema implemented have it with validation errors or incomplete properties that nullify much of its potential. The tool isn’t broken — it’s just implemented incorrectly at a frequency that’s genuinely surprising.
Schema LocalBusiness is, in essence, a standardized vocabulary that tells search engines exactly what you are, where you are, when you’re open, and what you do — all in a format a machine can process without ambiguity. When Google crawls your page and finds that JSON-LD block, it doesn’t have to infer whether your phone number is for the main office or a branch, or whether Saturday hours differ from the rest of the week. The data is there, structured, verifiable.
The difference between a mediocre schema and a complete one is measurable in concrete figures. Pages with complete LocalBusiness schema are 30% more likely to appear in Google’s Knowledge Panel, according to BrightLocal research published in 2025. And businesses that combine robust schema with a well-optimized Google Business Profile don’t just compete better in the Local Pack — they also improve their visibility with generative AI engines that use structured data as a trust signal when building responses.
This guide won’t give you code to copy and paste without understanding. It will explain why each property exists, what happens when you omit it, and how to verify your implementation actually works. If you already have LocalBusiness schema, you’ll likely find at least three things you’re doing suboptimally. If you don’t have it yet, you’ll have a clear roadmap for implementing it correctly from the start.
What Schema LocalBusiness Is and Why It Matters Now
Schema.org is a collaborative vocabulary created in 2011 by Google, Microsoft, Yahoo, and Yandex with a very specific purpose: providing a common language to describe entities on the web in a machine-processable way. Within that vocabulary, LocalBusiness is the type designed to describe businesses with a physical presence: a barbershop in Brooklyn, a law firm in Chicago, a restaurant in Austin.
What distinguishes LocalBusiness from other schema types is its emphasis on geospatial and hours data. While an Article schema is concerned with authorship and publication date, LocalBusiness needs to know exactly where the business is located (down to latitude and longitude), when it serves the public, and how to contact it. That geographic specificity is what makes it the central technical piece of local SEO.
The timing of this implementation matters more than it might appear. In the current search ecosystem, Google doesn’t act alone. Generative AI engines like ChatGPT Search, Perplexity, and Google Gemini are increasingly responding to local queries: “best dentist in the Upper East Side,” “auto repair shops open Sunday in Denver.” These models extract information from multiple sources, and structured data is, literally, what they process most efficiently. A business with well-constructed LocalBusiness schema is already speaking the language these engines understand.
The technical process works like this: when Googlebot crawls your page and finds a LocalBusiness JSON-LD block, it extracts it, validates it against schema.org specifications, and adds it to its knowledge graph. That knowledge graph is the source that feeds the Knowledge Panel, the Local Pack, and increasingly, AI Overviews responses. The coherence between your schema, your Google Business Profile, and your website’s visible content reinforces all these signals simultaneously.
One detail that often surprises SEO professionals who know the topic superficially: Google automatically extracts data from LocalBusiness schema to complete and verify Google Business Profile information. That means if your GBP hours differ from your schema, Google has to decide which to believe. If they match, the trust signal is amplified.
JSON-LD Format: The Only Option That Makes Sense
Schema.org can be implemented in three formats: JSON-LD, Microdata, and RDFa. In theory, all three are equivalent in terms of expressive capacity. In practice, JSON-LD has won the battle, and Google has stopped being ambiguous about it: their official documentation explicitly recommends JSON-LD as the preferred format.
Why JSON-LD over Microdata? Because JSON-LD is an independent code block that lives in the <head> of the page, completely separate from the visible HTML. You can update structured data without touching the design. You can add complex properties with nested objects without turning the HTML markup into a labyrinth. And you can validate it in isolation with automated tools.
The basic structure of a JSON-LD LocalBusiness always has three indispensable elements:
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Your Business Name"
}That’s the technically valid minimum. It’s also the useless minimum. A schema with only those three fields tells Google nothing it couldn’t infer from the page title. The real value starts when you add the properties that search engines can’t deduce on their own.
Complex nesting is one of JSON-LD’s capabilities that Microdata handles clumsily. For example, to specify different hours for each day of the week with openingHoursSpecification, you need an array of objects with @type: OpeningHoursSpecification. In Microdata, that requires nested HTML markup that complicates maintenance. In JSON-LD, it’s a clean array in the script tag, invisible to the user, completely structured for the machine.
Required vs. Recommended Properties: Where the Value Lives
Google classifies LocalBusiness schema properties into two categories according to its official documentation: required and recommended. The distinction matters because required properties are necessary for the schema to be eligible for rich results, while recommended properties are what distinguish a functional schema from one that truly drives visibility.
Google’s required properties for LocalBusiness are three: @type, name, and address. Without these, the validator returns critical errors. The address, in turn, must follow the PostalAddress type with the appropriate subfields.
But where the real potential lies is in the recommended properties. There’s no need to choose — implement all that apply to your business.
telephone — Always in international format with country code. For US businesses, +1 555-234-5678, never 555-234-5678 or (555) 234-5678. Search engines and automated phone dialing systems need the E.164 format.
openingHoursSpecification — This is one of the most frequently poorly implemented properties. The openingHours property (singular) accepts simplified strings like "Mo-Fr 09:00-18:00", but openingHoursSpecification lets you define special hours for holidays or specific days with nested objects. If your business has summer hours, closes on state holidays, or has reduced hours on Saturdays, the detailed specification gives you full control that the simplified version can’t express.
geo — Latitude and longitude of the business. This seems redundant if you already have the address, but it isn’t. The address is text that Google has to geocode (convert to coordinates). Direct coordinates eliminate that intermediate step and reduce the possibility of geocoding errors — especially for businesses in industrial parks, shopping centers, or buildings with multiple entrances. Use the coordinates of the same point shown in Google Maps, not auto-calculated building center coordinates.
priceRange — One to four $ signs to indicate the price range. Simple but effective for responses to queries with price filters (“cheap restaurants near me”).
url — Absolute URL of the business’s main page. Not just the domain — the full URL with https://.
image — URL of a representative image. Use a quality image showing the business, the team, or the main product.
aggregateRating — If you have your own rating system on your website, you can include the average rating and number of ratings. Don’t confuse this with Google Maps ratings (which Google manages directly) and never fabricate data here — Google verifies consistency.
The 100+ Subtypes of LocalBusiness: Choose the Right One
One of the most underused capabilities of LocalBusiness schema is its hierarchy of subtypes. Schema.org doesn’t define a single generic type for all businesses — it defines more than 100 specializations, from Restaurant to DentalClinic, including AutoRepair, LegalService, Hotel, Pharmacy, RealEstateAgent, and dozens more.
This distinction isn’t cosmetic. When Google knows your business is of type Dentist (a subtype of MedicalBusiness, which is in turn a subtype of LocalBusiness), it can associate it with specific queries in the dental sector, apply the sector-specific evaluation criteria for healthcare (including reinforced E-E-A-T for YMYL content), and potentially show it in rich snippets specific to medical professionals.
Using generic LocalBusiness when you should be using Restaurant is like filing your business under the wrong industry category: technically valid, but with consequences for how the system categorizes you.
The hierarchy works like this: you can use multiple @type values simultaneously to capture multiple classifications. A Japanese restaurant in Seattle might define:
{
"@context": "https://schema.org",
"@type": ["Restaurant", "FoodEstablishment"],
"servesCuisine": "Japanese",
"name": "Your Restaurant Name"
}Relevant subtypes for common sectors in English-speaking markets:
- Hospitality and food service:
Restaurant,Bar,Bakery,CafeOrCoffeeShop,Hotel,BedAndBreakfast - Healthcare:
Dentist,Optician,Pharmacy,Physiotherapist,VeterinaryCare - Professional services:
LegalService,AccountingService,FinancialService,InsuranceAgency - Automotive:
AutoRepair,AutoDealer,CarWash - Retail:
ClothingStore,ElectronicsStore,HomeGoodsStore,BookStore - Beauty and personal care:
BeautySalon,HairSalon,SpaOrHealthClub,NailSalon
Consult the complete hierarchy at schema.org/LocalBusiness to find the most specific type that describes your business. The more precise the type, the more relevant the schema for sector-specific queries.
Step-by-Step Implementation: The Complete JSON-LD
Theory aside, here’s how everything translates into concrete code. The following example corresponds to a law firm in Chicago, a case that illustrates the most complex properties well:
{
"@context": "https://schema.org",
"@type": "LegalService",
"name": "Miller & Associates Law Firm",
"url": "https://www.millerassociateslaw.com/",
"telephone": "+1 312-555-0178",
"email": "[email protected]",
"image": "https://www.millerassociateslaw.com/images/office-exterior.jpg",
"description": "Chicago law firm specializing in corporate and employment law, with over 20 years of experience representing 600+ business clients.",
"priceRange": "$$$",
"address": {
"@type": "PostalAddress",
"streetAddress": "233 S Wacker Drive, Suite 4500",
"addressLocality": "Chicago",
"addressRegion": "IL",
"postalCode": "60606",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 41.8788,
"longitude": -87.6359
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
"opens": "09:00",
"closes": "18:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Friday",
"opens": "09:00",
"closes": "15:00"
}
],
"areaServed": {
"@type": "State",
"name": "Illinois"
},
"sameAs": [
"https://www.linkedin.com/company/miller-associates-law",
"https://goo.gl/maps/example"
],
"hasMap": "https://goo.gl/maps/example",
"currenciesAccepted": "USD",
"paymentAccepted": "Cash, Credit Card, Bank Transfer"
}A few notes on this example. The areaServed property is especially valuable for service businesses that serve clients beyond their physical location (a law firm doesn’t only serve clients who walk through the door). The sameAs property links the schema to verifiable profiles on other platforms, reinforcing authority signals. And hasMap connects directly to the Google Maps listing, facilitating data correlation.
For businesses with multiple locations, each branch page needs its own independent JSON-LD block. Don’t use the same schema with a duplicated @id across all pages — that’s one of the errors Google detects and that erodes trust in your domain’s schema as a whole.
Common Errors That Invalidate Schema
The gap between implementing schema and implementing it well is where most of the value is lost. These are the most frequent errors I encounter when auditing local business websites:
- Hours in incorrect format:
openingHours: "Mon-Fri 9am-6pm"isn’t valid. Google requires days in English and 24-hour format:"Mo-Fr 09:00-18:00". It seems like a minor detail, but the validator flags it as an error and the data gets discarded. - Phone without international prefix:
"555-234-5678"creates ambiguity in automated processing. Always use"+1 555-234-5678". - Coordinates pointing to city centre instead of the business: Many automatic schema generators insert city centre coordinates if they can’t find the specific business location. If your
geopoints to downtown Chicago but your business is in Lincoln Park, the geospatial signal is incorrect. - Schema that doesn’t match GBP data: If your schema says you’re open Sundays but your Google Business Profile shows you’re closed, Google has to decide which to believe. This inconsistency reduces trust in both sources. Schema and GBP must always be identical for contact data and hours.
- Relative URL instead of absolute:
"url": "/contact"is invalid. Always use"url": "https://www.yourdomain.com/contact/". - Generic type when a specific one exists: Using
"@type": "LocalBusiness"for a dental practice when"Dentist"exists and provides more semantic context. - Not updating schema after changes: A business that changes its summer hours but doesn’t update the JSON-LD will be sending incorrect data for months. Integrate schema review into any business data change process.
Validation Tools and Testing
Before declaring an implementation complete, you need to validate it with tools that don’t make mistakes. Google offers two: the Rich Results Test and the Schema Markup Validator. They’re complementary, not interchangeable.
The Rich Results Test (search.google.com/test/rich-results) evaluates whether your schema is eligible for specific types of rich results in Google Search. For LocalBusiness, it tells you whether the schema is correctly implemented to potentially enhance the Knowledge Panel and local results. It shows critical errors (that prevent eligibility) and warnings (that reduce potential but don’t nullify it).
The Schema Markup Validator (validator.schema.org) validates JSON-LD syntax against the formal schema.org specifications, independent of whether Google uses it for rich results. It’s useful for detecting typos, unknown properties, or incorrect nesting structures.
The Merkle tool (technicalseo.com/tools/schema-markup-generator/) is helpful for generating initial JSON-LD if you’re starting from scratch. It guides you through a form and produces the code, though you’ll need to review the output because automatic generators frequently make errors with complex properties like openingHoursSpecification.
For bulk validation on sites with multiple location pages, tools like Screaming Frog can crawl the site and extract all structured data blocks for analysis in aggregate.
One additional verification that often gets skipped: after publishing the schema, access Google Search Console and review the “Enhancements” report in the “Page Experience” section. Google takes anywhere from a few hours to several days to process new schema, but the report will show any active errors or warnings on indexed pages.
Schema LocalBusiness and Generative AI Engines
The impact of LocalBusiness schema is no longer limited to Google’s traditional search ecosystem. Generative AI engines that answer queries about local businesses use structured data as a trust signal when building responses.
When ChatGPT Search or Perplexity crawls a webpage looking for information about a local business, JSON-LD processing is more efficient than plain text analysis. A LocalBusiness schema block with name, address, phone, hours, and coordinates tells the model exactly what it needs to know without ambiguity. The page’s text might be ambiguous (“we’re open weekdays” without specifying hours); the schema isn’t.
According to BrightLocal data from 2025, businesses with complete LocalBusiness schema receive 20% more clicks in local organic results, and that effect is amplified in the context of AI responses, where the source with the most structured and verifiable data has a competitive advantage in being selected for the answer.
There’s a LocalBusiness schema property that takes on special significance for AI engines: areaServed. This property lets you define the geographic area the business serves, whether as a city, region, country, or a geographic radius with GeoCircle. For LLMs responding to queries like “plumbing services throughout the greater Boston area,” a business with correctly defined areaServed has an explicit signal these models can process directly.
The makesOffer and hasOfferCatalog properties allow structuring the business’s services or products in a machine-processable format. A restaurant that defines its dishes with Offer and MenuItem is giving AI engines the ingredients to answer very specific queries about its menu. A Semrush study from 2025 identified that businesses with detailed service schema had 35% more mentions in AI Overviews responses for niche queries compared to businesses with basic schema.
Schema Maintenance and Lifecycle
A LocalBusiness schema implementation isn’t a one-time task. It’s a living data layer that must remain synchronized with the reality of the business.
Events requiring immediate schema updates include: schedule changes (including seasonal hours or holidays), change of address or phone number, opening or closing of branches, business name change, and modification of the service range. Every time you update your Google Business Profile, check whether the corresponding schema needs the same update.
A recommended practice for marketing teams or agencies managing multiple clients: create a tracking spreadsheet with all LocalBusiness schema fields, current values, and last verification date. Reviewing this spreadsheet quarterly takes fewer than 30 minutes per client and prevents inconsistencies from accumulating and eroding search engine trust.
For sites built with CMS platforms like WordPress, SEO plugins like Yoast or RankMath manage LocalBusiness schema from the admin panel. The advantage is ease of updating; the risk is that these plugins generate generic schema that may not include all the properties you need. Always verify the output with the Rich Results Test, regardless of which plugin you use.
For more technical projects — sites built with Astro or other modern frameworks — creating a dedicated component that dynamically generates JSON-LD from a single data source (a configuration file or environment variables) is the most robust approach. You change data in one place and the schema updates automatically across all relevant pages.
LocalBusiness schema is one of those technical elements with measurable return, conditional on the implementation being complete and maintained. A partial or outdated schema isn’t neutral: it can generate inconsistencies that Google and AI engines interpret as low-reliability signals. Implemented correctly, it’s one of the technical investments with the best effort-to-impact ratio in local SEO.
To go deeper into the complete local positioning strategy, the local SEO guide covers the strategic context where this schema fits alongside all other ranking factors.