LocalBusiness Schema, Explained Property by Property

Your website tells humans what you do. Schema markup tells machines. And in 2026 the machines are the gatekeepers: Google's local pack, AI Overviews, ChatGPT, Perplexity, and voice assistants all decide whether to recommend you based on structured facts they can verify, not on how nice your homepage looks. Local business schema is the block of JSON-LD code that publishes those facts in the vocabulary the machines were built to read.

This guide covers the whole discipline for a business owner or the person they delegate it to: what the markup is, which subtype to pick, every property worth including, a complete example you can copy and adapt, the errors that quietly break everything, and why this feeds systems far bigger than one search snippet. In FD's methodology this work is Vector 6: Structure, the schema layer of the service stack.

What local business schema actually is

Local business schema is structured data written against the Schema.org vocabulary, usually as JSON-LD inside a <script type="application/ld+json"> tag in your page's head. The LocalBusiness type is defined by Schema.org as a physical business or branch of an organization, and it inherits from both Organization and Place. That dual inheritance is the point: a local business is simultaneously a company (with a legal name, logo, and phone number) and a location (with an address, coordinates, and opening hours), and the markup lets you state both halves in one object.

Google's own documentation confirms what this buys you: LocalBusiness structured data makes your business eligible for the knowledge panel treatment, feeds hours and location details into search features, and helps Google match your website to your Google Business Profile. The markup does not rank you by itself. It removes ambiguity, and ambiguity is what keeps good businesses out of local results.

One distinction worth fixing early: your Google Business Profile is a listing you maintain inside Google's walled garden. Schema markup is a public statement on your own property that every crawler can read, including the AI engines Google does not control. You want both, and you want them to agree. That agreement is the core of what FD calls entity validation on local SEO engagements.

Pick the most specific subtype, not plain LocalBusiness

Schema.org defines well over a hundred subtypes under LocalBusiness, and using the most specific one that fits is the cheapest accuracy win in structured data. Declaring a dental clinic as Dentist rather than generic LocalBusiness is the markup equivalent of choosing the right category on Google Maps: the engine no longer has to guess your industry from your page copy.

Two practical rules. First, if no subtype fits, plain LocalBusiness is fine; never force a wrong subtype for the sake of specificity. Second, a business that is genuinely two things can declare both with an array, for example "@type": ["Bakery", "CafeOrCoffeeShop"]. The full subtype tree lives on Schema.org, and the structured data cheatsheet in our research library lists the ones Ontario service businesses reach for most.

The properties that matter, and how to fill each one

Schema.org permits hundreds of properties. In practice a short list does nearly all the work, and Google's local business documentation names name and address as the required core. Here is the working set, in rough order of importance.

Notice what is not on the list: keyword-stuffed descriptions, dozens of service pages jammed into one object, and review stars. Restraint reads as trustworthy to a parser. Bloat reads as manipulation.

The aggregateRating rule most guides get wrong

Owners ask for review stars more than any other rich result, so be clear about the constraint. Since 2019, Google has excluded what it calls self-serving reviews from review snippets: ratings a business publishes about itself, on its own site, using LocalBusiness or Organization markup, do not earn stars in Google results. That includes ratings piped in from a third-party widget you embedded. Google's review snippet documentation spells this out, and BrightLocal's testing confirms the stars simply do not render for those types.

So should you include aggregateRating at all? Our position: yes, when the rating is real, sourced from a named platform, and displayed visibly on the same page. Google will not show stars, but Google is not the only reader anymore; AI engines ingest the field as an entity fact. What you must never do is mark up a rating that appears nowhere on the visible page, invent a review count, or inflate the score. Schema that contradicts the visible page is the fastest way to lose Google's trust in all your markup, not just the one field.

A complete, valid example you can copy

The block below is a full LocalBusiness JSON-LD object for a fictional Brantford plumbing company, used here purely to illustrate the shape. Swap every value for your own, then validate before publishing. It goes inside <script type="application/ld+json"> tags in your page head; our companion guide on how to add schema markup walks through the placement step by step for WordPress, Shopify, and static sites.

{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "@id": "https://www.examplebrantfordplumbing.ca/#business",
  "name": "Example Brantford Plumbing",
  "url": "https://www.examplebrantfordplumbing.ca/",
  "image": "https://www.examplebrantfordplumbing.ca/images/storefront.jpg",
  "logo": "https://www.examplebrantfordplumbing.ca/images/logo.png",
  "telephone": "+15195550142",
  "email": "office@examplebrantfordplumbing.ca",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Colborne Street",
    "addressLocality": "Brantford",
    "addressRegion": "ON",
    "postalCode": "N3T 2G8",
    "addressCountry": "CA"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 43.13894,
    "longitude": -80.26636
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "17:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "09:00",
      "closes": "13:00"
    }
  ],
  "areaServed": [
    { "@type": "City", "name": "Brantford" },
    { "@type": "City", "name": "Paris" },
    { "@type": "City", "name": "Cambridge" }
  ],
  "sameAs": [
    "https://www.facebook.com/examplebrantfordplumbing",
    "https://maps.google.com/?cid=1234567890"
  ]
}

