Visit Website →
← Back to blog

3 Must-Have Local Business Schema Fields for Owners and Site Managers

September 30, 2026
3 Must-Have Local Business Schema Fields for Owners and Site Managers

LocalBusiness schema is a structured data format that tells search engines exactly what your business is called, where it operates, and how to reach it. The fastest fix for most sites is a JSON-LD LocalBusiness block on the homepage and every location page, containing a matching name, address, and telephone number. Get that right first, then layer in the extras.

TL;DR:

  • Use the most specific LocalBusiness subtype relevant to your operation, such as Dentist or Plumber, to provide search engines with clearer context.
  • For multiple locations, create a dedicated schema block per site with separate URLs and link them with @id references to avoid confusion.
  • Regularly validate your JSON-LD code with both Google's Rich Results Test and the Schema.org Validator, especially after any business detail updates.
  • Keep your schema data in sync with your Google Business Profile, updating it immediately after any change to hours, address, or services to prevent data mismatches.
Seohoneybadger
Make Your Local Business Easier to Find
Honey Badger SEO helps local businesses improve search visibility through SEO, website creation, and Google Business Profile management.
Explore local SEO services

Table of Contents

Why local business schema matters for search and AI results

LocalBusiness schema is a vocabulary defined by Schema that describes a physical or service-area business in a format machines can parse without guessing. Search engines use it to build rich results, populate knowledge panels, and increasingly, to source the facts that AI Overviews and other generative answers cite when someone asks "is this place open" or "what does this business do." Without it, a search engine has to infer your name, hours, and location from unstructured text, which is slower and more error prone.

There's a meaningful difference between Organization and LocalBusiness. Organization suits a brand with no single physical presence: a software company, a national franchise headquarters, a media outlet. LocalBusiness suits any operation tied to a specific address or service area: a clinic, a repair shop, a law firm, a restaurant. If your business has a storefront or a service radius, LocalBusiness (or one of its subtypes) is the correct choice, not Organization.

A few practical distinctions to keep straight:

  • LocalBusiness describes an entity tied to a place or a defined service area, not a national brand with no fixed location.
  • Organization fits corporate entities, nonprofits, or brands without a customer-facing address.
  • Subtypes like Dentist, Plumber, or Restaurant inherit LocalBusiness properties while adding context search engines can use more precisely.

Google's own structured data guidance for local businesses treats this as foundational: name, address, and phone number are the baseline for eligibility, and everything else builds on top of that core.

Pro Tip: If you're unsure which type applies, start with LocalBusiness and upgrade to a specific subtype once you confirm it renders cleanly in testing.

Three properties are non-negotiable: name, address, and telephone. Google's structured data documentation lists these as the baseline for rich result eligibility, and skipping any one of them is the most common reason a schema block gets ignored entirely.

Beyond the baseline, a handful of properties do most of the heavy lifting for local relevance:

  • name: the exact business name as it appears on your Google Business Profile and website, character for character.
  • address: a nested PostalAddress object with streetAddress, addressLocality, addressRegion, postalCode, and addressCountry using the ISO two-letter country code.
  • telephone: formatted in international E.164 style, for example +1-512-555-0100, which Schema.org's examples use to avoid parsing ambiguity.
  • geo: a GeoCoordinates object with latitude and longitude, ideally carried to at least five decimal places for precise map placement.
  • openingHoursSpecification: a structured object per day, using 24-hour hh:mm:ss format for opens and closes times.
  • url: the fully-qualified canonical URL of the page, never a relative path.
  • image: a direct link to a representative photo, ideally the same one used on your Google Business Profile.
  • priceRange: a simple string like $$ or $10-$30 that gives searchers a quick cost expectation.
  • areaServed: used instead of a fixed address for businesses that travel to customers rather than operate from a storefront.

Formatting matters more than most site owners expect. A phone number written as (512) 555-0100 without international formatting can still parse, but E.164 formatting removes ambiguity for automated systems reading the data across regions. Country codes belong in the ISO 3166-1 alpha-2 format (US, CA, GB), not full country names. Opening hours need the hh:mm:ss structure, not "9am to 5pm" written as plain text.

Here's a minimal address and hours fragment showing the correct shape:

"address": {
  "@type": "PostalAddress",
  "streetAddress": "123 Main St",
  "addressLocality": "Austin",
  "addressRegion": "TX",
  "postalCode": "78701",
  "addressCountry": "US"
},
"openingHoursSpecification": [{
  "@type": "OpeningHoursSpecification",
  "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
  "opens": "09:00:00",
  "closes": "17:00:00"
}]

For lat/long precision, provide at least five decimal places to anchor the business accurately, since coarser precision can weaken relevance in dense, competitive geographies like a shopping district or a downtown core with multiple similarly named businesses nearby.

Schema.org's reference page also documents properties like branchCode, currenciesAccepted, and paymentAccepted, which are worth adding once the core fields are solid but shouldn't distract from getting name, address, and telephone correct first.

