Local Business Schema: How to Use Local Schema Markup for Cleaner Local SEO

LocalBusiness is a Schema.org type used to describe a physical business, branch, or local organization. It sits underneath the broader Place and Organization types in the Schema.org hierarchy and has dozens of more specific subtypes beneath it, covering dentists, restaurants, lawyers, plumbers, auto repair shops, and many more.

When implemented correctly, LocalBusiness schema can include:

• business name, URL, logo, and description
• address, phone number, and map link
• geographic coordinates
• opening hours by day and holiday exceptions
• service areas for businesses that travel to customers
• reviews and aggregate ratings where visible and compliant
• departments where genuinely applicable
• sameAs links to official profiles
• service offerings and offer catalogs
• parent organization or branch relationships

Google can use structured data to understand page content and may surface eligible markup in search features, but structured data does not guarantee rich results or ranking improvements. Google's own documentation is direct on this point: structured data helps Google understand what a page is about, not that it deserves to rank.

LocalBusiness schema is not a replacement for Google Business Profile optimization, local citations, reviews, links, or local landing page proof. It is the structured layer that helps tie those assets together into a coherent entity signal.

LocalBusiness schema should usually be added in JSON-LD format because it is easier to manage, audit, and update than microdata embedded throughout the HTML. Google recommends JSON-LD for structured data implementation, and it is the format used in all examples on this page.

Yes, but not in the way most local schema articles describe.

Schema can help by clarifying the business entity so search engines understand who the business is and what it does. It supports NAP consistency when the markup matches what appears on the page and in the GBP.

It helps Google understand service and location relationships, particularly for multi-location businesses and service area businesses where the page structure can be ambiguous. It makes opening hours, contact information, and service areas machine-readable.

It connects official profiles through sameAs. And it supports eligibility for search features where Google has defined specific structured data requirements.

Schema cannot move a business closer to the searcher. It cannot create a real location or compensate for fake NAP. It will not outrank stronger competitors by itself, fix weak GBP categories, replace reviews or links, or turn thin city pages into strong pages. It does not guarantee rich results regardless of how complete the markup is.

Schema is a support signal. If the underlying entity is weak, schema mostly helps Google understand a weak entity faster.

If a local business has no schema at all but also has weak reviews, poor GBP categories, thin service pages, and no local links, schema is not the first fix.

The businesses that benefit most from careful schema implementation are multi-location companies with complex page architectures, service area businesses whose pages need to clarify coverage without implying fake physical presence, and businesses where the GBP, website, and citation data have inconsistencies that schema can help bridge.

For a single-location business with clean NAP and a well-optimized GBP, schema is still worth doing correctly, but it is unlikely to be the limiting ranking factor.

Local SEO ranking factors cover proximity, prominence, and relevance as the primary signals. Schema supports the relevance and entity clarity layer, but it does not override the other two.

Most local schema guides treat these as interchangeable. They are not.

Organization schema describes the broader company or brand. LocalBusiness schema describes a specific local business location or branch. Multi-location sites typically need both, but they should not be combined carelessly.

The question is not "which schema type ranks better?" The question is "which entity does this page actually represent?"

The most common mistake: applying the same LocalBusiness entity with the corporate address to every page on a multi-location site.

That tells Google the entire site represents a single location, which conflicts with the actual architecture and creates entity confusion rather than clarity.

A franchise with twenty locations needs Organization schema for the brand homepage and distinct LocalBusiness entities for each location page, with their own addresses, phone numbers, opening hours, and geographic coordinates.

The brand entity and the location entities are related but not identical.

For a single-location business, you may not need separate Organization and LocalBusiness entities if they describe the same real-world entity. If both are used, connect them cleanly with stable @id values and avoid duplicating contradictory names, URLs, logos, or contact data.

The decision order:

1. Use the most specific valid Schema.org subtype available for the business type.
2. If no perfect subtype exists, use the closest valid parent type.
3. Use visible page content, Service schema, and additionalType to clarify what the business actually does.
4. Do not use invalid or invented schema types.
5. Do not stack multiple subtypes because they all "sound relevant."

