Local business schema generator

How to generate LocalBusiness schema

One storefront per page, one page per storefront. The generator writes the markup and the visible block from the same values, so the two can never drift apart.

1. Pick the most specific business type. Restaurant, Dentist, Plumber and the rest are subtypes of LocalBusiness and inherit everything it has. Use LocalBusiness only when nothing more specific fits.
2. Fill in name and address. Those two are the only required properties. Everything else on this form is recommended — it makes the result richer, not valid.
3. Write the hours as rules, one per line. A bar open Saturday from 18:00 until 03:00 is one line, not two. A holiday closure is a date range plus the word closed. The generator turns each line into an OpeningHoursSpecification.
4. Read the warnings before you copy. Coordinate precision, a price range too long to display, an address part missing, a day covered by two contradicting rules — each one is a thing Google either ignores or reads differently than you meant.
5. Paste both outputs. The JSON-LD goes in the head or body of that location page. The address block and hours table go where visitors read them. Regenerate both whenever the hours change.

The part every other generator gets wrong: hours past midnight

A local business schema generator turns a storefront's details into LocalBusiness JSON-LD — the structured data Google reads for business hours, location and departments. The hard part is not the address. It is the hours, and it is where the tools ranking for this query fall over.

Google's documentation is explicit: for hours past midnight, define opening and closing hours using a single OpeningHoursSpecification property. A bar open Saturday 18:00 until Sunday 03:00 is one rule — dayOfWeek: Saturday, opens: 18:00, closes: 03:00 — not a Saturday rule ending at 23:59 plus a Sunday rule starting at 00:00. Split it and you have told Google the bar closes at midnight and reopens for a mysterious three-hour Sunday breakfast.

The second-ranked tool for this query, checked on 2026-09-04, offers one row of weekday checkboxes and a single open/close pair — the whole week gets one rule, and closing before you opened is unrepresentable. This generator takes a line per rule, so the shapes Google documents are all sayable:

Mon-Thu 07:00-19:00
      Fri     07:00-23:00
      Sat     09:00-02:00          # past midnight, one spec
      Sun     closed               # opens and closes both 00:00
      Mon-Sun 24h                  # opens 00:00, closes 23:59
      2026-12-24..2026-12-26 Mon-Sun closed   # validFrom / validThrough

Those last three encodings are not our invention. Google's page says to show a business open around the clock, set opens to 00:00 and closes to 23:59; to show it closed all day, set both to 00:00; and it defines validFrom and validThrough as the start and end of a seasonal closure in YYYY-MM-DD form. Most forms simply have no field for the third one.

What is actually required, and what only looks required

Google's Local Business page lists exactly two required properties: name and address. Everything else — hours, phone, geo, price range, department, images — is recommended. A generator that refuses to emit anything until you have filled fourteen boxes is not enforcing a Google rule; it is enforcing its own form.

What is worth getting right, because Google states a consequence:

• Coordinate precision. geo.latitude and geo.longitude must carry at least five decimal places. Three decimals is roughly a hundred metres — a different building on a city block. The tool warns below five.
• Price range length. priceRange has to be shorter than 100 characters; at 100 or more Google will not show a price range for the business at all. It takes $$ or 10-15, not a paragraph about your packages.
• Department naming. A nested department should be named {store name} {department name} — gMart and gMart Pharmacy — unless the department carries its own brand.
• Country code. addressCountry takes the two-letter ISO 3166-1 code. "United States" is not wrong enough to break, but the code is what everything downstream parses.

And one property Google's page never mentions: priceRange being deprecated. It is not. It is still listed as recommended, with that length rule attached — a claim worth checking before you strip it out of a template on someone's advice.

Two branches, one website: give each node an @id

Google's Local Business documentation says nothing about @id. We are not going to pretend otherwise. But the moment a site has more than one storefront, an @id stops being decoration.

Without one, each location page emits an anonymous JSON-LD node. Your own site handles that fine — one page, one business. Everything else that reads the graph does not: aggregators, a knowledge-graph pipeline, your CMS's own schema plugin, an agent crawling your site to build a location list. A node with a stable IRI — https://example.com/locations/mint-plaza#store — is the same node every time it is seen, and other markup on the page can point at it instead of duplicating it.

The practical rule for multi-location sites: one page per location, one LocalBusiness node per page, one @id per node, and the url property pointing at that same page. Do not list all twelve branches on one page and mark them all up — Google's guidance for structured data is that the markup describes the page it sits on. If you need a hub, the hub links to the twelve; it does not impersonate them.

Star ratings you collected yourself: the line not to cross

The checkbox at the bottom of the form exists to be refused. Google's review snippet guidelines state that if the entity being reviewed controls the reviews about itself, pages using LocalBusiness or any Organization type are ineligible for the star review feature — and that includes an embedded third-party reviews widget on your own site.

LocalBusiness review and aggregateRating are documented as recommended only for sites that capture reviews about other local businesses: a directory, a review site, a guide. If the page is your own shop, the stars are not coming, and marking them up anyway is the kind of thing that collects a manual action rather than a rich result.

This is one of four rules in the same family, all of them checkable rather than arguable, and each one has its own tool here: what a review may claim is covered by the review schema generator, what an offer must carry by the product schema generator, and the rule that markup must match the visible page — the rule this whole toolset is built on — by the FAQ schema generator.