Adding JSON-LD step by step, from template to live page

JSON-LD is the format Google recommends for structured data because it lives in a self-contained script block rather than being woven through your visible HTML, which cuts down on formatting mistakes compared to Microdata or RDFa. It sits inside the <head> or before the closing </body> tag, wrapped in a <script type="application/ld+json"> tag, and never touches your visible page content.

For a single-location business, a clean baseline template looks like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.com/#business",
  "name": "Example Dental Clinic",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "telephone": "+1-512-555-0100",
  "url": "https://example.com",
  "image": "https://example.com/images/storefront.jpg",
  "priceRange": "$$"
}
</script>

When a page carries multiple related entities, such as a location page that also describes a specific service and a breadcrumb trail, wrap everything in a single @graph array and link the pieces with @id references rather than repeating full blocks. Google's practitioner guidance on structured data notes that this avoids duplicated nodes and keeps provider relationships explicit:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "LocalBusiness",
      "@id": "https://example.com/#business",
      "name": "Example Dental Clinic"
    },
    {
      "@type": "Service",
      "name": "Teeth Whitening",
      "provider": { "@id": "https://example.com/#business" }
    }
  ]
}

Follow this deployment sequence rather than pushing straight to production:

  1. Draft the JSON-LD block using your actual business data, not placeholder text.
  2. Lint the raw JSON for syntax errors using any JSON validator before it ever touches a live page.
  3. Test with both the Google Rich Results Test and the Schema.org Validator to catch rendering issues and semantic errors separately.
  4. Stage the change on a preview or staging URL if your CMS supports it.
  5. Publish to the live page once both tools return clean results.
  6. Monitor Google Search Console's Enhancements reports weekly for the first month, then monthly after that.

A few habits keep this process from breaking down:

  • Never hand-edit JSON-LD directly in a CMS text field without validating it first, since a single missing comma breaks the entire block.
  • Keep one canonical @id per business location so every page referencing that entity points to the same node.
  • Store your template in version control or a shared document so future edits start from a known-good baseline.

Pro Tip: Run the Schema.org Validator before the Rich Results Test. It catches structural and type errors that Google's tool sometimes lets through silently.

Picking the most specific business type

Schema.org documents dozens of LocalBusiness subtypes, from Dentist and Plumber to DaySpa and Restaurant, and using the most specific one available gives search engines more context than the generic LocalBusiness type alone. A plumbing company marked up as Plumber signals its category directly, rather than forcing a search engine to infer it from surrounding text.

Some practical guidance for picking a type:

  • Use the most specific subtype that accurately describes the core service, such as Electrician over a generic LocalBusiness for an electrical contractor.
  • List multiple types with an array when a business genuinely spans categories, such as a spa that also operates as a retail shop.
  • Fall back to plain LocalBusiness when no subtype fits, rather than forcing an inaccurate match just to appear more specific.
  • Avoid switching types repeatedly, since consistency over time matters more than chasing a marginally better-fitting subtype.

A hybrid business, say a bakery that also caters events, can reasonably use Bakery as the primary type while adding FoodEstablishment properties where relevant. The goal is accuracy, not maximizing the number of types attached to one entity.

Handling service-area businesses and multiple locations

Service-area businesses (SABs), like mobile detailers or home repair contractors who don't operate from a public storefront, should omit streetAddress entirely and rely on areaServed instead. Publishing a home address for a business that operates out of a residence creates a real privacy risk with no SEO upside.

Service area boundary excluding private business address

For multi-location businesses, the cleanest approach is one dedicated LocalBusiness block per location page, each with its own @id, address, and phone number, rather than one bloated schema block trying to represent every branch at once. A parent Organization node can then reference each location's LocalBusiness node through @id links, giving search engines a clear map of the overall structure without duplicating data.

Key rules to follow:

  • Never publish a residential address for a home-based SAB; use areaServed with city or region names instead.
  • Give every physical location its own schema block and its own URL, rather than combining locations onto a single page.
  • Link a parent Organization to each location's LocalBusiness node using @id references when the brand operates at scale.

Pro Tip: For SABs, list areaServed as an array of city or county names rather than a single broad region. It gives search engines finer-grained targeting without exposing a home address.

Testing and fixing common schema errors

Two tools do different jobs, and using only one leaves gaps. The Google Rich Results Test shows exactly what Google will render in search results based on your markup, while the Schema.org Validator checks the underlying JSON against the full schema.org vocabulary and catches type or semantic errors that the Rich Results Test can miss entirely.

Run both, in this order:

  1. Paste the live URL or raw code into the Google Rich Results Test and check whether LocalBusiness is detected and eligible for enhancement.
  2. Run the same code through the Schema.org Validator to confirm every property and type matches the official vocabulary.
  3. Cross-check the NAP fields (name, address, phone) against your Google Business Profile listing to confirm they match exactly.
  4. Fix syntax errors first, since a single misplaced bracket or missing comma can invalidate an entire block.
  5. Re-test after every fix rather than batching multiple changes and testing once at the end.

