How do I add LocalBusiness structured data to my website?

Structured data describes a page in a vocabulary machines share. For a business that vocabulary is schema.org, which defines LocalBusiness as a particular physical business or branch of an organisation, such as a restaurant or a bank branch. It is usually written as JSON-LD: a few lines of data in a script element of type application/ld+json, read by software and never shown to visitors.

Google’s documentation says the markup lets you tell Google about your opening hours, departments and more. It requires name and address, and recommends others, including telephone, url, geo and openingHoursSpecification.

There are two limits. Google’s guidelines say the markup must describe what the page itself shows, and that using it does not guarantee any search feature will appear; its guide to AI features adds that they need no special schema.org markup. What a block does for certain is state your details once, in a form that can only be read one way.

The kind of business goes in @type, and Google asks for the most specific type under LocalBusiness you can find: Bakery and CafeOrCoffeeShop under food businesses, BookStore under shops, HairSalon under health and beauty. Search schema.org for the word you would use, open its page, and check that LocalBusiness appears in the line of types above it.

If nothing fits, LocalBusiness itself is right, and safer than a type that is almost right, which states something untrue. Copy the name exactly, capitals included: CafeOrCoffeeShop, not Cafe.

The business is invented: Popty Teifi, a bakery and café in Cardigan with an English page and a Welsh one. Its English block opens with "@context": "https://schema.org", naming the vocabulary, then "@type": "Bakery" and "@id": "https://popty.example/#popty". In JSON-LD an @id identifies a thing so that other data can refer to the same one, which the bilingual section relies on.

Then the facts a customer reads: "name": "Popty Teifi", as on the sign, "description": "Bakery and café by the river: sourdough and Welsh cakes.", "url": "https://popty.example/en/" and "telephone": "+441632960123". Google wants the country and area codes, so +44 replaces the first 0.

The "address" is a PostalAddress with a field for each part: "streetAddress": "4 Quay Yard", "addressLocality": "Cardigan", "addressRegion": "Ceredigion", "postalCode": "SA43 1ZZ" and "addressCountry": "GB". schema.org accepts a two-letter ISO country code there, and for anywhere in the United Kingdom, Wales included, that code is GB.

For the location, "geo" is a GeoCoordinates item, "latitude": 52.08312 and "longitude": -4.66087, read off a map pin on the front door; Google asks for at least five decimal places. Google recommends more, such as priceRange and menu; add only what your page states.

Hours go in openingHoursSpecification, a list of OpeningHoursSpecification items, each naming days in dayOfWeek and 24-hour times in opens and closes. Popty Teifi opens Tuesday to Saturday, eight till four, so one item covers it: "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"], "opens": "08:00", "closes": "16:00". A day with other hours, such as a late Friday, leaves that list for an item of its own.

Google’s documentation covers the harder cases. A closed day has opens and closes both at 00:00; open round the clock runs from 00:00 to 23:59; hours past midnight close earlier than they open. Hours that hold only for a while, such as a Christmas closure, take validFrom and validThrough dates, and without them Google reads the hours as valid all year.

When your hours change, change the block and the page on the same day. Google’s guidelines expect markup to match what a visitor sees, and a block that disagrees with your footer states something untrue.

One block per page, in that page’s language. The Welsh page carries its own copy, with Welsh wherever a person would read the value: "description": "Popty a chaffi ger yr afon: bara surdoes a phice ar y maen.", "streetAddress": "4 Iard y Cei", "addressLocality": "Aberteifi" and "url": "https://popty.example/cy/".

Whatever identifies the business stays identical: the @id, telephone, postalCode, geo and the hours. In JSON-LD, blocks that share an @id describe one thing, so the two pages describe one bakery in two languages, not two bakeries.

Names from the vocabulary never change language. @type stays Bakery, property names stay as they are, and dayOfWeek stays Tuesday: schema.org’s days are a fixed list, and Dydd Mawrth is not on it.

Then inLanguage. schema.org gives it to creative works such as WebPage, not to businesses: a bakery has no language, but a page about it does. So the block becomes an @graph list, with @context once at the top and two items: the bakery as before, and a page item with "@type": "WebPage", "inLanguage": "cy" and "mainEntity": {"@id": "https://popty.example/#popty"}, pointing at the bakery by its identifier. The English page uses "en". Both are BCP 47 language tags, the standard schema.org names.

Google suggests starting with its Rich Results Test. Give it a live address, or paste the code if the page is not public yet: it can only fetch what an anonymous visitor could. It lists the rich result types it found, with any errors and suggestions: you want a local business with no errors. If nothing is found at all, check the JSON first, since one missing comma or quote stops the whole block being read.

Then run the same address through the Schema Markup Validator, which schema.org runs. Google describes it as generic schema.org validation without Google’s own checks, so it covers what Google’s test passes over, such as the WebPage item and its inLanguage.

Test the Welsh and English addresses separately, since one block can break while the other works. Once they are live, Google suggests the URL Inspection tool in Search Console to confirm it can reach them. To start from your own page, the free assessment on this site drafts a block from the name, number and postcode it finds there, and leaves out what it cannot find.