Schema.org defines LocalBusiness as a physical business or branch of an organization, with many more specific subtype options underneath it. Using a more specific type is better than defaulting to the generic LocalBusiness type when a valid subtype exists. The table below lists suggested types, subject to validation against Schema.org and Google's supported structured data documentation before implementation.

Not every real-world business category has a perfect Schema.org subtype. When there is no exact match, use the closest valid parent type, then use Service schema, additionalType, and visible page copy to clarify. Do not invent types that Schema.org does not define.

Local schema is not a single block of code. It is a stack of related entities that describe the business, its location, its services, the current page, and its trust signals. Each layer has a job.

1. Entity Schema

Defines who the business is:

• @type with the most specific valid subtype
• @id as a stable, canonical identifier for the entity
• name matching the business name in GBP and citations
• url pointing to the canonical business URL
• logo and image
• telephone matching GBP and citations exactly
• sameAs linking to official profiles only
• description short, factual, and matching visible page content
• parentOrganization where the business is a branch or franchise location
• foundingDate where relevant and accurate

2. Location Schema

Defines where the business operates:

• address with PostalAddress including streetAddress, addressLocality, addressRegion, postalCode, addressCountry
• geo with GeoCoordinates latitude and longitude
• hasMap linking to the GBP map URL
• openingHoursSpecification with day, opens, closes for each day
• branchOf where applicable
• department only for genuinely distinct operational departments with separate staff, hours, and phone numbers

3. Service Schema

Defines what the business offers:

• Service type with name, description, provider, and areaServed
• serviceType or category where appropriate
• url pointing to the relevant service page
• areaServed describing real coverage

4. Page Schema

Defines what the current URL represents:

• WebPage as the base type
• AboutPage for about pages
• ContactPage for contact pages
• BreadcrumbList for navigation hierarchy
• WebPage as the page entity on service pages, with Service schema used separately to describe the service offered on that page

5. Trust Schema

Only when visible and compliant:

• Review with compliant first-party reviews visible on the page
• AggregateRating only when the rating is visible and the count is accurate
• awards, certifications, and association memberships where accurate and visible

Note: sameAs belongs to the entity layer, but it also supports trust when it points to official, authoritative profiles. It appears in entity schema because that is where it is most commonly needed, but its trust value comes from the quality and consistency of the profiles it links to.

The win is not adding more schema. The win is making the page, business, service, location, and external entity footprint agree with each other.

For most local businesses, this is the minimum useful implementation. Minimum useful properties are not the same as required properties for every rich result or every business type. Required and recommended properties vary by eligibility feature, business model, and page purpose.

• @context set to https://schema.org
• @type with the specific business subtype
• @id as a stable URL-based identifier
• name matching GBP and citations exactly
• url for the canonical business or location URL
• telephone in consistent format across GBP and citations
• address as a PostalAddress object
• image showing the business or location
• logo as an ImageObject
• openingHoursSpecification covering all operating days
• sameAs with official profile URLs only
• hasMap with the GBP map link
• geo with accurate coordinates
• areaServed for service area businesses
• description that is short, factual, and visible on the page
• priceRange where relevant and accurate

Google's structured data guidelines are explicit that markup must represent the main content of the page, must be visible to users, and must not be misleading. Marking up information that exists only in JSON-LD and not on the page is a policy violation.

Marking up incorrect addresses, fake phone numbers, or exaggerated service areas is a policy violation. If the only place a fact exists is inside JSON-LD, it probably should not be there.

Schema should match the purpose of the page it is on. Dropping the same LocalBusiness entity across every page template regardless of content is a common mistake that creates entity noise rather than entity clarity.

City pages and service area pages should not carry LocalBusiness schema with a fake address for the city being targeted. Using WebPage, Service, and areaServed on those pages accurately describes their purpose without implying a physical location that does not exist.

