AI Agent WorxVisit Website →
← Back to blog

7 Step Local Business Schema for Developers, Pass Google Validation

September 25, 2026
7 Step Local Business Schema for Developers, Pass Google Validation

LocalBusiness schema is structured data that tells Google your business name, address, phone number, hours, and location in a format search engines can read directly. Get the required properties right and your pages become eligible for richer Google displays like knowledge panel details, hours snippets, and map carousels. It works best in JSON-LD, and Google won't use it unless it passes validation.

TL;DR:

  • Using the most specific LocalBusiness subtype enhances the likelihood of unlocking features like menu links or booking actions in search results.
  • Placing validated JSON-LD structured data in server-rendered HTML improves reliability and compliance compared to client-side injected schema.
  • Ensuring all required properties are accurate and up-to-date is critical, as missing or outdated information can prevent eligible rich result displays.
  • Each physical location needs an independent LocalBusiness schema block with its own address, hours, and contact details for proper Google recognition.
  • Regular schema validation and updates are essential to maintain eligibility for enhanced features and prevent common errors like missing country codes or stale data.
Aiagentworx
Keep Your Business Details Working
Aiagentworx builds tailored AI systems that help small businesses automate repetitive tasks and respond more efficiently to customers.
Explore AI Agent Worx

Table of Contents

What Is LocalBusiness Schema and When Should You Use It?

LocalBusiness is a type defined on schema.org, sitting as a more specific branch of the broader Organization type. Every LocalBusiness is technically an Organization, but the reverse isn't true. If you run a business with a physical location or a defined service area, you almost always want LocalBusiness (or one of its subtypes), not the generic Organization markup.

That subtype distinction matters more than most developers assume. Schema.org lists dozens of LocalBusiness subtypes, from Restaurant and HealthClub to Dentist and AutoRepair. Google's Local Business structured data documentation recommends picking the most specific one that fits your business rather than defaulting to the generic type. A pizza place marked up as Restaurant gives Google a clearer signal than one just labeled LocalBusiness, and that specificity can influence which enhanced features become available.

Here's a distinction that trips people up constantly: schema markup and your Google Business Profile are not the same thing, and one doesn't replace the other. Your Business Profile is what you manage directly through Google. Your schema is what your website tells crawlers about itself. They should agree with each other, but they're separate systems serving separate purposes. Schema reinforces what's on the page. It doesn't work as a substitute for actual visible content. If your address only exists in a JSON-LD block and nowhere on the rendered page, you're setting yourself up for a policy problem, not a ranking win.

On format, Google supports three ways to write structured data: JSON-LD, Microdata, and RDFa. All three are technically valid, but they're not equally practical. JSON-LD is a script block you drop into the page, separate from your visible HTML. Microdata and RDFa require you to weave attributes directly into the HTML tags themselves, which gets messy fast when your markup or your content changes. Google's own guidance on how structured data works points to JSON-LD as the preferred format in most cases, and that's the format used throughout this guide.

Comparison of structured data formats

Why Bother With LocalBusiness Schema at All?

The honest answer: it doesn't move rankings by itself, but it opens doors that plain HTML can't. Once your required properties are in place and validated, your pages become eligible for a set of enhanced displays. Think knowledge panel reinforcement (Google matching your site data against what it already knows about your business), local carousels for "near me" style queries, and displayed opening hours pulled straight from your markup instead of a stale Google cache.

Some LocalBusiness subtypes unlock even more. Restaurants can surface menu links. Certain service categories can support booking actions directly in search results. None of this is automatic just because you added a script tag. Google decides which enhancements to show based on a mix of markup quality, page authority, and query context.

Here's the part worth repeating to anyone who thinks schema is a checklist you fill out once: completeness and accuracy beat field count, every time. Google's structured data guidelines are direct about this. It's better to include fewer properties, with every one of them correct and current, than to stuff in every optional field and let half of them go stale. A phone number that's two years out of date does more damage than no phone number at all, because it erodes trust between your markup and what Google can verify elsewhere.

Treat local business schema as reinforcement, not magic. It tells Google what you're already telling customers on the page, in a structured way the crawler can parse without guessing.

Google's documentation is specific about what you need. Skip a required property and your page won't be eligible for the enhanced display at all, according to Google's general structured data guidelines.

Required properties:

  • name: your business's actual name, matching what appears on the page
  • address: formatted as a nested PostalAddress object, with streetAddress, addressLocality, addressRegion, postalCode, and addressCountry (use the two-letter ISO country code, like US)
  • telephone: full number including country code where relevant
  • url: the canonical URL of the page

