LocalBusiness schema: how do you add structured data for local SEO?

In brief: LocalBusiness markup describes your business to Google in a machine-readable format, provided it accurately reflects the page. It makes you eligible for certain rich results, but it promises neither display nor a direct ranking boost.

This guide walks through a complete implementation in six steps, from choosing the type to checking crawling, with a real code example for a fictional shop. Each step begins with the action to take, then sets out the useful details and the pitfalls.

What LocalBusiness schema offers (and what it doesn't promise)

The LocalBusiness markup is a set of structured data, that is, information written in a standardised vocabulary (Schema.org) that search engines can read without interpretation. It lets you give Google data about a business: opening hours, departments and, in some cases, reviews. According to Google Search Central, this data must relate to the business itself and comply with Google's guidelines.

Its limits are just as important. Valid markup can make a page eligible for certain rich results, without guaranteeing that they will appear. Display depends on the search context, the location, the device and the relevance of the data. Nor is any direct ranking boost promised by this markup.

Please note

A Google manual action targeting structured data removes eligibility for rich results. It does not, however, affect the page's ranking in web search.

This markup is therefore a precision building block, not a lever in its own right. It forms part of a broader approach, detailed in our guide to the complete method for local SEO on Google. Here, we focus on the code and how to implement it.

Prerequisites before writing the code

Before touching the JSON-LD, check that a page genuinely describes the business, with its details visible: name, address, phone number, opening hours. The markup must mirror this information, never be its only source. As for budget, there is nothing to plan for: the markup is free, and the only cost is the time spent implementing and checking it.

Data to gather

Collect the exact values in a working document, copying them from the published page rather than retyping them from memory.

• the business name, as it appears on the page;

• the full postal address;

• the phone number with country code;

• the full URL of the page;

• the regular opening hours;

• the GPS coordinates (latitude and longitude).

Technical access and tools

You need access to edit the HTML, the CMS or the tag manager. Also have ready the two free testing tools we will use in step 6: the Rich Results Test and the Schema Markup Validator.

Step 1: choose the right type and create one object per business location

Start by identifying the Schema.org type that describes your business. This is a modelling decision: it shapes how everything else is read.

The most specific subtype

Use the most specific LocalBusiness subtype that matches the business, for example Restaurant, DaySpa or HealthClub, rather than the generic type whenever a subtype exists. The essential condition: the type you choose must genuinely describe what the business does. A more specific type is no advantage if it is inaccurate.

One object per location

Each location of a local business is declared as a separate LocalBusiness object. For a brand with a presence in several cities, a single “brand” object grouping all the addresses muddles the information. Each location gets its own name, address, opening hours and phone number.

Several types of business

If the business genuinely carries out several activities, declare an array in @type, for example Electrician, Plumber and Locksmith. According to Google, additionalType is not supported in this case. Keep this option for activities that are actually carried out, not to artificially widen your coverage.

One last point of reference: LocalBusiness is a subtype of Organization. This relationship sets up the step on additional properties, which we will come back to in the maintenance tips.

Step 2: fill in the required and recommended properties

First fill in the two properties that Google lists as required, then add the recommended extras that apply to your case. The table below sets out the difference.

One common-sense rule applies to everything: only add information that is applicable and consistent with what is visible on the page. An empty or approximate property does more harm than a missing one.

Name and postal address

The address must be an object PostalAddress describing the physical location. Break it down into street, city, postcode and country rather than a single text string. It must match the place actually described by the page, not a registered-office address with no link to receiving the public.

Phone number and URL

TheURL must be complete and working, including the protocol. The phone number must include the country code and the area code, in international format. A number written the way you would dial it from home leaves the machine to guess the country.

Step 3: encode opening hours, coordinates, departments and special hours

Now translate the practical information into structured properties. This is the step where format errors are most common, because each field expects a precise syntax.

Opening hours by day

Declare opening hours with openingHoursSpecification, as an object or an array. Create one block for each range of days that share the same hours. Opening and closing times follow the hh:mm:ss format in the Google reference, for example 07:00:00. Opening hours must describe the real location and stay consistent with those shown on screen.

GPS coordinates

The geo property contains a latitude and a longitude with at least five decimal places of precision. Retrieve them from a mapping tool, checking that they point to the entrance of the premises rather than the centre of the town.

Departments and special opening hours

The department property is used to declare a genuinely distinct entity within the business, such as a pharmacy inside a shop, with its own details (name, opening hours, telephone number). Do not create one for simple aisles or services that have no independent identity.

To depart from the usual opening hours, use specialOpeningHoursSpecification: seasonal closure, public holiday, exceptional opening hours. These hours replace the general opening hours for the period concerned, which you define with dates. For how to express a closure lasting the whole day, consult the Google reference when you write the code.

Step 4: assemble the complete JSON-LD for a business

Assemble the properties in a script tag of type application/ld+json. Google recommends JSON-LD among the three supported formats (JSON-LD, Microdata and RDFa). Choosing a format does not exempt you from complying with the properties and rules specific to LocalBusiness.

Our example concerns a fictional business: a bakery in Lyon, hence the subtype Bakery. The coordinates, telephone number and URL are invented for illustration.

Minimal version

The minimal valid version contains only name and address, the two required properties.

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "Bakery",
 "name": "Boulangerie Les Trois Épis",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "12 rue des Halles",
 "addressLocality": "Lyon",
 "postalCode": "69001",
 "addressCountry": "FR"
 }
}
</script>

