LocalBusiness Schema: A Complete Property Guide

What it is and how it works

LocalBusiness is a type in the Schema.org vocabulary that describes an organization with a physical presence customers can visit or contact. You publish it as JSON-LD in the page source, usually on your home page or a dedicated location page. Crawlers parse that block, extract the structured facts, and use them to build a confident understanding of your business as an entity.

The value is precision. Instead of inferring your phone number from visible text or guessing your hours from a styled table, search engines and AI assistants read named properties with unambiguous values. That clarity feeds Google's Knowledge Graph and the entity layer that modern answer engines rely on. If you want the broader context on why machine-readable facts matter, see our overview of machine-readable web standards.

Choosing the right subtype

LocalBusiness has many subtypes, and using the most specific accurate one improves clarity. A restaurant should use Restaurant, a shop should use Store, a dentist should use Dentist, and so on through LegalService, AutomotiveBusiness, HealthAndBeautyBusiness, and dozens more. When no specific subtype fits, fall back to LocalBusiness itself.

Pick the subtype that genuinely describes the business. A more specific type can unlock type-relevant properties (a restaurant gains servesCuisine and menu, for example) and gives engines a sharper entity match. Do not stack multiple unrelated types hoping for more coverage. One accurate type beats three approximate ones.

The SEO and visibility angle

Here is the honest version. LocalBusiness schema is a clarity and trust signal, not a ranking shortcut. It helps Google associate your website with the correct real-world entity, reinforces NAP (name, address, phone) consistency across the web, and can support what appears in a knowledge panel. Those are real benefits for entity understanding and for how AI search engines summarize your business.

What it does not do is generate the local pack, the map-based three-result block, by itself. Local pack and Maps rankings are driven primarily by your Google Business Profile, physical proximity to the searcher, review signals, and prominence. Your GBP is the source of truth there, not your markup. The right mental model: schema and GBP should agree perfectly, and schema reinforces the identity that GBP establishes. Anyone promising a local pack jump from markup alone is selling the wrong story.

Use cases: who benefits most vs least

Most: Single-location and multi-location businesses with a real address and service hours, where each location has its own page. Brands that show up in knowledge panels, and any business that wants AI assistants to quote correct hours and contact details, gain the most clarity.

Least: Pure online businesses with no physical presence or defined service area (those usually belong under Organization), and pages that duplicate the same markup across every URL without per-location accuracy. If the facts are not stable and true, the markup adds noise rather than signal.

Implementation

Below is a complete, valid JSON-LD example for a single location. Use one block per physical location, keep every value identical to what appears on the page and in your GBP, and use a stable @id so other markup (like breadcrumbs or articles) can reference the same entity.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.com/#restaurant",
  "name": "Harbor Lane Kitchen",
  "url": "https://example.com/",
  "telephone": "+1-503-555-0188",
  "priceRange": "$$",
  "servesCuisine": "Seafood",
  "image": "https://example.com/images/storefront.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "412 Harbor Lane",
    "addressLocality": "Portland",
    "addressRegion": "OR",
    "postalCode": "97204",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 45.5202,
    "longitude": -122.6742
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Tuesday", "Wednesday", "Thursday"],
      "opens": "11:30",
      "closes": "21:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Friday", "Saturday"],
      "opens": "11:30",
      "closes": "22:30"
    }
  ],
  "areaServed": {
    "@type": "City",
    "name": "Portland"
  },
  "sameAs": [
    "https://www.facebook.com/harborlanekitchen",
    "https://www.instagram.com/harborlanekitchen"
  ]
}
</script>

Note the key properties at work: name, url, and telephone for core identity; address wrapped in PostalAddress for a structured location; geo with GeoCoordinates for precise mapping; openingHoursSpecification for machine-readable hours; priceRange for tier context; areaServed for coverage; and sameAs to link your authoritative profiles and strengthen the entity. For related patterns, see our guides to Article schema and Breadcrumb schema, which can share the same @id graph.

How to validate

Run the markup through Google's Rich Results Test to confirm it is detected and eligible, and through the Schema.org Validator for vocabulary correctness. After deployment, watch Google Search Console for structured data and enhancement reports that flag errors on live pages. Validate with the same address and phone formatting you use everywhere else, then spot-check that the rendered JSON-LD matches the visible page content.

Common mistakes

• NAP mismatch with GBP. The name, address, or phone in your schema differs from your Google Business Profile or citations. Mismatches erode the entity confidence the markup is supposed to build. Pick one canonical format and use it everywhere.
• Wrong or overly generic subtype. Tagging a dental clinic as plain LocalBusiness, or worse, as an unrelated type, throws away the precision that a specific subtype provides.
• Fake or self-serving review markup. Adding aggregateRating or review that is invented, scraped, or not genuinely collected and displayed on the page violates Google's policies and can trigger manual action. Only mark up reviews that are real and visible on the same page.
• Duplicated markup across locations. Reusing one location's block on every page instead of giving each location accurate, distinct data.
• Markup that contradicts the page. Hours or phone in the JSON-LD that do not match what visitors see. The structured facts must mirror the visible content.

FAQ