What Is LocalBusiness Schema?

LocalBusiness schema is structured data used to describe a physical business or local branch using the Schema.org vocabulary.

It can give machines a clearer description of information already associated with a business, including:

• business name;
• physical address;
• telephone number;
• website URL;
• opening hours;
• latitude and longitude;
• business type;
• price range;
• related identity profiles.

Google supports several structured-data formats, but recommends JSON-LD for most implementations.

The important point is that structured data should describe the actual entity and support information users can verify from the page.

It should not be treated as a hidden SEO field where additional locations, keywords, ratings, services, or claims can be inserted without corresponding page content.

If you need a broader introduction first, read our schema markup guide.

What Does Google Actually Require for LocalBusiness Schema?

Many LocalBusiness guides publish long lists of supposedly mandatory fields.

Google’s current documentation is simpler.

That does not mean a useful implementation should contain only those two properties.

Google also documents recommended properties that provide additional information when relevant.

Four labels you should not confuse

This distinction prevents a common mistake: assuming that every property available at Schema.org is required by Google.

Required vs Recommended LocalBusiness Properties

Choose the Most Specific LocalBusiness Type

LocalBusiness is a broad Schema.org type.

When a more specific subtype accurately represents the company, Google recommends using that more specific type.

Do not choose a business subtype simply because it contains a keyword you want to rank for.

The type should represent what the business actually is.

Can a Local Business Use Multiple Schema Types?

Yes, when multiple types genuinely describe the same business.

Google’s current LocalBusiness documentation shows that multiple applicable types can be provided as an array in @type.

For example, a company that genuinely operates as an electrician, plumber, and locksmith could use:

"@type": [
  "Electrician",
  "Plumber",
  "Locksmith"
]

This is preferable to inventing a hybrid type that does not exist.

For Google’s LocalBusiness implementation, do not assume additionalType is a substitute for the documented multiple-@type pattern.

Only include types the business genuinely satisfies.

LocalBusiness JSON-LD Example

The example below represents a fictional dental office.

Replace every value with information that is accurate and visible for the business you are marking up.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://www.example.com/locations/downtown/#localbusiness",
  "name": "Example Dental",
  "url": "https://www.example.com/locations/downtown/",
  "image": "https://www.example.com/images/downtown-office.jpg",
  "telephone": "+1-555-555-0100",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "125 Example Street",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 30.26720,
    "longitude": -97.74310
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday"
      ],
      "opens": "09:00",
      "closes": "17:00"
    }
  ]
}
</script>

Why use an @id?

@id is not one of Google’s required LocalBusiness properties.

It is useful because it gives the entity a stable identifier.

An Organization, WebPage, Article, Service, or another related entity can then reference that identifier rather than creating disconnected descriptions of the same business.

Important LocalBusiness Properties Explained

name

Use the genuine business name.

Do not append city names, service terms, slogans, or promotional keywords unless they are actually part of the business name.

address

Use PostalAddress and provide the relevant components:

• streetAddress
• addressLocality
• addressRegion
• postalCode
• addressCountry

The address should describe the location represented on the page.

telephone

Use a current phone number associated with the business or specific location.

For multiple locations, check whether location pages have their own numbers rather than automatically inserting one corporate phone number everywhere.

geo

GeoCoordinates provides the latitude and longitude of the physical location.

Google’s current LocalBusiness documentation asks for latitude and longitude with a precision of at least five decimal places.

Precision alone is not enough.

Verify that the coordinates actually point to the correct business location rather than trusting values copied from an old plugin, database, theme, or previous website.

openingHoursSpecification

Use this property to describe actual business hours.

Schema often becomes stale after businesses change:

• weekday hours;
• weekend hours;
• seasonal hours;
• holiday schedules;
• temporary closures.

If the visible page changes, update the structured data as part of the same process.

url

Use the URL that best represents the entity.

For a multi-location website, this will often be the corresponding location URL rather than the homepage.

sameAs

sameAs can identify URLs that clearly represent the same entity elsewhere.

Use it selectively.

Adding dozens of weak directories does not automatically create stronger entity understanding.

For a deeper explanation, see our entity optimization guide.

LocalBusiness vs Organization vs Service Schema

These types describe different entities or concepts.

A website can legitimately contain all three.

For example:

• one Organization can represent the company;
• separate LocalBusiness entities can represent individual physical branches;
• Service entities can describe services provided by the company or location.

The problem is not multiple schema types.

The problem is multiple disconnected or contradictory descriptions of the same entity.

LocalBusiness Schema for Service-Area Businesses

Service-area businesses need more careful modeling than ordinary storefront businesses.

