LocalBusiness schema is a block of structured data that tells Google exactly who you are, where you are, and how to reach you, using Schema’s standardized vocabulary. Add a JSON-LD block using the most specific subtype available, your business name, full address, and a properly formatted phone number, and keep every detail identical to your Google Business Profile. Schema sharpens how search engines and AI tools read your business. It doesn’t replace the ranking work your listing and reviews still have to do.


TL;DR:

  • Using specific LocalBusiness subtypes unlocks additional properties like menu details for restaurants or hours for salons, enhancing search result displays.
  • Google’s four mandatory schema fields are @type, name, address, and telephone, with address formatted as a PostalAddress object and phone in international format; mistakes here often invalidate rich results.
  • Accurate schema must match your Google Business Profile exactly in name, address, and phone to avoid disqualification and ensure consistency across your listings and website content.
  • For multi-location businesses, each physical site requires its own schema with a unique @id to prevent ambiguity and improve local entity recognition.
  • Regular validation and maintenance of schema code, especially after updates to hours or locations, are essential to sustain rich result eligibility and accurate local SEO signals.

Ibrand
Strengthen Your Local Visibility
Ibrand helps small businesses improve local visibility through SEO, local marketing, web design, advertising, and performance analytics.
Explore Ibrand’s services

Table of Contents

What LocalBusiness Schema Is and Why It Matters for Local SEO

LocalBusiness is a type defined by Schema.org, the shared vocabulary search engines use to parse structured data on your pages. It sits under the broader Organization type but adds properties that only make sense for a business with a physical presence or a defined service area: address, opening hours, price range, geographic coordinates. Organization schema works for a corporate entity with no storefront. LocalBusiness works for the dentist, the taco shop, or the plumbing company that shows up on a map.

The subtype choice matters more than most owners realize. Schema.org lists dozens of LocalBusiness subtypes, and picking the closest match, Restaurant instead of generic LocalBusiness, HairSalon instead of Store, unlocks properties specific to that category. A restaurant using the Restaurant subtype can add servesCuisine and menu data. A generic LocalBusiness tag can’t, because Google’s parsers don’t map those properties to it. Search Engine Journal’s guide to local schema makes this point directly: the more specific the type, the richer the features you’re eligible for.

Here’s what schema realistically buys you:

  • Rich result eligibility. Pages can display opening hours, price range, and location details directly in search results.
  • Cleaner entity data. Search engines and AI systems parse your name, address, and category with less ambiguity, which matters as more assistants pull answers from structured data rather than crawled text.
  • Knowledge panel reinforcement. Consistent schema backs up the identity signals Google already has from your Google Business Profile.

None of that guarantees local-pack placement. Semrush’s breakdown of local business schema is blunt about this: schema supports your existing signals, it doesn’t create them. The factors that actually move the needle on map-pack rankings are still your Google Business Profile completeness, physical proximity to the searcher, and review volume and quality. Schema is the layer that makes your existing signals unambiguous to a machine. It’s not a substitute for building them.

Which Properties Does Google Require for Rich Results?

Google’s structured data guidelines spell out exactly four required properties, and missing any one of them disqualifies your markup for enhanced search features. Google Search Central’s LocalBusiness documentation lists them plainly:

  • @type — the most specific subtype your business fits, not the generic “LocalBusiness” fallback.
  • name — your business name, exactly as it appears everywhere else online.
  • address — structured as a PostalAddress object with streetAddress, addressLocality, postalCode, and addressCountry.
  • telephone — formatted in international format (for a U.S. business, that’s +1 followed by the area code and number).

Beyond those four, Google recommends a longer list that isn’t mandatory but noticeably improves how your listing renders: geo (latitude and longitude), openingHoursSpecification, priceRange, url, sameAs (links to your social profiles), image, and aggregateRating when you have genuine, verifiable reviews to back it.