Schema should reinforce the same business entity shown in your GBP and citations, not manufacture local presence that the operational reality does not support.

Schema supports local relevance, but it does not override proximity in the local pack. City pages should prove service-city relevance without pretending to be physical locations.

The examples below are templates, not universal code. Replace every placeholder with real business data, remove any property that is not visible or accurate, and validate the final output before publishing. Schema should be customized by page type, not pasted across the entire site.

1. Single-Location Local Business

1. Single-location local business Use this when the business has one real physical address and the page is the homepage or primary location page.

{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "@id": "https://example.com/#localbusiness",
  "name": "Example Plumbing Co.",
  "url": "https://example.com",
  "telephone": "+1-214-555-0100",
  "image": "https://example.com/images/storefront.jpg",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/images/logo.png"
  },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Dallas",
    "addressRegion": "TX",
    "postalCode": "75201",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 32.7767,
    "longitude": -96.7970
  },
  "hasMap": "https://maps.google.com/?cid=YOURGBPCID",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "07:00",
      "closes": "18:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "08:00",
      "closes": "14:00"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/exampleplumbing",
    "https://www.yelp.com/biz/example-plumbing-dallas"
  ],
  "priceRange": "$$",
  "description": "Licensed residential and commercial plumber serving Dallas."
}

Do not use this on every page. Do not place it on city pages or service area pages to imply a physical address in the target area. Match the telephone and address exactly to what appears in GBP and on citations.

2. Service Area Business Schema

2. Service area business schema Use this when the business travels to customers and hides its address in GBP.

{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "@id": "https://example.com/#localbusiness",
  "name": "Example Plumbing Co.",
  "url": "https://example.com",
  "telephone": "+1-214-555-0100",
  "image": "https://example.com/images/team.jpg",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/images/logo.png"
  },
  "areaServed": [
    { "@type": "City", "name": "Dallas" },
    { "@type": "City", "name": "Plano" },
    { "@type": "City", "name": "Frisco" }
  ],
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
      "opens": "07:00",
      "closes": "20:00"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/exampleplumbing"
  ],
  "description": "Licensed plumber serving Dallas, Plano, Frisco, and surrounding areas."
}

The address field is omitted when the business hides its address as a true SAB. If the business has a real address but serves customers at their locations, include the address and add {

areaServed. Do not fabricate an address for any city in the areaServed list. areaServed should match real service coverage, not a fantasy expansion map.

3. Multi-Location Brand Homepage Schema

3. Multi-location brand homepage schema Use this when the business has multiple real locations and the homepage represents the brand, not a single branch.

Each location page should carry a distinct LocalBusiness entity with its own @id, NAP, coordinates, hours, and map link, linked to the parent organization using parentOrganization. Do not use this as the only schema on the site. It represents the brand, not the locations.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Plumbing Co.",
  "url": "https://example.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/images/logo.png"
  },
  "sameAs": [
    "https://www.facebook.com/exampleplumbing",
    "https://www.linkedin.com/company/example-plumbing"
  ],
  "description": "Licensed plumbing company with locations across the Dallas-Fort Worth area."
}

4. Individual Location Page Schema

4. Individual location page schema Use this on a page that represents one specific real physical branch.

{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "@id": "https://example.com/locations/dallas/#localbusiness",
  "name": "Example Plumbing Co. - Dallas",
  "url": "https://example.com/locations/dallas/",
  "telephone": "+1-214-555-0101",
  "parentOrganization": {
    "@type": "Organization",
    "@id": "https://example.com/#organization"
  },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "456 Commerce Street",
    "addressLocality": "Dallas",
    "addressRegion": "TX",
    "postalCode": "75202",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 32.7801,
    "longitude": -96.8003
  },
  "hasMap": "https://maps.google.com/?cid=DALLASLOCGBPCID",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "07:00",
      "closes": "18:00"
    }
  ]
}