Recommended properties:

  • openingHoursSpecification: structured hours by day, using 24-hour HH:MM time format
  • geo: latitude and longitude, each needing at least 5 decimal places of precision per Google's local business documentation
  • image: a representative photo URL
  • priceRange: a simple indicator like $$
  • menu: for restaurants and food service subtypes

Here's a working JSON-LD example for a single location:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Riverside Dental Care",
  "image": "https://example.com/images/office.jpg",
  "telephone": "+1-555-201-3344",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "482 Elm Street",
    "addressLocality": "Springfield",
    "addressRegion": "IL",
    "postalCode": "62701",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.78157,
    "longitude": -89.64371
  },
  "url": "https://example.com",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "17:00"
    }
  ]
}

A microdata version of the same core fields looks like this, embedded in your actual HTML:

<div itemscope itemtype="https://schema.org/LocalBusiness">
  <span itemprop="name">Riverside Dental Care</span>
  <span itemprop="telephone">+1-555-201-3344</span>
</div>

Schema documents dozens of additional optional properties and example snippets worth bookmarking as a reference.

PropertyTypeRequired?Format notes
nameTextYesMatch visible page content exactly
addressPostalAddressYesNested object with full component breakdown
telephoneTextYesInclude country code
urlURLYesCanonical page URL
openingHoursSpecificationOpeningHoursSpecificationRecommended24-hour HH:MM format
geoGeoCoordinatesRecommendedMinimum 5 decimal places
imageURLRecommendedReal photo, not a placeholder
priceRangeTextRecommendedSimple symbol format like $$

How Do You Add and Validate LocalBusiness Schema?

The workflow is straightforward once you've picked your subtype. Here's the sequence that avoids most of the headaches:

  1. Choose the most specific LocalBusiness subtype that matches your business, not just the generic parent type.
  2. Write the JSON-LD block with your required properties first, then layer in recommended ones.
  3. Insert the script in the page's <head> or <body>, ideally rendered server-side in the initial HTML response rather than injected after the page loads with client-side JavaScript. Google's documentation on how structured data works treats server-rendered markup as the more reliable pattern, since client-side injection can create crawling inconsistencies.
  4. Test it with Google's Rich Results Test before you ship anything.
  5. Run it through the Schema Markup Validator as a secondary check for broader schema.org compliance beyond what Google specifically uses.
  6. Deploy, then check Search Console's URL Inspection tool to confirm Google is actually reading the markup the way you intended.
  7. Set a recurring calendar reminder to re-validate quarterly, since hours, addresses, and phone numbers change more often than developers remember to update schema.

If you're on a CMS, most modern platforms let you inject JSON-LD through a theme template, a header snippet field, or a dedicated schema plugin. For larger sites managing many locations, generating the JSON-LD server-side per location page, rather than relying on a single sitewide template, keeps each page's data accurate to its specific address and hours.

Common validator errors tend to repeat themselves: missing addressCountry, a telephone field with no country code, openingHoursSpecification written in 12-hour format instead of 24-hour, or a geo coordinate pair rounded to only two or three decimal places instead of the five Google expects. Most of these take thirty seconds to fix once the validator flags them; the problem is nobody runs the validator after the initial launch.

Pro Tip: Add a structured-data check to your build pipeline, not just your pre-launch checklist. A simple CI step that validates your JSON-LD output and flags missing required fields catches regressions before they ship, especially on sites where content editors can accidentally strip a schema block during a redesign.

For teams managing this alongside a broader website overhaul, it's worth folding schema validation into your standard site design and deployment process rather than treating it as a one-off task.

Modeling Multiple Locations and Business Subtypes

Multi-location businesses need one LocalBusiness entry per physical address, not one shared block that tries to cover every branch. Google reads each location as a distinct entity, and combining them into a single markup object undermines the accuracy the whole system depends on.

A few modeling rules worth locking in early:

  • Give each location page its own complete LocalBusiness markup, with its own address, phone number, and hours.
  • Use the most specific applicable subtype for every location individually. A restaurant chain with one location that also has a bar might warrant a different subtype nuance than a location without one.
  • Use branchCode to distinguish branded departments or franchise locations under a parent brand, and nest a department property when a location contains multiple distinct business units, like a hotel with an on-site spa.
  • Keep the homepage focused on Organization-level markup if the business operates as a broader brand, while individual location pages carry their own LocalBusiness data.
  • Canonicalize location pages carefully. Duplicate or near-duplicate location content confuses both search engines and structured data parsing, especially across similarly named branches in different cities.

Treat each location page as its own self-contained unit of truth. That's the model Google's documentation assumes, and fighting against it with shared or templated markup tends to backfire once you scale past two or three branches.

