Local Business Schema: A JSON-LD Example, 2 Required Fields

Local business schema is a short block of code on your site that states your business name, address, hours and phone in a format search engines don't have to guess at. Google's LocalBusiness documentation, last updated September 8, 2026, requires only two of its fields (called properties): name and address. What the code won't do is lift your rankings.

The code is written in JSON-LD, a plain data format that Google recommends "if your site's setup allows it". Below is a full example for a made-up Toronto plumber. After it come business types, several locations, testing, and "near me" answers in AI assistants. The post belongs to our guide to structured data.

Key facts

What does a complete LocalBusiness JSON-LD example look like?

A complete block names the business, gives a full postal address, and adds the recommended details: hours, phone, page address and map coordinates. Paste it into the <head> of that location's page, then replace every value. Example Co. is invented. Phone numbers in the 555-01xx range are set aside for fiction, and M0M 0M0 is not a real postal code.

{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "@id": "https://www.example.com/locations/toronto-queen-west#business",
  "name": "Example Co. Plumbing Queen West",
  "url": "https://www.example.com/locations/toronto-queen-west",
  "telephone": "+1-416-555-0123",
  "image": [
    "https://www.example.com/photos/1x1/storefront.jpg",
    "https://www.example.com/photos/4x3/storefront.jpg",
    "https://www.example.com/photos/16x9/storefront.jpg"
  ],
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Example Street, Unit 4",
    "addressLocality": "Toronto",
    "addressRegion": "ON",
    "postalCode": "M0M 0M0",
    "addressCountry": "CA"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 43.64512,
    "longitude": -79.41234
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "18:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "09:00",
      "closes": "14:00"
    }
  ],
  "areaServed": "Toronto",
  "parentOrganization": {
    "@id": "https://www.example.com/#organization"
  }
}

In your page code, the block sits inside <script type="application/ld+json"> and </script>. The table explains each property, using the same Google page and schema.org, the shared vocabulary search engines read.

Two rules trip people up. For hours past midnight, the documentation shows "opens": "18:00", "closes": "03:00" on one day, and a closed day sets both to "00:00". Also, skip review stars for your own business. Those two properties are only for sites that review other businesses.

Which LocalBusiness subtype should you choose?

Pick the narrowest type that is true for you. Google asks for "the most specific LocalBusiness sub-type possible", so a plumber uses Plumber, not the generic type. If two types fit, list both, as in ["Dentist", "MedicalClinic"]. The additionalType property isn't supported.

One caution on ProfessionalService. Schema.org now marks it as deprecated "due to confusion with Service" and moved dentists, accountants and the trades to other types. The code still passes testing. Use a narrower type if one fits, and fall back to ProfessionalService or plain LocalBusiness only when nothing does.

How do you mark up multiple locations?

Give each location its own page and its own block, with that page's address in url. The documentation says to "define each local business location as its own LocalBusiness type".

Say a company has shops in Leslieville and Etobicoke. It builds two pages, /locations/leslieville and /locations/etobicoke, and each shows its own address, hours and phone in the visible text.

Each page carries one block that describes only that shop. Don't stack every branch onto the homepage.

The Leslieville and Etobicoke blocks each point parentOrganization at one company record on the homepage. Our Organization schema example shows how to write that record.

A shop with a separate service desk nests it under department in the same block. The suggested name format is "{store name} {department name}", so "Example Co. Leslieville Service Desk".

A service-area business with no storefront still needs a real address, because it's one of the two required properties. Add areaServed for the cities you cover.

How do you test local business schema?

Run the page through the Rich Results Test first, then the Schema Markup Validator. The first is the official tool for rich results, and the second checks the code against schema.org in general.

Fix every critical error. Warnings are worth fixing but don't block eligibility. Expect several days before the change shows in search.

The most common mistake is code that disagrees with the page. The general guidelines say "don't mark up content that is not visible to readers of the page", so the two must agree. A footer that says 9 to 5 next to code that says 8 to 6 is the classic case.

Other mistakes to check for:

• Every location crammed onto the homepage.
• Review stars for your own business.
• The generic type when Dentist or Plumber exists.
• Coordinates with too few decimals, or a url that leads to an error page.

Does local business schema help with "near me" answers in ChatGPT and Google AI?

Not directly, as far as anything published shows. Structured data feeds search features, not rankings, and AI answers don't need special code. Past that point it's inference, so we keep the two apart.

What Google documents. The markup makes a page eligible for a knowledge panel when someone searches your name, and a carousel on searches like "plumbers in Toronto". Even then, Google "does not guarantee" the feature will show.

Its AI features page says there's "no special schema.org structured data that you need to add" for AI answers. The same page does ask you to keep "Business Profile information up-to-date", meaning your free Google listing.

On rankings, John Mueller, a search advocate at Google, wrote in April 2025 that "structured data won't make your site rank better" and is used for search features instead.

The local ranking help page names three factors: relevance, distance and prominence. It says "businesses with complete and accurate info are more likely to show up in local search results", and it talks only about the listing, never schema.

What we infer. Consistency is the real job. Your name, address and phone now live in three places: the listing, the page and the code. Google wants the listing accurate and the code to match the page, so keep all three identical.

AI assistants lean on listings and reviews. ChatGPT turns a local question into web searches, as we explain in how ChatGPT recommends local businesses.

A sponsored study by Uberall, a listings software company, counted 120,000+ AI mentions of American businesses. Dentists that AI named averaged 643 Google reviews, while the ones it skipped averaged 253, and the study didn't measure schema at all.

So schema is hygiene, not a lever. It makes your facts clear to any system that reads your page, but it won't make up for 390 missing reviews.

When is local business schema not worth your time?

If your site already shows your address, hours and phone, and your Google listing is complete, schema adds little you can measure. We haven't tested whether it changes how often an AI assistant names a business, and we haven't found a public study that has. Your site may already output a basic block, so test a location page before writing a new one.

Schema is worth an hour when you have several locations, seasonal hours, or a business type that's easy to misread. Our list of structured data types Google still rewards shows where it fits.

To see what your site's markup says today, run a free site check.