Each location page gets its own @id. The address, phone, coordinates, and hours should reflect that specific branch, not the corporate entity. Do not copy the same schema across every location page with different city names swapped in.

5. Service Page Schema

5. Service page schema Use this on a page dedicated to a specific service offering.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Emergency Plumbing Repair",
  "serviceType": "Emergency Plumbing",
  "provider": {
    "@type": "Plumber",
    "@id": "https://example.com/#localbusiness"
  },
  "areaServed": {
    "@type": "City",
    "name": "Dallas"
  },
  "url": "https://example.com/services/emergency-plumbing/"
}

The service page is about a service. The provider is the local business, referenced by its stable @id. Do not mark every service page as a separate LocalBusiness entity. Do not add a fake address to service pages.

6. BreadcrumbList Schema

6. BreadcrumbList schema Use this on any page within a hierarchical site architecture to clarify page relationships and navigation context.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com" },
    { "@type": "ListItem", "position": 2, "name": "Locations", "item": "https://example.com/locations/" },
    { "@type": "ListItem", "position": 3, "name": "Dallas", "item": "https://example.com/locations/dallas/" }
  ]
}

BreadcrumbList can also work for service hierarchies: Home > Services > Emergency Plumbing. Use it on location pages, city pages, service pages, and service area pages to make page relationships explicit. It helps both users and search engines understand where the page sits in the site architecture.

7. Combined @graph Example: LocalBusiness + Service + WebPage

7. Combined @graph example: LocalBusiness + Service + WebPage This is the correct way to combine multiple schema entities on a single page. Using @graph ties them together as related entities rather than disconnected blocks of code. Use this on a location-specific service page, such as /locations/dallas/emergency-plumbing/.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Plumber",
      "@id": "https://example.com/locations/dallas/#localbusiness",
      "name": "Example Plumbing Co. - Dallas",
      "url": "https://example.com/locations/dallas/",
      "telephone": "+1-214-555-0101",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "456 Commerce Street",
        "addressLocality": "Dallas",
        "addressRegion": "TX",
        "postalCode": "75202",
        "addressCountry": "US"
      },
      "geo": {
        "@type": "GeoCoordinates",
        "latitude": 32.7801,
        "longitude": -96.8003
      },
      "openingHoursSpecification": [
        {
          "@type": "OpeningHoursSpecification",
          "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
          "opens": "07:00",
          "closes": "18:00"
        }
      ]
    },
    {
      "@type": "Service",
      "@id": "https://example.com/locations/dallas/emergency-plumbing/#service",
      "name": "Emergency Plumbing Repair - Dallas",
      "serviceType": "Emergency Plumbing",
      "provider": { "@id": "https://example.com/locations/dallas/#localbusiness" },
      "areaServed": { "@type": "City", "name": "Dallas" },
      "url": "https://example.com/locations/dallas/emergency-plumbing/"
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/locations/dallas/emergency-plumbing/#webpage",
      "url": "https://example.com/locations/dallas/emergency-plumbing/",
      "name": "Emergency Plumber Dallas | Example Plumbing Co.",
      "isPartOf": { "@id": "https://example.com/#website" },
      "about": { "@id": "https://example.com/locations/dallas/emergency-plumbing/#service" },
      "breadcrumb": {
        "@type": "BreadcrumbList",
        "itemListElement": [
          { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com" },
          { "@type": "ListItem", "position": 2, "name": "Dallas", "item": "https://example.com/locations/dallas/" },
          { "@type": "ListItem", "position": 3, "name": "Emergency Plumbing", "item": "https://example.com/locations/dallas/emergency-plumbing/" }
        ]
      }
    }
  ]
}

The @graph approach lets Google read all three entities and their relationships from a single JSON-LD block. Each entity has its own @id, and the provider, about, and isPartOf "url":"https://example.com/locations/dallas/emergency-plumbing/"

references connect them explicitly. This is cleaner than three disconnected schema blocks on the same page. Do not use @graph as an excuse to add every possible entity type to every page. The graph should only include entities that the page actually represents.