What Mistakes Make LocalBusiness Schema Ineligible?

Most schema problems come down to a handful of repeatable mistakes, and nearly all of them are avoidable with a five-minute review before deploy.

  • Hidden or empty structured data. Google's structured data policies are explicit that markup must reflect what's actually visible on the page. A JSON-LD block listing an address that appears nowhere in the rendered content is a policy violation risk, not just a missed opportunity.
  • Self-controlled review markup. If you control the reviews shown on your own site, your pages are ineligible for star review snippets in Google Search, per Google's review snippet guidelines. Third-party review platforms, not your own testimonials page, are the safe path if you want review stars to show.
  • Mismatches with your Google Business Profile. When your site's schema and your public Business Profile list different phone numbers, hours, or addresses, it creates confusion that can hinder both. Structured data should align with your verified profile, not diverge from it.
  • Sloppy formatting on precision fields. Geo coordinates need at least 5 decimal places, and opening hours need to follow the correct time format rather than shorthand like "9 to 5."
  • Overloading with every optional property. More fields aren't automatically better if half of them are outdated or wrong.

One statistic worth internalizing here: Google will not consider your page for a rich result at all if even one required property is missing, according to Google's own structured data guidelines. That's not a partial penalty. It's a binary gate.

Which Format and Tools Should You Actually Use?

JSON-LD wins for most sites, and it isn't close. It's a standalone block, easy to template, easy to update, and easy to audit without touching your visible HTML. Microdata and RDFa exist for cases where a legacy system or a specific CMS constraint makes inline attribute markup more practical, but for anyone building or maintaining a site from scratch, Google's own guidance points toward JSON-LD as the default.

For a working toolchain, keep it simple:

  • Google's Rich Results Test for the specific properties Google recognizes for enhanced displays
  • Schema Markup Validator for broader schema.org compliance checks
  • Search Console's URL Inspection tool to confirm what Google actually sees post-deploy
  • CMS-level schema plugins or generators to reduce manual JSON-LD writing, particularly on WordPress or similar platforms
  • A scheduled quarterly re-check, since hours, pricing, and addresses drift over time even when nobody touches the code

None of these tools replace human review. Automated validators catch format errors, not whether your priceRange actually reflects your current pricing.

How Aiagentworx Helps Keep Your Schema Accurate

Aiagentworx builds and maintains this kind of structured data as part of website design, build, and maintenance work for owner-led businesses, alongside SEO and online visibility support. The practical implementation approach means schema doesn't just get written once and forgotten. It gets checked against your live business hours, address changes, and new locations as they happen.

Priorities for Getting LocalBusiness Schema Right

If there's one lesson from watching how Google's guidelines are actually written, it's this: accuracy beats ambition every time. Teams that chase every optional property while letting the required ones go stale end up worse off than teams that nail four fields and update them religiously.

Treat structured data as a pipeline, not a one-time task. It needs testing before deploy, validation after deploy, and a recurring audit schedule that catches drift before Search Console does. Automate the validation step in your build process if you can. It's the cheapest insurance against a broken schema block shipping unnoticed for six months.

— Brian

Sources

FAQ

What Is LocalBusiness Schema?

LocalBusiness schema is a structured data type from schema.org that describes a business's name, address, phone number, hours, and location in a machine-readable format. It helps Google understand your business details well enough to potentially display them in enhanced search features like knowledge panels and local carousels.

Can You Give an Example of LocalBusiness Schema?

A basic example includes the required properties: name, address (as a nested PostalAddress object), telephone, and url, written in JSON-LD format inside a script tag. The full working example earlier in this guide shows how these fields nest together along with recommended properties like openingHoursSpecification and geo.

How Do I Add LocalBusiness Schema to My Website?

Write your JSON-LD block with the required and recommended properties, then insert it in your page's head or body, ideally rendered server-side rather than added by JavaScript after the page loads. Test it with Google's Rich Results Test and the Schema Markup Validator before deploying, then confirm it in Search Console afterward.

What's the Difference Between Business Schema and LocalBusiness Schema?

"Business schema" usually refers to the broader Organization type on schema.org, while LocalBusiness is a more specific subtype meant for businesses with a physical location or defined service area. Google's documentation recommends using the most specific subtype available, whether that's LocalBusiness generically or a narrower type like Restaurant or Dentist, rather than defaulting to Organization.

Does LocalBusiness Schema Guarantee Better Rankings?

No. It reinforces information Google can already find on your page and can make you eligible for enhanced displays, but it isn't a ranking factor on its own. Google's guidelines emphasize that accurate, complete markup improves eligibility and display quality, not organic ranking position directly.