The failure patterns that show up most often in practice are predictable: broken JSON syntax from a hand edit, a phone number or address that doesn't match the Google Business Profile listing, opening hours that were never updated after a holiday schedule change, and a generic LocalBusiness type used where a specific subtype like Dentist or Plumber was available. Mismatched NAP data between your schema and your Google Business Profile is one of the most common reasons a business's structured data gets discounted rather than used, which is why keeping GBP and website data aligned is worth treating as a standing task, not a one-time setup step.

Consistency between your on-page content, your JSON-LD, and your Google Business Profile listing is the factor practitioners cite most often when structured data gets ignored. A phone number that's correct in one place and outdated in another undermines the whole block.

Once markup is live, check Google Search Console's Enhancements section periodically. It flags specific validation issues Google's own crawlers encountered, which sometimes differ from what the Rich Results Test shows for a single URL tested manually.

A maintenance checklist to keep schema accurate

Treat LocalBusiness schema as a living asset tied to your actual business operations, not a one-time technical task you finish and forget. Anytime your hours, address, phone number, or services change, the schema needs to change with it, and the highest-priority pages get the schema first.

  1. Homepage LocalBusiness block, since it's the entity search engines reference most often for brand-level queries.
  2. Location pages, each with its own LocalBusiness node and matching NAP data.
  3. Service pages, marked up with Service schema referencing the parent LocalBusiness via @id.
  4. BreadcrumbList on deeper pages, where a clear site hierarchy helps both users and crawlers.

A simple cadence keeps this from decaying: check schema validity monthly, and immediately after any change to hours, address, phone number, or service lineup.

TriggerAction
Business hours changeUpdate openingHoursSpecification and re-test
Address or phone changeUpdate schema and Google Business Profile together
New service addedAdd a Service node referencing the LocalBusiness @id
Quarterly reviewRe-run Rich Results Test and Schema.org Validator

Copy this sequence into your CMS deployment plan and assign it to whoever owns your Google Business Profile, since that's usually the same person who'll notice a hours or address change first.

What years of local audits reveal about schema mistakes

Across the local business sites we've reviewed, a recurring pattern shows up: most either have no LocalBusiness schema at all or have a block that technically exists but fails validation because of a syntax error or a mismatched phone number. The single highest-leverage fix, more often than adding new properties, is simply correcting what's already broken and making sure it matches the Google Business Profile listing exactly.

Honey Badger SEO built its audit process around catching that gap early, since a broken schema block is often invisible to the business owner until a search console report or a rich results test surfaces it. The fix is rarely complicated. It's usually a missing comma, an outdated phone number, or a generic type where a specific one was available all along.

— Anas

How Honey Badger SEO handles schema implementation

Getting LocalBusiness schema right takes more than copying a template. It takes matching it to your Google Business Profile, your actual service pages, and keeping it current every time something changes, which is exactly the kind of ongoing, hands-on work Honey Badger SEO builds into its Local SEO engagements.

Seohoneybadger

Every plan includes technical and on-page work, Google Business Profile setup and optimization, and website implementation, handled with direct oversight rather than outsourcing or delegation to junior staff. That means the person who writes your LocalBusiness JSON-LD is the same person who tests it, monitors it in Search Console, and fixes it when your hours or address change. Local SEO pricing details are available on Honey Badger SEO's website, featuring transparent monthly plans without long-term contracts.

If your business operates in a specific market, dedicated pages cover dental practices, insulation contractors, and med spas, alongside broader website builds designed to rank and convert. Check current availability and pricing at Honey Badger SEO.

Where to verify your schema right now

Sources

FAQ

What is a local business schema?

LocalBusiness schema is a structured data vocabulary from Schema.org that describes a business tied to a physical location or service area, including its name, address, and phone number. Search engines use it to build rich results and knowledge panels rather than guessing those facts from page text.

Can you give me an example of a local business schema?

A minimal example includes the @type of LocalBusiness, a name, a nested PostalAddress object, and a telephone field formatted in international style like +1-512-555-0100. Adding geo, openingHoursSpecification, and priceRange strengthens it further, as shown in the JSON-LD templates in this guide.

How do I add a local business schema to my website?

Write the JSON-LD block with your business's real name, address, and phone number, then place it inside a <script type="application/ld+json"> tag in the page's HTML. Validate it with the Google Rich Results Test and the Schema.org Validator before publishing, then recheck it any time your business details change.

What is a business schema?

"Business schema" usually refers to either Organization or LocalBusiness schema, depending on whether the business has a physical location or service area. A brand with no customer-facing address typically uses Organization, while a storefront, clinic, or service-area business uses LocalBusiness or a more specific subtype.

Does local business schema actually improve local search rankings?

Structured data itself is not a direct ranking factor, but it helps search engines understand and display your business accurately in rich results and knowledge panels. Consistent, error-free LocalBusiness markup that matches your Google Business Profile is one of the more reliable ways to make sure your business information gets used rather than ignored.