What LocalBusiness Schema Is (and Which Fields Matter)

What it actually is

Schema.org is a shared vocabulary for describing things on the web. LocalBusiness is one type in that vocabulary, and it exists to describe an organisation that serves customers in a physical place.

Writing it into your page, usually as JSON-LD, hands an engine a structured statement of your facts instead of asking it to infer them from your layout. That is the entire purpose, and it is why Lesson 4: schema and structured data for local AI SEO treats it as an ambiguity-removal tool rather than a growth lever.

Picking the right type

LocalBusiness has dozens of subtypes: Plumber, Electrician, Dentist, HVACBusiness, Restaurant, AutoRepair, AccountingService and so on. Use the most specific one that genuinely describes you.

Two rules keep this simple. If a subtype names what you do, use it. If nothing fits properly, use LocalBusiness rather than forcing a bad match, and let your services list and page content carry the specifics.

A wrong specific type actively misinforms. A correct general type plus clear content does not.

The fields that earn their place

Everything in that block must match your visible page and your business profile. Markup that disagrees with either is worse than none, because it manufactures the contradiction that Lesson 2 exists to eliminate.

Fields people add that change nothing

slogan. Nobody retrieves a slogan.

foundingDate on its own, with no other trust signals. Fine to include, not worth debating.

Elaborate makesOffer structures for a business with three services. The complexity outruns the benefit.

aggregateRating from a third-party platform. This is not merely useless, it is against the guidelines and can cost you rich result eligibility.

Duplicated blocks from two plugins. A common WordPress problem where the theme and an SEO plugin each emit their own LocalBusiness block, often disagreeing. One block, one source of truth.

A minimal working example

{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "@id": "https://example.com/#organization",
  "name": "Example Plumbing",
  "url": "https://example.com/",
  "telephone": "+61 3 9000 0000",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "14 Hammond Road",
    "addressLocality": "Dandenong",
    "addressRegion": "VIC",
    "postalCode": "3175",
    "addressCountry": "AU"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": -37.9884, "longitude": 145.2148 },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "07:30",
      "closes": "17:00"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/exampleplumbing",
    "https://www.linkedin.com/company/exampleplumbing"
  ]
}

The @id matters more than it looks. Giving your organisation a stable identifier lets other blocks on your site, such as a Service or Article block, reference the same entity instead of describing a second one.

Getting it onto the site

Writing the block is the easy part. Installing it correctly, on the right pages, and confirming it renders is where things go wrong. The guide on adding JSON-LD to a local business site covers WordPress, site builders and hand-coded sites, plus the mistakes that silently invalidate a block.

And before you spend the afternoon: check whether schema is the right priority at all. If your pages have nothing specific to quote, correct markup will not create something. Work through Lesson 3 first.

Picking the right subtype for your trade

The subtype list is long and uneven. Some trades have an exact match, some do not, and the gap causes more hand-wringing than it deserves.

When nothing fits, LocalBusiness with clear service content is the correct answer. Forcing a near-match that misdescribes you is worse, because structured data is the one place where you are explicitly telling a machine what you are.

Where the block belongs

One organisation block, on the pages that describe the organisation. In practice that means the homepage and the contact page at minimum, and often sitewide through a shared template.

Service pages can carry an additional Service block that references the organisation by @id, rather than repeating a second full business description. That keeps one entity definition and avoids the duplication problem that plugin stacks create.

FAQ blocks are separate and can coexist on the same page, as long as the questions genuinely appear in the visible content. The guide on adding JSON-LD covers installation and validation for each platform.

Fields worth adding once the basics are right

After name, address or areaServed, phone, hours, URL, geo and sameAs, a handful of properties earn their place for specific situations.

hasOfferCatalog when you offer several distinct services and want each named in structured form. Useful for a business whose services differ meaningfully in price or process.

paymentAccepted and currenciesAccepted where payment options are a genuine customer question, such as trade accounts or particular payment methods.

founder or employee as a Person, with sameAs links, when a named individual is a real trust signal in your sector. Sole traders and professional practices benefit most.

makesOffer with price specifications only when your prices are genuinely fixed. If they vary by job, prose on the page serves better than markup that will go stale.

openingHoursSpecification with seasonal variations for businesses whose hours change meaningfully across the year.

The rule remains the same at every level of detail: only add what is true, only add what you will maintain, and never let the markup say something the page does not.