A plumber, mobile cleaner, contractor, locksmith, or similar business may travel to customers and may not serve customers at its operating address.

Google Business Profile allows eligible service-area businesses to hide their street address from the public.

Website structured data is a separate system.

That does not mean a private address should be published invisibly in JSON-LD just to satisfy Google’s requirement.

Google’s general structured-data guidelines say markup should accurately represent page content and should not describe hidden or misleading content.

What should a true service-area business do?

If an operating address is deliberately private and is not displayed on the website, consider whether an Organization plus Service model describes the entity more honestly.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "Example Plumbing",
      "url": "https://www.example.com/",
      "telephone": "+1-555-555-0150"
    },
    {
      "@type": "Service",
      "@id": "https://www.example.com/plumbing/#service",
      "name": "Residential Plumbing",
      "provider": {
        "@id": "https://www.example.com/#organization"
      },
      "areaServed": [
        {
          "@type": "City",
          "name": "Austin"
        },
        {
          "@type": "City",
          "name": "Round Rock"
        }
      ]
    }
  ]
}
</script>

This is a Schema.org entity-modeling pattern.

It should not be interpreted as a promise that Google will show a LocalBusiness rich result.

If the company has a genuine customer-facing storefront and also travels to customers, LocalBusiness schema can represent the physical location while service coverage is modeled separately.

For page strategy, see our location and service-area pages guide.

LocalBusiness Schema for Multiple Locations

Each real business location should be treated as its own entity.

Do not use one generic LocalBusiness node to represent several unrelated addresses.

A cleaner multi-location structure

1. Create a useful page for each genuine business location.
2. Show the correct address, phone number, opening hours, and location information.
3. Add schema describing that specific location.
4. Give the location a stable @id.
5. Connect it to the parent organization when appropriate.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://www.example.com/locations/south-austin/#localbusiness",
  "name": "Example Dental",
  "url": "https://www.example.com/locations/south-austin/",
  "telephone": "+1-555-555-0185",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "900 Example Avenue",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78745",
    "addressCountry": "US"
  }
}
</script>

Do not automatically rename a location to something like “Example Dental South Austin” unless that is genuinely its business name.

The page heading, address, breadcrumb, location copy, and URL can establish geographic context without changing the entity name.

For location consistency, also review our NAP consistency guide.

How to Add LocalBusiness Schema in WordPress

WordPress often creates a different problem from manually coded sites: too many systems can generate schema at the same time.

Structured data may come from:

• Yoast SEO;
• Yoast Local SEO;
• Rank Math;
• another schema plugin;
• the WordPress theme;
• a page builder;
• custom PHP;
• a header/footer code tool;
• a tag-management implementation.

If you use Yoast

Check the structured-data graph Yoast already generates before adding another LocalBusiness node manually.

Determine whether the existing Organization or LocalBusiness entity already contains the relevant information and relationships.

If it does, extending or correcting the existing implementation is normally cleaner than inserting an unrelated second entity.

If you use Rank Math

Review the Local SEO and schema configuration, then inspect what Rank Math actually emits on the live page.

Do not assume the WordPress settings screen perfectly reflects the final rendered output.

If you use a dedicated schema plugin

Identify which system owns each important entity:

• Organization
• LocalBusiness
• WebSite
• WebPage
• Article
• BreadcrumbList
• Service

If you add JSON-LD manually

First inspect the existing source.

Search for:

application/ld+json

Then inspect each JSON-LD block.

Adding another business entity can create problems such as:

• different phone numbers;
• different addresses;
• old opening hours;
• different @type values;
• different URLs;
• multiple independent @id values describing the same business.

Where Should LocalBusiness Schema Go?

Use LocalBusiness schema on a page that genuinely describes the business or location being marked up.

For a single-location business, that may be:

• the homepage;
• a contact/location page;
• a dedicated business-location page.

For a multi-location website, the corresponding location page is usually the clearest place to describe that specific location.

Copying one identical LocalBusiness block across every page of a large website rarely creates additional useful meaning.

Should JSON-LD go in the head or body?

Google can process JSON-LD placed in the <head> or <body>.

The more important questions are:

• Can Google crawl the page?
• Can Google render the markup?
• Does the schema represent the page accurately?
• Is another tool generating conflicting markup?

How to Test LocalBusiness Schema Properly

Do not rely on one green checkmark.

There are several different questions to test.

1. Validate Schema.org vocabulary

Use the Schema.org Validator to inspect whether your structured data follows the Schema.org vocabulary and syntax.

2. Test Google’s supported structured data

Use Google’s Rich Results Test to see how Google interprets supported structured data on the page.

