LocalBusiness JSON-LD: Build a Clear Identity for Every Business Location

Schema.org JSON-LD helps search engines understand which business a page describes, where it operates and how customers can contact it. For local businesses, the foundation is a correctly defined LocalBusiness entity.

The objective is not to add as many schema properties as possible. It is to publish a consistent, verifiable description of the business that matches the website and its real-world details.

Correct markup can support search engines’ understanding and eligibility for supported search features. It does not guarantee rankings, rich results or citations in AI-generated answers.

What does LocalBusiness schema describe?

LocalBusiness is a Schema.org type for a particular physical business or branch. It combines characteristics of an organisation and a place.

Use it to describe facts such as:

• Business name and canonical website URL.
• Physical address and telephone number.
• Opening hours.
• Geographic coordinates.
• Official profiles associated with that business.

JSON-LD is the format used to express those facts in a structured script. Visitors read the page; systems that process structured data can also read its machine-readable description.

LocalBusiness markup should describe the business shown on the page, not a separate version created for search engines.

Choose the most specific accurate type

Use a specific subtype when it genuinely describes the business. Examples include Dentist, Restaurant, Electrician and AutoRepair.

A dental practice should generally use Dentist rather than stopping at the broader LocalBusiness type. The more specific type communicates the business category more precisely.

Do not choose a type because it appears commercially attractive. Schema describes what the business is, not which keywords it wants to rank for.

For a company with multiple branches, distinguish the overall organisation from its individual locations. Each branch should have its own entity and location-specific information.

A practical LocalBusiness JSON-LD example

The following example uses fictional placeholder details. Replace every value before publishing, and include only information that accurately describes the business and is supported by the page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Electrician",
  "@id": "https://example.com/locations/ghent/#business",
  "name": "Example Electrical",
  "url": "https://example.com/locations/ghent/",
  "telephone": "+3290000000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Example Street 10",
    "postalCode": "9000",
    "addressLocality": "Ghent",
    "addressCountry": "BE"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "https://schema.org/Monday",
        "https://schema.org/Tuesday",
        "https://schema.org/Wednesday",
        "https://schema.org/Thursday",
        "https://schema.org/Friday"
      ],
      "opens": "08:00",
      "closes": "17:00"
    }
  ]
}
</script>

This is a starting point, not a universal checklist for every search feature. Search engines maintain their own requirements and recommendations, which may differ from basic Schema.org validity.

Use @id to keep business identity consistent

The @id property gives an entity a stable identifier. It helps connect references to the same business across your structured data.

For a single-location business, choose one stable identifier and reuse it whenever that business is referenced. Do not generate a new business identity for every service page.

For multiple locations:

• Give each branch a unique @id.
• Use a dedicated URL for each location.
• Publish that branch’s address, telephone number and hours.
• Connect branches to the parent organisation where appropriate.

A service page can reference an existing business entity instead of creating another disconnected copy.

One business location should have one consistent identity, even when several pages mention it.

Match schema to visible business information

Structured data should agree with the information customers can read on your website.

Check names, addresses, telephone numbers and opening hours against the relevant location page and Google Business Profile. Different formatting is not necessarily a problem, but conflicting facts are.

Pay particular attention to:

• Holiday hours and temporary closures.
• Relocated branches.
• Central telephone numbers versus branch numbers.
• Appointment-only availability.
• Old addresses left behind by plugins.

For service-area businesses, do not invent a storefront or publish a private address simply to populate schema. areaServed can describe coverage, but it does not replace address requirements for search features that require one.

Avoid markup that overstates trust

Add sameAs links only when they identify the same business, such as its official social profiles. They are identity references, not a list of websites where you want backlinks.

Reviews require similar care. Never fabricate ratings or copy third-party review totals into markup without checking the applicable rules.

Google does not show self-serving review snippets for LocalBusiness or Organization entities. Adding aggregateRating to your own business page does not bypass that policy.

For GEO and AEO, accurate entity information is a useful foundation. There is no established rule that adding LocalBusiness JSON-LD makes an AI assistant cite your website.

Validate the deployed page, not just the code

A syntactically correct snippet can still describe the wrong location or conflict with existing markup.

Use this deployment checklist:

1. Inventory existing schema. Check themes, plugins, tag managers and custom scripts.
2. Validate vocabulary and syntax. Use the Schema Markup Validator.
3. Check Google-specific eligibility. Use Google’s Rich Results Test for supported features.
4. Inspect the rendered page. Confirm that dynamically injected markup is accessible.
5. Review factual accuracy. Compare schema with visible business details.
6. Monitor changes. Recheck after website updates or business information changes.

JavaScript-injected JSON-LD can be processed by Google, but crawler capabilities vary. Do not assume every AI crawler renders JavaScript.

How GeoEngine supports schema maintenance

GeoEngine is a Belgian B2B SaaS GEO and AI toolkit for SMEs and marketing agencies.

Its lightweight tag dynamically injects page-specific Schema.org JSON-LD without modifying the source code. Daily technical monitoring and schema Auto-Healing support ongoing maintenance. GeoEngine also provides sitemap synchronisation and IndexNow pings to search engines.

Automation does not replace accurate business inputs or deployment checks. GeoEngine does not guarantee rankings or AI citations.

Frequently asked questions

Should LocalBusiness schema appear on every page?

Not necessarily. Prioritise pages that describe the business or a specific location. Elsewhere, reference the same entity consistently when relevant.

Can multiple branches share one LocalBusiness entity?

Each physical branch should generally have its own entity, identifier and location details. A separate parent organisation can connect them.

Does valid schema guarantee a rich result?

No. Validity, feature eligibility and actual display are different things. Search engines decide whether to show enhanced results.

Is JSON-LD enough for AI visibility?

No. It complements accessible content, consistent business information and technical discoverability. It does not guarantee that AI systems will retrieve or cite a page.

For a starting assessment, explore the free GEO scan at geoengine.tech.