8. AggregateRating Schema

8. AggregateRating schema Use this only when the aggregate rating is visible on the page and accurately reflects real, compliant reviews.

{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "@id": "https://example.com/#localbusiness",
  "name": "Example Plumbing Co.",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "214",
    "bestRating": "5",
    "worstRating": "1"
  }
}

The rating value and review count must match what is visibly displayed on the page. Marking up a rating that users cannot see, or inflating the count, is a policy violation. Local reviews should be displayed and attributed correctly before adding aggregateRating markup.

Do not use this as a standalone schema block if the page does not visibly show a rating widget or review list. Do not import this rating from a third-party platform and mark it up as if it is a first-party display.

Use Stable @id Values

Every business entity should have a stable @id, typically the canonical business or location URL with a consistent fragment identifier. For a single-location business:

https://example.com/#localbusiness. For a location in a multi-location architecture: https://example.com/locations/dallas/#localbusiness. Stable @id values connect repeated mentions of the same entity across pages, help avoid entity duplication in Google's knowledge graph, support cleaner multi-location architecture, and make schema graphs easier to audit.

Match Schema to Visible Content

Schema should describe what the page shows. If the JSON-LD claims the business is open 24 hours but the page shows 7am to 6pm, the markup conflicts with visible content. If the schema lists ten services but the page only covers three, Google faces contradictory signals.

If the aggregateRating shows 500 reviews but the page displays none, that is a policy violation. The test is simple: if the only place a fact exists is inside JSON-LD, it probably should not be there.

Use SameAs for Entity Reinforcement, Not Citation Stuffing

The sameAs property links the business entity to official profiles on other platforms.

Use it for official profiles with stable public URLs: Facebook, LinkedIn, Instagram, YouTube, Yelp where relevant, BBB where relevant, industry association profiles, and a Google Maps or GBP URL where it is stable and appropriate.

Do not stuff low-quality directory links into sameAs. The goal is to connect the entity to authoritative, consistent representations of the same business, not to manufacture signals through structured data.

AreaServed Should Describe Operational Reality

For service area businesses, areaServed should reflect real service coverage. It should align with the service area pages that already exist and the operational capacity the business actually has.

Do not list every city in the metro because the business could theoretically drive there. A service area page does not create service coverage, and schema should not pretend it does either.

This point connects directly to the entity consistency principle that runs through local citations and GBP: the business entity should describe the same thing everywhere it appears.

Multi-Location Schema Should Be Page-Specific

Homepage: Organization or parent LocalBusiness entity, linking to location pages. Do not dump every branch's full schema globally unless there is a specific technical reason.

Location page: one specific LocalBusiness entity with its own NAP, coordinates, hours, map link, and where possible its own proof, staff, and reviews. City page or service area page: WebPage, Service, areaServed, and BreadcrumbList.

Never imply a physical location where none exists. This matches the positioning in the city pages and service area pages satellites: schema should not manufacture local presence that the operational reality does not support.

Department Schema Requires Real Departments

The department property is for genuinely distinct operational departments with separate staff, separate phone numbers, and often separate addresses or hours. A law firm with separate litigation and estate planning departments with distinct teams and contact points may use it.

A plumbing company that offers both residential and commercial service but answers the same phone number is not two departments.

Using fake departments to create entity signals for services or locations that are not operationally distinct is the schema equivalent of fake GBP locations. It creates noise, not clarity.

Most WordPress sites implement local schema through an SEO plugin. Yoast SEO, Rank Math, and similar plugins include local schema features, but plugin output varies in quality and often requires manual review.

Common plugin problems to audit:

• outputting LocalBusiness schema on every page including blog posts and service pages where it does not belong
• using generic LocalBusiness type when a more specific subtype fits
• missing or unstable @id values
• no areaServed for service area businesses
• aggregateRating markup without visible review data
• duplicate schema from multiple active plugins
• schema that does not update when business hours or addresses change