Schema.org Validator vs Rich Results Test

3. Test the live URL

Testing only a pasted code snippet can miss implementation problems introduced by:

• WordPress;
• JavaScript;
• caching;
• plugins;
• templates;
• server-side rendering.

After publishing, test the final URL.

4. Use Google Search Console URL Inspection

Check:

• indexability;
• canonical URL;
• rendered page;
• crawl status;
• whether an important update has been recrawled.

See our Google Search Console guide for a wider technical workflow.

Illustrative LocalBusiness Schema Audit Example

The following example is illustrative. It demonstrates the type of conflict an audit should look for and is not presented as a Search Counsel Co client case.

Visible business information

The location page shows:

• Phone: +1-555-555-0100
• Hours: Monday to Friday, 9 AM to 5 PM

Plugin A generates

{
  "@type": "Dentist",
  "@id": "https://example.com/location/#business",
  "telephone": "+1-555-555-0100"
}

Plugin B also generates

{
  "@type": "LocalBusiness",
  "@id": "https://example.com/#localbusiness",
  "telephone": "+1-555-555-0199"
}

The JSON itself may be syntactically valid.

The real problem is that the page now contains two business entities with different telephone numbers.

Audit workflow

1. Inspect every JSON-LD block in the rendered page.
2. Determine which plugin generates each entity.
3. Compare the schema values with visible page information.
4. Identify whether both nodes genuinely represent different entities.
5. If they describe the same entity, consolidate or disable the duplicate implementation.
6. Retest using Schema.org Validator.
7. Retest the live URL in Google’s Rich Results Test.
8. Inspect the URL through Google Search Console after publishing.

This is why structured-data audits should focus on entity consistency, not only validation errors.

Why Is My LocalBusiness Schema Valid but Not Showing in Google?

Valid schema and a visible Google search feature are not the same thing.

Google explicitly says that correct structured data does not guarantee a rich result.

A successful validator result is therefore part of QA, not proof that the SEO task is finished.

Common LocalBusiness Schema Errors

1. Keyword stuffing the business name

Use the real business name.

Schema is not a second SEO title field.

2. Using stale opening hours

If the page says 6 PM and the schema says 8 PM, update the schema.

3. Using incorrect geo coordinates

Check both precision and actual location.

A technically formatted coordinate that points to the wrong building is still wrong.

4. Publishing a private service-area address only in JSON-LD

Do not expose an intentionally private address merely to fill Google’s required address property.

5. Treating self-published ratings as automatic star eligibility

Google’s LocalBusiness documentation limits its recommended review and aggregate-rating use case to sites collecting reviews about other local businesses.

Do not add fake, misleading, or unsupported ratings.

6. Reusing the same location schema everywhere

Each genuine location should be represented by its own facts.

7. Generating duplicate business entities

Check plugins and themes before inserting manual JSON-LD.

8. Treating every Schema.org field as a Google requirement

Schema.org defines the vocabulary.

Google separately defines which structured data and properties it supports for particular search experiences.

9. Ignoring visible page quality

LocalBusiness schema cannot rescue a weak location page.

The page should still provide useful information about:

• the business;
• location;
• services;
• contact information;
• hours;
• what customers should expect.

LocalBusiness Schema vs Google Business Profile

They describe related business information, but they are separate systems.

Avoid contradictory information across the website and Business Profile.

That does not require blindly forcing every field into character-for-character duplication when the systems use different formatting.

The goal is a consistent, truthful representation of the same real business.

For related local signals, see our NAP consistency guide and local SEO guide.

Does LocalBusiness Schema Improve Local SEO Rankings?

Do not treat LocalBusiness schema as:

• a guaranteed Map Pack ranking factor;
• a shortcut to position one;
• a guaranteed knowledge panel trigger;
• a guaranteed rich-result trigger;
• a substitute for useful location pages;
• a substitute for Google Business Profile work;
• a replacement for relevance, prominence, links, reviews, or local authority.

Its practical value is entity clarity.

A clean structured-data graph can help machines understand:

• what the business is;
• which URL represents it;
• where the physical location is;
• which telephone number and hours belong to it;
• how a location relates to a broader organization;
• which services are connected to that entity.

That is useful without turning schema into an unsupported ranking claim.

What Matters Most for LocalBusiness Schema in 2026?

The strongest LocalBusiness implementation is not the one with the longest JSON-LD block.

It is the one with the least ambiguity.

Focus on:

• accurate business types;
• correct required and recommended fields;
• visible-content consistency;
• proper entity relationships;
• location-specific data;
• service-area privacy;
• duplicate WordPress schema;
• Schema.org validation;
• Google eligibility testing;
• ongoing maintenance after business changes.

