LocalBusiness structured data step by step: JSON-LD for a small business and how to test it

Step 1 — pick a type, not just "LocalBusiness"

LocalBusiness in schema.org has more specific subtypes, including HealthAndBeautyBusiness, HomeAndConstructionBusiness, LegalService, LodgingBusiness, MedicalBusiness and ProfessionalService (Schema.org, LocalBusiness). The more precise the type, the less ambiguous the description of what the business actually does.

When none of the subtypes fits exactly, the general LocalBusiness type remains a valid, accepted choice — just a less precise one.

Step 2 — gather the facts into one table before writing any code

Before a single curly brace appears, it's worth writing down, in one place, exactly the data that's already public anyway: the business name, identical to the one on the sign and in the Google listing, the address, the phone number in international format, the website URL, opening hours by day of the week, and an approximate price range. The rule is simple: the code should carry the same data visible on the site and in the Google listing — the name in the listing should match the real business name, and the listing also shows the address or service area, opening hours, and category (Google, guidelines for representing your business). Keeping the listing itself — its categories and hours — in order is a separate job, handled by Google Business Profile.

If any of this data is missing from the visible page — say, opening hours — add it to the visible content first, and only then to the code. Structured data is meant to reflect content visible to users, not replace it or run ahead of it.

Step 3 — the JSON-LD code, on an example

The block below is an example built on made-up numbers — the brackets and fields themselves are real and match Google's documentation, but the name, address and phone number are invented and serve only as a template to fill in with your own data:

{
  "@context": "https://schema.org",
  "@type": "HomeAndConstructionBusiness",
  "name": "Example Renovation Company",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Example Street",
    "addressLocality": "Warsaw",
    "postalCode": "00-001",
    "addressCountry": "PL"
  },
  "telephone": "+48123456789",
  "url": "https://example.com",
  "priceRange": "$$",
  "openingHoursSpecification": [
    { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"], "opens": "08:00", "closes": "16:00" },
    { "@type": "OpeningHoursSpecification", "dayOfWeek": "Saturday", "opens": "09:00", "closes": "13:00" }
  ]
}

The priceRange field — an approximate price range — appears in Google's own examples right next to the phone number and hours, as one of the recommended properties (Google Search Central, LocalBusiness). Change @type to the exact subtype from the table above, and replace the rest of the fields with your own data from the facts table.

Different hours by day, a lunch break, and Saturday

When hours differ by day — one schedule on weekdays, another on Saturday, a lunch break in the middle of the day — openingHoursSpecification takes a list of separate objects, one for each distinct hours pattern, exactly as in Google's own restaurant example, where Monday and Tuesday carry different hours than Wednesday through Friday, and Saturday and Sunday get their own entries (Google Search Central, LocalBusiness). A lunch break is written as two separate objects for the same day — one up to the break, one after it.

Step 4 — where to paste the code

JSON-LD code goes inside a <script type="application/ld+json"> tag, usually in the page's <head> section. With one address, a single block on the homepage is enough — or, better still, the same block on every page, so each one carries the same description of the business.

WordPress and website builders

In WordPress, the code usually goes through a code field in theme settings, an SEO plugin's structured data section, or a header code editor. Website builders typically have a separate "head code" field in page or site-wide settings — the exact name differs between platforms, but the mechanism is the same: the pasted code lands in <head> unchanged.

A business with two addresses

When a business has two or more locations, each address gets its own structured data block on that location's own contact page, with its own phone number and its own hours — the same way a Google listing works, where each branch gets a separate listing with that branch's opening hours, and the main office gets its own besides (Google, guidelines for representing your business). One shared block covering every address at once confuses the machine about where the business actually is.

Step 5 — test the code before you publish it

The Rich Results Test is Google's tool for validating structured data, and in some cases it also shows a preview of the search result (Google Search Central, introduction to structured data). It works two ways: paste the URL of a published page, or paste the code itself before it ever reaches a server.

The tool separates critical errors, which block the feature entirely, from warnings — fields that are recommended but not required. After publishing, keep watching the same page in the rich results status report in Search Console, since a page that worked correctly on launch day can break after the next template change.

Common mistakes that break structured data

The most common mistake is a mismatch between the code and the page: hours in the JSON-LD that differ from the visible content, or data about a service the page never actually describes. Google treats this as misleading — structured data is meant to reflect content visible to users, not offer a separate, more convenient version of reality (Google Search Central, structured data policies).

A second mistake is inventing ratings or reviews in the code that nobody actually left — the same requirement to match reality applies to ratings just as it does to hours and address. A third is copying one code block across every cloned subpage without changing the address and phone number, which, with several branches, ends up with every page claiming to be the same place.

Who updates the data when something changes

As long as one person keeps these three places — website, code, and Google listing — in sync from a single list, no mismatch appears. Once each one is updated by a different person at a different time, a mismatch is only a matter of time.

Do it yourself in an hour

1. Write the facts down in one table: name, address, phone, URL, hours by day, price range.
2. Pick the exact subtype from the industry table above, or stick with LocalBusiness if none fits.
3. Assemble the JSON-LD code from the example, substituting your own data.
4. Paste it into the <head> of the homepage or every page.
5. Check the code in the Rich Results Test and fix any critical errors.
6. Note the check date in a calendar and come back to the table whenever hours, phone, or address change.

What it looks like in a system

At Aura this starts with SEO and maps, where we tidy up the Google listing and add what the search engine needs to the site itself. The website and its code are built inside Websites and stores, and keeping the business description consistent across the site, structured data, and the sources that confirm it is the job of GEO / AI visibility. When business data lives in several systems at once, Integrations connect them so an update in one place spreads to the rest on its own. The system doesn't promise enhanced results — it only keeps the data consistent everywhere it appears.

More on who should actually be keeping business data current, and why it drifts apart in practice, is covered in restaurant data in Google, on the website, and on portals — the update mechanism is the same regardless of industry. If you're only starting to put a business's online presence in order, four thresholds instead of a general analysis are laid out in small business automation. On why inconsistent or incomplete data turns inquiries away before anyone even calls, see the analysis of Warsaw company websites, and on setting up numbers an owner actually looks at, see reporting automation.

Frequently asked questions

Will structured data improve my ranking in Google?

There's no guarantee of that. Google explicitly states that marking up data enables an enhanced result feature to appear, but doesn't guarantee it will — ranking is decided by other factors.

Do I have to use exactly the LocalBusiness subtype for a medical practice?

It's better to use a more specific subtype if one exists — for example, MedicalBusiness for a medical practice. A more precise type describes what the business does more unambiguously than the general LocalBusiness type.

What should I do if the Rich Results Test shows a warning instead of an error?

Warnings cover fields that are recommended but not required — the page will work without them, but it's worth filling them in if the data is available, since they add completeness to the description.

Can I put a higher rating in the code than the business actually has?

No. Structured data is meant to match reality and the content visible to users — an invented rating or review nobody actually left violates Google's policies and can result in a manual action.

How often should I check structured data in the Rich Results Test?

Every time the page template changes, and every time hours, phone number, or address change — a page that worked correctly on launch day can break after the next theme or plugin update.

Is one shared code block on every page enough for a business with one address?

Yes — if a business has one address, a single shared code block across every page is enough, and simpler to maintain than a separate block on each page.