The fix is not always turning off the plugin. It is auditing what the plugin outputs across page templates and either configuring it correctly or supplementing with custom JSON-LD where the plugin falls short. Validate output with Google's Rich Results Test and the Schema Markup Validator before and after any plugin changes.

For WordPress sites, check schema output at the template level, not just the homepage. Test the homepage, one service page, one location page, one blog post, one city page, and one service area page. Most schema problems are template problems, not single-page problems.

Schema should have one source of truth. If the SEO plugin, theme, local SEO plugin, review plugin, and custom code all output structured data, audit which layer owns which entity. Duplicate schema is not automatically bad, but conflicting schema is.

Use this to decide what schema belongs on each page before writing a single line of JSON-LD.

• Is this the homepage? Single location: LocalBusiness subtype plus Organization. Multi-location: Organization only at brand level, linking to location entities.
• Is this a real location page with a physical address? Yes: specific LocalBusiness subtype with full NAP, hours, coordinates, and map. No: do not use LocalBusiness with a fake address.
• Is this a service page? Use Service schema with provider relationship to the LocalBusiness entity. Do not create a separate LocalBusiness for the service.
• Is this a city page or service area page? Use WebPage, Service, areaServed, and BreadcrumbList. Do not imply a physical location.
• Are reviews visible on the page? Yes, first-party and accurate: Review or AggregateRating where compliant. No: do not add review markup.
• Is this an about page or contact page? Use the relevant WebPage subtype (AboutPage or ContactPage) and reference the correct business entity rather than creating a new LocalBusiness entity on each page.
• Is the business multi-location? Each location page gets a distinct LocalBusiness entity. The homepage gets Organization.
• Is the business a true SAB with hidden address? Use LocalBusiness subtype without address, with areaServed reflecting real coverage.

Passing validation only means the syntax works. It does not mean the strategy is correct. A schema graph can validate perfectly and still describe a business that does not exist, a location the business does not occupy, or services the page does not discuss.

Before publishing or after any schema change, run through this list.

Entity Accuracy

• Does the schema @type match the actual business category?
• Does the name match GBP and all major citations exactly?
• Is the @id stable and consistent across pages?
• Does the address match GBP and citations?
• Does the phone number match GBP and citations?
• Are coordinates accurate?
• Are opening hours current and accurate?

Page Match

• Does the schema describe what this specific page is about?
• Is every marked-up fact visible somewhere on the page?
• Is the schema placed on the correct page type?
• Is there any schema from other page templates that does not belong here?

Service Area and Coverage

• Does areaServed reflect real operational coverage?
• Are service areas consistent with service area pages already published?
• Is there any fake address for a city the business does not have an office in?

Reviews and Ratings

• Is aggregateRating only present where ratings are visible on the page?
• Do the rating value and review count match what is displayed?
• Are reviews first-party or appropriately attributed?

Technical

• Is there duplicate schema from multiple plugins?
• Are sameAs links pointing to official, accurate profiles?
• Does the schema validate in Google's Rich Results Test?
• Does Search Console show structured data errors or warnings?

After Indexing

• Does the Search Console Enhancements report show issues?
• Is the entity being understood correctly in any Knowledge Panel features?
• Does the schema conflict with anything visible in GBP?
• Does each page template output the correct schema for that page type?
• Has schema been checked after publishing, not just in staging?
• Does the schema match what a user would see in GBP, Apple Maps, Bing Places, and major
• citations?

Schema that is never updated becomes a liability. Update local business schema whenever the business changes any of the following:

• address
• phone number
• opening hours
• service area coverage
• primary business category
• location page URL
• logo
• business name
• departments
• review or rating display on the page
• location opening or closure

Schema changes should be treated the same as GBP and citation updates. When any of the three changes, the others should be reviewed for consistency. A local SEO audit should include a schema audit that checks output by page template, identifies conflicts between schema and visible content, flags fake address or fake location signals, and compares NAP consistency across schema, GBP, and citations.