Structured data can also make entities easier for machines to interpret, but no schema property guarantees that an AI system will cite or recommend a business.

That topic is covered separately in our schema for AI citations guide.

LocalBusiness Schema Implementation Checklist

Frequently Asked Questions

What is LocalBusiness schema?

LocalBusiness schema is structured data that uses Schema.org vocabulary to describe a physical local business or branch in a machine-readable form.

What properties are required for LocalBusiness schema?

Google currently lists name and address as required LocalBusiness properties. Other properties such as telephone, geo, url, openingHoursSpecification, and priceRange are recommended when applicable.

Does LocalBusiness schema improve rankings?

It does not guarantee higher rankings. It helps search engines understand structured business information and can make eligible content capable of participating in supported Google search experiences.

Should I use LocalBusiness or Organization schema?

Use LocalBusiness for an appropriate physical business or branch. Use Organization for the broader company or brand. Both can exist on the same website when they represent related but distinct entities.

Can I use more than one LocalBusiness type?

Yes. When multiple types genuinely apply, Google’s documentation supports using an array in @type.

Where should LocalBusiness schema be added?

Add it to a page that actually represents the business or location. For a multi-location site, the relevant location page is normally the clearest place for location-specific LocalBusiness markup.

Should LocalBusiness schema appear on every page?

Not automatically. Repeating the same LocalBusiness node across every page does not necessarily create additional useful information.

Can a service-area business use LocalBusiness schema without an address?

Markup without an address can still use Schema.org vocabulary, but it does not meet Google’s current documented required-property set for LocalBusiness. Do not publish a private street address only inside JSON-LD merely to satisfy that requirement.

What is areaServed?

areaServed is a Schema.org property used to describe the geographic area where an organization or service operates. It can be useful for entity modeling, but it does not guarantee higher local rankings.

Can I add aggregateRating to my own business?

Do not assume that adding your own business rating will create review stars. Google’s LocalBusiness documentation recommends aggregateRating and review for sites that collect reviews about other local businesses.

Why is my LocalBusiness schema valid but not showing?

Google does not guarantee a visible rich result simply because markup validates. Check indexing, page quality, visible-content consistency, duplicate schema, supported properties, recrawling, and Google’s current eligibility rules.

What is the difference between Schema.org Validator and Rich Results Test?

Schema.org Validator checks the structured data against Schema.org vocabulary. Google’s Rich Results Test focuses on structured data Google supports for its search experiences. Passing one test does not automatically guarantee success in the other or a visible Google result.

Is JSON-LD better than Microdata?

Google supports JSON-LD, Microdata, and RDFa, but recommends JSON-LD. JSON-LD is also often easier to maintain because it can be managed without embedding individual schema attributes throughout visible HTML.

How do I test LocalBusiness schema?

Check the markup with Schema.org Validator, test the live URL with Google’s Rich Results Test, inspect the final rendered source for duplicates, and use Google Search Console URL Inspection after important changes.

What is the difference between LocalBusiness schema and Google Business Profile?

LocalBusiness schema is structured data placed on a website. Google Business Profile is Google’s system for managing business information in Search and Maps. They are related but separate systems.

Primary Sources

This guide separates Google requirements, Schema.org vocabulary, and implementation recommendations wherever possible.

• Google Search Central: Local Business structured data
• Google Search Central: General structured data guidelines
• Google Search Central: Organization structured data
• Schema.org Validator
• Schema.org: LocalBusiness
• Google Rich Results Test
• Google Business Profile: Service-area guidance

Editorial Method

Structured-data guidance can change independently of the underlying Schema.org vocabulary.

For that reason, we use three separate questions when reviewing a LocalBusiness implementation:

1. Is the markup valid Schema.org vocabulary?
2. Does it satisfy Google’s current documented requirements for the intended search feature?
3. Does it accurately represent what users can see on the page?

A strong implementation should answer all three.

September 2026 Update Notes

This guide was rechecked against current LocalBusiness and structured-data documentation in September 2026.

The update:

• clarified Google’s required versus recommended properties;
• added multiple-@type guidance;
• added geo-coordinate precision guidance;
• expanded service-area business treatment;
• expanded WordPress, Yoast, and Rank Math troubleshooting;
• separated Schema.org validation from Google Rich Results testing;
• expanded multi-location schema guidance;
• added a structured-data audit workflow;
• removed unsupported ranking guarantees;
• clarified review and aggregate-rating limitations;
• expanded troubleshooting for valid schema that does not produce a visible Google search feature.