It is correct, but it leaves Google without opening hours, a telephone number or precise coordinates.

Full version

The enriched version adds the recommended extras.

<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "Bakery",
 "name": "Boulangerie Les Trois Épis",
 "url": "https://www.example.fr/boulangerie-lyon",
 "telephone": "+33-4-78-00-00-00",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "12 rue des Halles",
 "addressLocality": "Lyon",
 "postalCode": "69001",
 "addressCountry": "FR"
 },
 "geo": {
 "@type": "GeoCoordinates",
 "latitude": 45.76700,
 "longitude": 4.83500
 },
 "openingHoursSpecification": [
 {
 "@type": "OpeningHoursSpecification",
 "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
 "opens": "07:00:00",
 "closes": "19:30:00"
 },
 {
 "@type": "OpeningHoursSpecification",
 "dayOfWeek": "Sunday",
 "opens": "07:00:00",
 "closes": "13:00:00"
 }
 ]
}
</script>

Let's read it in order. @context indicates the Schema.org vocabulary, and @type specifies the most specific subtype. name and address repeat the required minimum, with an address broken down into its components. url and telephone use the full URL and the country code. geo shows five decimal places. Finally, the opening hours array contains one block for the days that share the same hours, and a second for Sunday.

What adds real value? The opening hours, telephone number and coordinates, because these are the details people look for about a place. Monday does not appear: the business is closed that day, and the absence of a block conveys this.

Step 5: place the markup on the right page

Place the JSON-LD on the page it describes. LocalBusiness can be added to any page of the site, but it is most relevant where the details of the business or of the location concerned appear. Never create an empty page solely to host structured data.

Homepage or location page

For a single business location, the homepage or contact page naturally carries the object. For a company with several locations, plan one page per location, each with its own object. In the projects we support, this is often where the quality of the site architecture shows: a local page with nothing of its own to say is hard to mark up well.

JSON-LD injected with JavaScript

JSON-LD can be generated by JavaScript, via a CMS, a framework or a tag manager. In that case, test the published URL and check the rendered HTML to confirm that Google can crawl and process the markup. This precaution matters most for markup injected on the client side.

Step 6: test the markup and check crawling

Test before and after going live, using two tools with different roles, then check that Google can access the pages.

The two validators

The Rich Results Test checks eligibility for Google's rich result features. The Schema Markup Validator checks the Schema.org vocabulary more broadly, including types with no Google-specific validation. Use both: one answers "Can Google do anything with it?", the other "Is my vocabulary correct?".

Point to watch

A test with no errors does not guarantee display in search results. It confirms that the code is readable and eligible, nothing more.

URL Inspection and recrawl

After deployment, test a few pages with the Search Console URL Inspection tool. Check that they are not blocked by robots.txt, by a noindex tag or by a mandatory login. If necessary, request a new crawl. Google states that discovery, crawling and reindexing can take several days: there is no point submitting repeated requests the very next day.

Common mistakes to avoid

Here are the pitfalls we most often come across during audits, grouped by type.

• Markup that does not match the visible content: opening hours, name, address, telephone number, URL or services that differ from those on the page, hidden or unrelated content, outdated data. Google requires data that is visible, accurate, relevant and up to date.

• Poorly chosen type: a generic type when a subtype exists, a single object for several locations, or additionalType used instead of an array @type.

• Approximate formats: coordinates with fewer than five decimal places, a telephone number without a country code, an incomplete URL.

• False sense of security: relying solely on the test's "valid" result and inferring a guarantee of display.

Point to watch

Self-awarding stars is a classic mistake. A business that controls its reviews cannot obtain stars for itself, even if third-party reviews are embedded on its own site. In this documentation, LocalBusiness reviews concern sites that collect reviews about other local businesses.

For each of these points, the remedy is the same: compare the code with the displayed page, line by line, before every release.

Practical tips for durable markup

Markup that is correct on the day it is published can become wrong three months later. Durability comes down to two habits: complete it intelligently, then maintain it.

Complete it with Organization

As LocalBusiness is a subtype of Organization, Google recommends also adding the relevant Organization fields: url, logo, sameAs, address, telephone number and brand identity. They can help Google understand and disambiguate the business. Only provide accurate profiles and identifiers for the entity or location concerned. A sameAs link to another agency's profile, for example, would be a mistake.

Maintenance and updates

Update the JSON-LD whenever opening hours, address or telephone number change, at the same time as the visible content. Also schedule a periodic check on a sample of pages, particularly after a redesign or a CMS change, when tags can silently disappear or be duplicated.

On the vocabulary side, Schema.org released version 30.1 on 16 September 2026. The release notes cited do not flag any material change to the core LocalBusiness model, so your current implementation does not need to be reworked for that reason.

Key takeaways

A precise type, one object per business location, name and address filled in, accurate additional properties, placement on the page it describes, then two validators and a URL inspection.

The best LocalBusiness markup is the one that stays true to the reality of your business, week after week: its value lies in its accuracy, not its volume.