structured data

LocalBusiness schema audit: 12 checks before publishing

A practical audit for local-business JSON-LD covering facts, identity, plugin conflicts, feature eligibility, served output, and monitoring.

Published 2026-08-26 · Updated 2026-09-19

A LocalBusiness graph can parse perfectly and still be unsafe to publish.

The most serious problems are often not missing commas. They are wrong facts, duplicate identities, hidden conflicts, unsupported ratings, or markup that never reaches the served page. Use this checklist before publishing or approving a local-business implementation, then browse the related structured-data resource library.

1. Confirm the business entity the page actually describes

Decide whether the page represents the whole organization, one location, or a service page. A multi-location brand should not make every location page the same undifferentiated LocalBusiness entity.

2. Choose the most specific supported subtype without forcing it

Schema.org includes LocalBusiness subtypes such as Plumber. Use a specific subtype when the business really is that type. Do not pick a narrower category solely because it sounds commercially useful.

3. Give the entity a stable @id

An @id should identify the same business or location across pages and versions. It should not change because the display name, tracking parameters, or page order changed.

4. Match the visible business name

Do not put keyword-stuffed or alternate names into structured data when the visible page and verified business identity do not support them. Record the legal and brand distinction explicitly when both are real and visible.

5. Verify phone, address, and service-area treatment

Phone and address are high-impact business facts. Confirm them from an authorized integration, customer approval, or clear visible content. For service-area businesses, do not expose a private address just to complete a schema field.

6. Verify opening hours from a current source

Hours change. Holiday exceptions exist. If the page, customer, and business profile disagree, pause instead of choosing silently. Store the source and review date.

7. Do not fabricate ratings or reviews

Ratings must come from real reviews and follow the applicable platform and Google feature policies. A local business should not add a self-serving aggregate rating merely to produce stars.

8. Check for competing graphs

WordPress themes, Yoast, Rank Math, ecommerce plugins, page builders, and custom snippets can all emit JSON-LD. Inventory every block before adding another. Two syntactically valid graphs can still create conflicting business identities.

9. Link site and page entities coherently

Organization or LocalBusiness, WebSite, WebPage, BreadcrumbList, and any page-specific entity should use stable references rather than repeat disconnected copies of the same facts.

10. Apply the right validation layer

Run JSON parsing and Schema.org vocabulary checks. Then apply a Google feature guide only if that feature and page type are relevant. A tool should not report every optional Schema.org property as a Google error.

11. Inspect the served page

Do not stop at the editor, plugin preview, or source template. Fetch the production URL, account for caching and client-side delivery, and confirm that the approved graph is what a visitor and crawler can receive.

12. Define the next check and rollback path

Record the content hash, validation ruleset, publication time, responsible owner, and last-known-good version. Decide what happens if the graph disappears, conflicts with new origin markup, or no longer matches visible content.

A useful audit report separates evidence from advice

For every issue, show:

  • what was observed;
  • where it was observed;
  • why it matters at the selected validation layer;
  • the proposed change;
  • any fact that still needs confirmation;
  • whether the issue blocks publication or is advisory;
  • the validation and served-output result after the change.

Avoid one opaque “schema score.” A score can hide the difference between a harmless optional property and a wrong phone number.

SEO Nori applies this operating model to the public pages it scans. It does not make a change during the free scan, and it does not fill missing business facts with guesses.

Check your own site evidence

Run the public scan to see observed structured-data gaps. The scan does not change your website.

Check my website