One in four required fields gets this wrong on a typical audit. The most common failure isn’t a missing field. It’s a mismatched one, an address in schema that doesn’t match the one on your Google Business Profile, or a phone number formatted for local dialing instead of international. Both technically “exist” in the code. Neither passes a careful validation check.

A few formatting details trip up otherwise solid markup:

  • Geo coordinates need precision. Round numbers or coordinates truncated to two decimal places can place your business blocks away from its actual location. Aim for five or more decimal places.
  • Opening hours follow a strict time format. openingHoursSpecification expects opens and closes values in hh:mm:ss format, and Google’s own documentation notes support for validFrom and validThrough when you need to mark seasonal hours or holiday closures.
  • Country codes stay in ISO format. addressCountry should read US, not “United States” or “USA.”

Three red flags deserve an immediate fix if you spot them in your current markup: a NAP (name, address, phone) mismatch between your schema and your Google Business Profile, a generic LocalBusiness type when a specific subtype exists for your industry, and any aggregateRating or review markup that doesn’t correspond to reviews actually published and verifiable on your site. That last one isn’t just sloppy. Google treats fabricated review markup as a violation, and getting caught can mean losing rich result eligibility across your entire domain.

What Does a Local Business Schema Example Look Like?

The fastest way to understand LocalBusiness schema is to see it fully built out. Below is a minimal, valid template for a single physical location using a specific subtype:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Example Café",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Springfield",
    "postalCode": "62704",
    "addressCountry": "US"
  },
  "telephone": "+12175551234"
}

That covers the four required fields and nothing else. It will validate, but it won’t earn you the richer display features Google supports. An expanded version adds the recommended properties:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example.com/#restaurant",
  "name": "Example Café",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Springfield",
    "postalCode": "62704",
    "addressCountry": "US"
  },
  "telephone": "+12175551234",
  "url": "https://example.com",
  "priceRange": "$$",
  "image": [
    "https://example.com/images/storefront.jpg",
    "https://example.com/images/interior.jpg"
  ],
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.78421,
    "longitude": -89.64394
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "11:00:00",
      "closes": "21:00:00"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/examplecafe",
    "https://www.instagram.com/examplecafe"
  ]
}

The @id field matters more than it looks. It gives your business a unique identifier that search engines can reference across multiple schema blocks on your site, which becomes critical the moment you have more than one page describing the same entity.

Here’s a quick reference for which fields belong in which scenario:

Field Single location Service-area business Notes
address (PostalAddress) Required Omit if no public address Use areaServed instead for service-area businesses
areaServed Optional Required Accepts a city, state, or radius description
geo Recommended Optional Less useful without a fixed address
openingHoursSpecification Recommended Recommended Still applies to phone hours or service windows
priceRange Recommended Recommended Use symbols like “$$” or a numeric range

If you run a business with no walk-in storefront, a mobile locksmith or a home cleaning service, drop address entirely and use areaServed instead:

"areaServed": {
  "@type": "City",
  "name": "Springfield, IL"
}

For businesses with multiple departments under one roof, Schema.org’s LocalBusiness examples show nested department blocks, useful for something like a hardware store with a distinct garden center that has its own hours or contact number.

How Do I Add LocalBusiness Schema to My Website?

Getting the code onto your site is simpler than most owners expect. It comes down to three approaches, ranked by how much technical comfort they require.

  1. Write the JSON-LD manually and paste it into your page. Wrap your finished code in a <script type="application/ld+json"> tag and place it in the <head> of your location page, or right before the closing </body> tag if your CMS doesn’t give you head access. Back up your theme files before editing anything directly.
  2. Use a CMS plugin to generate and inject it for you. Most WordPress SEO plugins include a structured data module that walks you through filling in fields, name, address, hours, and outputs the JSON-LD automatically without touching theme code. This is the path most non-technical owners should take.
  3. Generate the code with a free tool, then adapt it. Google’s Structured Data Markup Helper lets you tag elements on a live page visually and exports working JSON-LD. It’s a solid starting point, but always review the output. Generators frequently miss the specific subtype and default to generic LocalBusiness, which you should manually correct.