If hand-editing JSON is not your idea of a good Tuesday, our no-charge schema generator builds this block from a form and picks the right subtype for you.

The errors that quietly break your markup

In Matt's audits of Ontario service businesses, the recurring finding is not missing schema; it is schema that damages trust because it disagrees with something. The pattern he sees most: a site launched with correct markup, then the business moved, changed phone numbers, or rebranded, and nobody updated the code. The schema kept broadcasting a stale address for years while the Google Business Profile said something else, and the two signals cancelled each other out.

How LocalBusiness markup feeds the Knowledge Graph and AI engines

Here is the part most schema tutorials skip, and it is the reason the work pays off beyond one rich snippet. Search engines and AI assistants do not store the web as pages; they store it as entities and relationships. Hogan and colleagues, in their 2021 survey of knowledge graphs (arXiv:2003.02320), describe a knowledge graph as a graph of data whose nodes represent real-world entities and whose edges represent the relations between them, and they trace how Google's 2012 Knowledge Graph announcement pushed the model into mainstream industry use at Google, Bing, Amazon, LinkedIn, and beyond.

Two findings from that survey matter directly to a business owner. First, the authors emphasise that knowledge graphs are assembled from many diverse sources, which makes identity a central problem: the system must work out which mentions across the web refer to the same real-world thing. Your LocalBusiness markup, with its stable @id, exact NAP, and sameAs links to your other profiles, is precisely the identity evidence that resolution process consumes. Second, they note that schema plays the structural role, defining how the accumulated facts fit together; Schema.org is the shared vocabulary that lets your little block of JSON slot into a graph holding billions of entities.

The AI layer sits on top of the same substrate. When someone asks ChatGPT or an AI Overview for "a plumber in Brantford that does weekend calls," the engine is retrieving entity facts: category, service area, hours. A business whose facts exist in structured, corroborated form is a low-risk answer for the machine to give. A business whose facts must be inferred from prose is a hallucination waiting to happen. This is what we mean by Digital Fingerprints: the machine-verifiable evidence that you exist, do what you say, and are where you claim to be.

Service-area businesses: schema without a storefront

Plumbers, electricians, mobile groomers, and anyone who drives to the customer face a specific problem: local relevance without walk-in premises. The markup answer has three parts. Keep the address property pointing at your real base of operations, even if it is a home office you hide on Google Maps; engines still need a grounding location. Carry the local weight with areaServed, listing the actual cities and regions you cover as typed City or AdministrativeArea objects rather than a comma string. And resist inflating the list: claiming forty municipalities you have never invoiced dilutes the signal for the ten you genuinely serve, and it will not survive cross-checking against your reviews and citations.

Multi-location businesses invert the pattern: one Organization entity for the brand, plus a separate LocalBusiness block on each location's own page, each with its own @id, address, geo, and hours, all pointing back to the parent via parentOrganization. One block trying to describe five locations describes none of them.

Validate before you publish, then re-validate on a schedule

Three checks, in order. First, syntax: paste the JSON into any JSON validator or the Schema.org validator at validator.schema.org, which confirms the markup parses and the properties exist in the vocabulary. Second, eligibility: run the live URL through Google's Rich Results Test, which applies Google's stricter rules on top of the vocabulary and previews what rich features the page qualifies for. Markup can pass the first test and fail the second; both are necessary. Third, monitoring: Google Search Console's enhancement reports flag structured data errors across the whole site as Google recrawls, which is where you catch the regression a theme update introduced eight months after launch.

Then put a recurring reminder on the calendar. Every change to hours, phone, address, or ownership is a schema edit, the same day. Stale markup is worse than none, because it is confidently wrong.

Where LocalBusiness fits in your wider schema graph

LocalBusiness markup is one node, not the whole graph. A well-structured local site typically connects it to Article schema on its guides (with a Person author), FAQPage where genuine questions get answered, Service objects describing what you sell, and BreadcrumbList for hierarchy. Each block references the others by @id, so the crawler sees one coherent entity rather than scattered fragments. Building and maintaining that graph is the substance of our schema markup service, and the free cheatsheet maps which types belong on which page templates if you would rather build it yourself.

Either path is fine with us. The owners who copy the example above and validate it carefully are doing real Vector 6 work, and the ones who want the whole graph engineered and monitored know where to find us.