A production-ready LocalBusiness schema template with implementation guidance. Covers the mandatory and optional properties that signal relevance to Google, correct nesting for locations and service areas, and how to validate and deploy structured data without introducing crawl errors or misleading signals.
Google uses LocalBusiness schema to populate the Knowledge Panel, Local Pack results, and business details in Maps. The minimum viable markup includes @type (usually a subtype like Restaurant or Plumber), name, address (PostalAddress object), telephone, and url. Without these five, Google often ignores the structured data entirely.
Beyond the baseline, priceRange (represented as dollar signs: $, $$, $$$, $$$$) signals category positioning. The geo property (latitude and longitude) can reinforce map placement, especially when the address is ambiguous or rural. The openingHoursSpecification array is critical for the hours panel and for showing whether you're open now in search snippets.
Many templates circulating online include deprecated properties like @id using arbitrary URIs or redundant contactPoint blocks. Strip these out. Google's documentation is clear about which properties it actually consumes. Focus on the dozen that influence display and ranking rather than bloating the JSON with unused keys.
LocalBusiness is the parent type. You should almost never use it directly. Google recognizes dozens of subtypes: Restaurant, LegalService, MedicalBusiness, HomeAndConstructionBusiness, and many more. Each subtype inherits LocalBusiness properties but can also accept type-specific fields.
For example, Restaurant accepts servesCuisine and menu. LegalService has no extra required properties but signals relevance for legal queries. MedicalBusiness and its children (Dentist, Physician) can include priceRange and accept review aggregates differently in some verticals.
If your category doesn't have an obvious subtype, step down to the nearest parent. An interior design studio might use ProfessionalService. A coworking space can use LocalBusiness if no closer subtype fits, but avoid stretching the definition. Mismatched types can suppress features or trigger manual review flags in Google My Business.
Businesses that travel to customers — plumbers, mobile mechanics, home cleaners — face a schema decision. If you have a public storefront where customers can visit, use address and list your service zones in areaServed as an array of strings (city names, postal codes, or GeoShape polygons). If you operate from a non-public location and only visit clients, omit address entirely and rely solely on areaServed.
Google explicitly states that including a fake or non-public address when you're actually a service-area business can result in suspension from the Local Pack. The areaServed property accepts text (city names), PostalCode objects, or GeoCircle/GeoShape for precise boundary definition. Most templates use simple city strings because they're easier to maintain and Google parses them reliably.
Do not list every postal code in a metro area individually. A handful of city names or a GeoCircle with a radius in kilometers is cleaner and avoids the appearance of keyword stuffing in structured data.
LocalBusiness schema supports an aggregateRating property (ratingValue, bestRating, ratingCount) and a nested review array. Google displays star snippets in organic results if the markup is valid and the reviews are genuine first-party content or syndicated from a trusted platform.
You cannot fabricate ratings or copy reviews from Google My Business into your schema without republishing them on your own site. Each review object requires author, datePublished, and reviewRating. If you run your own review system, this is straightforward. If you rely solely on GMB, Yelp, or Facebook, you should omit the review markup and let Google pull from those sources naturally.
Some businesses inflate ratingCount or use a suspiciously perfect 5.0 average. Google's quality raters and algorithmic checks flag outliers. Stick to actual data. If you have twelve reviews averaging 4.6, mark it up exactly that way. The integrity of the schema matters more than the optics of a perfect score.
Before you publish schema, run the JSON through Google's Rich Results Test and Schema.org's validator. The Rich Results Test shows which features are eligible (logo, knowledge panel, sitelinks search box). The Schema.org validator catches syntax errors and missing required properties.
Common mistakes include trailing commas in JSON (breaks parsing in some contexts), mismatched quote types (curly quotes from word processors), and incorrect nesting of the address object. The address property must be a PostalAddress type with streetAddress, addressLocality, addressRegion, postalCode, and addressCountry. Flattening these into the LocalBusiness root breaks validation.
Deploy JSON-LD in the head or immediately after the opening body tag. Avoid inserting it mid-page or inside conditional blocks that fire only for certain users. Google's crawler needs to see the same markup as a logged-out visitor. After deployment, request indexing via Search Console and monitor the Enhancements report for structured data errors.
Multi-location businesses face a choice: one schema block listing all locations as an array, or separate pages with location-specific JSON-LD. Google prefers the latter. Each location page should have its own LocalBusiness block with unique address, telephone, geo, and openingHours.
If you operate a franchise, each franchisee is a distinct legal entity and should have separate schema. The parentOrganization property can link back to the franchisor's Organization schema, but the local address and contact details must be unique.
Do not use a single phone number or URL across all locations. Google cross-references schema with NAP data in Google My Business, citation sources, and on-page content. Inconsistencies suppress rich results or trigger duplicate-listing flags. Automate schema generation through your CMS or location-data platform, but validate a sample from each region to catch template errors.
LocalBusiness is a subtype of Organization and includes location-specific properties like address, geo coordinates, and opening hours. Use LocalBusiness when you operate a physical location customers can visit or when you serve a defined geographic area. Use the generic Organization type for entities without a public location, like pure SaaS companies or holding companies.
You can use the same template structure, but you must populate unique data for each location: address, telephone, URL, geo coordinates, and opening hours. Google flags duplicate schema across URLs as low-quality or manipulative. Automate population from a central database, but ensure each page's JSON-LD reflects that specific location's real-world details.
It is optional but recommended, especially if your address is ambiguous, rural, or newly established. The geo property helps Google pin your business on Maps and can improve local ranking when the address string alone is insufficient. Use the exact coordinates from Google Maps rather than approximate values from a geocoding API.
Include the address if customers visit your location, and note appointment-only status in the openingHoursSpecification using validFrom and validThrough for each time slot, or describe it in the description property. If you never allow walk-ins and operate from a non-public office, consider using areaServed instead of address, depending on whether the location is discoverable to customers.
Yes, use the sameAs property as an array of URLs pointing to your official Facebook, LinkedIn, Instagram, and Twitter profiles. Google uses these to verify entity identity and can surface social links in the Knowledge Panel. Only include profiles you control and keep active; dead or impersonated accounts hurt trust signals.
Google typically ignores malformed or incomplete schema rather than penalizing the page. You lose eligibility for rich results and Knowledge Panel enhancements, but organic rankings are not directly affected. Check the Enhancements report in Search Console for warnings and errors, fix them, then request re-indexing. Errors often stem from missing required properties or syntax issues in the JSON.