Once the code is live, run through this deployment checklist before you consider the job done:

  1. Validate the markup with Google’s Rich Results Test.
  2. Cross-check every field against your Google Business Profile for exact matches.
  3. Confirm the visible content on the page, hours, phone number, address, matches what’s in the schema. A mismatch between what a visitor sees and what the code says is a red flag to search engines.
  4. Check Search Console’s structured data reports a few days after deployment to catch anything the initial test missed.

Pro Tip: Test your JSON-LD in a text validator before you ever touch your live site. A single missing comma or unclosed bracket breaks the entire block silently, and you won’t know until Search Console flags it days later.

How Should Multi-Location Businesses Structure Their Schema?

Every physical location needs its own page and its own JSON-LD block. That’s the rule, and it’s the one owners with three, five, or fifteen locations get wrong most often by trying to shortcut it.

  • One page, one block, one unique @id per location. Copying the exact same schema across every location page and just swapping the address is a common shortcut that backfires. Search engines read identical blocks with only a city changed as evidence of a templated, low-effort setup rather than genuinely distinct businesses.
  • Service-area businesses skip the street address. If you don’t have a public storefront, a mobile dog groomer or an HVAC repair company, use areaServed and describe your coverage by city, state, or ZIP code rather than listing an address that doesn’t exist for walk-ins.
  • Granularity helps. “Springfield, IL” is more useful to a search engine than “Central Illinois.” Specific city, county, or ZIP-level detail lets Google match your service area to a searcher’s location more precisely.
  • Duplication creates entity ambiguity. BrightLocal’s schema template guidance recommends distinct blocks per location precisely because search engines use schema to disambiguate similarly named businesses in different cities. Identical markup defeats that purpose.
  • Link each location page to its own Google Business Profile, and where relevant, add a hasMap property pointing to that location’s map listing. This reinforces the connection between your schema and the profile Google already trusts.

If you operate service-area pages instead of storefronts, this is worth reading in full: our service area business SEO playbook covers how to structure those pages so schema and content reinforce each other instead of working at cross purposes.

How Do I Validate and Fix LocalBusiness Schema Errors?

Two tools do almost all the work here. Google’s Rich Results Test tells you whether your markup is eligible for enhanced search features and flags both errors and warnings. Errors are blocking, fix those first. Warnings are recommendations, missing a priceRange or image field won’t disqualify you, but adding it improves what shows up in results. Schema.org’s own validator is worth running as a second pass, since it checks against the full type specification rather than just Google’s feature requirements.

Search Console surfaces structured data issues over time under its enhancement reports, which is where you’ll catch problems that a one-time test missed, like a template change that accidentally stripped your schema from every page at once.

The errors worth prioritizing, in order:

  • NAP mismatches. Your name, address, and phone number in schema must match your Google Business Profile exactly. SEO Pro Check’s guide to LocalBusiness schema points out that inconsistencies here reduce entity confidence and can create conflicting signals search engines have to resolve on their own, often incorrectly.
  • Wrong or generic subtype. If a specific subtype exists for your business and you’re still using plain LocalBusiness, that’s an easy fix with real upside.
  • Fabricated review markup. Never add aggregateRating or review properties that don’t correspond to real, visible reviews on your page.
  • Malformed openingHoursSpecification. Wrong time format or missing dayOfWeek arrays are among the most common warnings flagged in testing.

Fix errors first, warnings second, then re-run the Rich Results Test on the live URL, not a staging copy, to confirm the fix actually took.

Best Practices for Keeping Schema Accurate Over Time

Treat your schema as the canonical record of your business identity, not a one-time SEO task you check off and forget. It should never drift from what’s on your Google Business Profile or what a visitor actually sees on the page. When those three sources disagree, search engines have to guess which one is right, and that guess doesn’t always favor you.

