LocalBusiness schema markup for an Indian business

LocalBusiness structured data is a block of JSON-LD sitting alongside your page's visible content, stating in machine-readable form what kind of business this is, where it is, and how to reach it. It exists because prose is ambiguous to a parser in ways it is not to a person: a line of text reading 'Kothrud, Pune 411038' is obviously an address to you and is a string of characters to a machine that has not been told otherwise.

The important thing to hold onto is that the block is a set of factual claims, not decoration. Every property you fill in asserts that this information is genuinely true of this business and genuinely present on this page. That framing decides most of the field-by-field questions below, because the answer to 'should I include this property?' is almost always 'only if it is true and the page shows it'. Markup that claims something a visitor cannot verify by reading the page is the category of mistake that gets acted on, rather than the category that merely underperforms.

Two are required for the type to mean anything at all: name and address. A LocalBusiness block without an address is not a local business as far as a parser is concerned, and markup missing a required property is ignored — which is worse than having none, because it looks finished to whoever wrote it and produces nothing.

Beyond those two, the properties that do real work are telephone, url, openingHoursSpecification, geo, priceRange and image. Name, address and telephone are the ones that must agree with what you have published elsewhere, because they are the fields a search engine can cross-check against directories and your own business profile. openingHoursSpecification is more useful than people expect and more often wrong than any other field, because it is set once and never revisited after the shop changes its Sunday hours. geo is worth adding when your entrance is genuinely hard to place from the address alone, which in a lane-addressed Indian neighbourhood is often. Leave out anything you would have to invent. An absent property costs you a possible enhancement; a wrong one costs you trust.

The address property takes a PostalAddress object with named sub-properties, and the mismatch between that shape and how Indian addresses are actually written is where most of the difficulty lives. streetAddress holds the building, lane and locality detail — shop number, building name, road, and the neighbourhood if it is part of how people write the address. addressLocality is the city, so Pune, not Kothrud. addressRegion is the state, and spelling it out as Maharashtra is safer than an abbreviation. postalCode is the six-digit PIN. addressCountry takes the two-letter code, IN.

The recurring errors are specific. Putting the locality in addressLocality and the city nowhere, which leaves the business apparently situated in a suburb no gazetteer knows as a city. Putting the PIN inside streetAddress as part of the text and leaving postalCode empty. Writing 'India' in addressCountry where the two-letter code is expected. And splitting a single Indian street line across streetAddress and a second field that does not exist in the vocabulary. The safe habit is to write the address as you would on an envelope, then assign each part to exactly one property, with the city in addressLocality and the PIN on its own.

The telephone property wants a number a machine can dial from anywhere, which means full international form: a plus sign, the country code 91, then the subscriber number. So +912025551234 or +91 20 2555 1234 for a Pune landline, and +919812345678 for a mobile. What it does not want is the form most Indian sites publish, which is a leading zero for domestic trunk dialling — 020 2555 1234 — or a mobile written as ten bare digits.

The reason this matters beyond validator pedantry is that a search engine comparing your markup to your business profile and to a directory listing is comparing strings. 020 2555 1234 and +91 20 2555 1234 are the same number to a person and are not the same string to a parser, and the trunk zero is dropped when the country code is present rather than kept alongside it. Publishing one form in the markup, another in the page footer and a third on a directory gives three variants of one fact. Pick the international form, use it in the markup, and keep the visible page consistent with it — a visitor can still dial a number written as +91 20 2555 1234, so there is no reason for the two to differ.

This is the point people find counterintuitive and it follows directly from how the markup is consumed. A parser reading a LocalBusiness block that lacks a required property does not partially credit it — it discards it. So the business has a block of JSON-LD on the page, a validator that reports it as present, and nothing whatsoever resulting from it. Compare that to having no markup at all: the same outcome, minus the false impression that the job is done.

The usual route to an incomplete block is a generator with more fields than the business has answers for. Someone fills in the ones they know, leaves the rest, and takes the green tick as completion. Two habits prevent it. Check that name and address are both genuinely populated before shipping anything, since those are the properties whose absence voids the block. And resist the pull of the highest-risk fields: a rating or a review count in the markup is the fastest way to cause real damage, because star ratings surface directly in results where a visitor sees them before the page loads, and a rating the page does not display is a claim it cannot support. If you have real reviews, display them on the page first, then mark up what is shown.

The check that catches the most is not a validator run. Open the rendered page, read each value in the JSON-LD block one at a time, and ask whether a visitor could confirm that value from the page in front of them with nothing else open. The name, the street address, the city, the phone number, the opening hours — all of these should appear in the visible content, not only in the markup. Anything that fails that question is the field that will cause a problem, and the fix is either to remove it or to make the page true first.

Then check the mechanical things, which are all readable from the page's own source: that the block parses as valid JSON, that the type is spelled correctly with its exact capitalisation, that addressCountry is IN rather than India, that postalCode contains six digits and nothing else, and that telephone begins with +91 and carries no trunk zero. None of this needs a paid tool or an account anywhere. And revisit the block whenever the page changes, because structured data has no expiry of its own — it stays exactly as written until somebody updates it, which is how a correct block quietly becomes a false one after a move or a change of hours.