Build a maintenance rhythm around it: audit your schema any time you change hours, move locations, or rebrand, and fold a structured data check into whatever monthly site audit routine you already run. Resist the urge to over-tag. Adding every optional property Schema.org lists, or worse, review markup you can’t back up, creates more risk than benefit. Stick to the most specific subtype your business fits and the properties you can keep accurate.

Keep a simple log of when you deployed or changed schema, and check Search Console afterward for regressions. A versioned record makes it far easier to trace a sudden drop in rich result eligibility back to the change that caused it, rather than guessing weeks later.

Best Practices for Keeping Schema Accurate Over Time — overview diagram

What an Agency Sees When Schema Becomes Part of a Local Campaign

Schema audits are one of the first things worth checking in any local campaign, right alongside Google Business Profile accuracy. Most small business sites either have no structured data or have LocalBusiness markup that quietly drifted out of sync with their listing months ago. Fixing that isn’t dramatic work, but it’s foundational.

The realistic uplift is entity clarity, not overnight rankings. Once search engines and AI tools can parse your hours, address, and category without guessing, you tend to see steadier rich result appearances over weeks, not days. A business handling a single location with basic technical comfort can do this correctly with the templates above. Hire help once you’re managing multiple locations, need ongoing validation, or want schema tied into a broader local SEO effort rather than treated as an isolated fix.

— TONY

How Ibrand Handles Schema and Local Visibility for You

Getting LocalBusiness schema right across one location is manageable with a template and twenty minutes. Getting it right across five locations, tied cleanly to five Google Business Profiles, with validation logs and NAP consistency checked monthly, is a different job entirely, and it’s the kind of detail work that quietly falls off the priority list for a busy owner.

Ibrand

We handle that work as part of a broader local SEO engagement: a schema audit, deployment of correctly typed JSON-LD across locations or service-area pages, validation through Google’s Rich Results Test, and ongoing checks to maintain accuracy after changes. Structured data is typically audited and redeployed early in a new engagement. If you want a starting point, check out our website optimization services for small businesses for more information and to request a plan based on your locations and setup.

Useful Resources for Validating Your Schema

  • Google Search Central’s LocalBusiness documentation lays out required and recommended properties directly from the source that decides rich result eligibility.
  • Schema lists every subtype and property available, useful when you’re deciding how specific to get.
  • Google’s Rich Results Test and Schema.org’s validator both check your live JSON-LD for errors before you consider a deployment finished.

Sources

FAQ

What Is LocalBusiness Schema?

LocalBusiness schema is structured data, based on the Schema.org vocabulary, that tells search engines your business name, address, phone number, and category in a machine-readable format rather than relying on them to parse it from page text.

Can You Give an Example of LocalBusiness Schema?

A minimal example includes the @type (a specific subtype like Restaurant or Dentist), name, an address formatted as a PostalAddress object, and a telephone number in international format, wrapped in a JSON-LD script block. The full templates above show both a minimal and an expanded version.

How Do I Add LocalBusiness Schema to My Website?

Paste your JSON-LD inside a <script type="application/ld+json"> tag on your location page, use a CMS plugin’s structured data module if you’re not comfortable editing code directly, or generate a starting template with Google’s Structured Data Markup Helper and adjust it manually. Always validate the result with the Rich Results Test before considering it live.

What Is Business Schema, Generally?

Business schema is a broader term covering Schema.org types like Organization and LocalBusiness that describe a company’s identity, contact details, and category to search engines. LocalBusiness is the subtype to use specifically when the business has a physical location or a defined service area.

Do I Need a Different Schema for Each Business Location?

Yes. Each physical location needs its own page with its own JSON-LD block and a unique @id, since identical blocks copied across locations create ambiguity that undermines the entity clarity schema is supposed to provide.