LocalBusiness structured data: the fields Google uses

This guide is built from Google Search Central's Local business (LocalBusiness) structured data documentation (last updated 8 September 2026), Google's general structured data guidelines, and the schema.org definitions of LocalBusiness and OpeningHoursSpecification. What structured data is, which types a business site needs and how JSON-LD works are in our structured data basics guide; this page goes field by field through the LocalBusiness markup itself.

What LocalBusiness markup is for

Google describes two places where local business details show up. When someone searches for a business on Google Search or Maps, the results "may display a prominent Google knowledge panel with details about a business that matched the query". When someone searches for a type of business, such as "best NYC restaurants", they "may see a carousel of businesses related to the query". With LocalBusiness structured data, Google says, you can tell it about business hours, departments, reviews (only if your site collects reviews about other businesses) and more.

Two limits apply here as they do to all markup. Google "does not guarantee that features that consume structured data will show up in search results", and the markup is separate from your Google Business Profile, which you manage in Google's own tools. Think of the markup as a clear, machine-readable copy of the contact details already on your page, not as a replacement for the profile. If you want people to book or order directly from Search, Google points to a different tool, the Maps Booking API.

Choosing the type

Google asks you to define each business location as a LocalBusiness and to use the "most specific LocalBusiness sub-type possible", giving Restaurant, DaySpa and HealthClub as examples. Its general guidelines say the same for all markup: "Try to use the most specific applicable type and property names defined by schema.org."

Schema.org lists the direct sub-types of LocalBusiness, including Dentist, FinancialService, FoodEstablishment, HealthAndBeautyBusiness, HomeAndConstructionBusiness, LegalService, MedicalBusiness, ProfessionalService, RealEstateAgent, Store and TravelAgency, and most of those have narrower types of their own (Plumber and Electrician sit under HomeAndConstructionBusiness, for instance). Pick the deepest one that honestly describes the business, and fall back to LocalBusiness only when nothing fits.

If the business is more than one thing, Google says to list the types as an array, for example "@type": ["Electrician", "Plumber", "Locksmith"], and notes that additionalType "isn't supported". Because LocalBusiness is a sub-type of Organization, Google also recommends following its Organization fields (such as logo and sameAs links) on top of the local ones.

The fields Google supports

Google lists only two required properties, name and address. Everything else is recommended. "You must include the required properties for your content to be eligible for display as a rich result", and the recommended ones add information "which could provide a better user experience". Schema.org defines many more properties than these; the table covers the ones Google names.

The review row is the one most often misread. Star ratings for your own business, written into your own markup, don't qualify. Our reviews and testimonials guide covers showing reviews on the page instead. The restaurant carousel is also out of reach for most sites: Google says it "is currently limited to a small set of restaurant providers", with a form to register interest.

Opening hours

Each OpeningHoursSpecification has dayOfWeek, opens and closes. Google accepts both the full schema.org day values (https://schema.org/Monday) and the short form (Monday). Its property table describes times in hh:mm:ss format, while its own examples use hh:mm, such as "opens": "09:00". Google's examples cover the common cases:

• Standard hours. Group days with the same hours in one entry, for example Monday to Friday 09:00 to 21:00 and Saturday and Sunday 10:00 to 23:00 as two entries. Leaving out validFrom and validThrough means the hours apply all year.
• Past midnight. Use one entry: Saturday, opens 18:00, closes 03:00 means Saturday 6pm to Sunday 3am. Schema.org says a closing time earlier than the opening time "is assumed to span over the next day".
• Open 24 hours. Set opens to "00:00" and closes to "23:59".
• Closed all day. Set both opens and closes to "00:00".
• Seasonal closures. Add validFrom and validThrough as YYYY-MM-DD dates; Google's example closes a business over the winter holidays this way.

"openingHoursSpecification": [
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "09:00",
    "closes": "21:00"
  },
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Saturday", "Sunday"],
    "opens": "10:00",
    "closes": "23:00"
  }
]

Schema.org also defines a shorter text property, openingHours (for example "Mo-Sa 11:00-14:30"), and specialOpeningHoursSpecification for hours that override the regular ones. Google's LocalBusiness documentation doesn't list either, so we use openingHoursSpecification, which it does document. Whatever you choose, the hours in the markup must match the hours printed on the page, because Google's guidelines say "Don't mark up content that is not visible to readers of the page" and ask for up-to-date information.

Departments

If a business has departments with their own hours or phone numbers, Google says to add a department element for each one and define only the properties that differ from the main store. A department can be any LocalBusiness sub-type, such as a Pharmacy inside a Store. Google gives two naming rules:

• Use the format "{store name} {department name}", for example "gMart" and "gMart Pharmacy".
• If the department has its own brand, use that name alone, as in "Best Buy" and "Geek Squad".

Departments are for parts of one location. A separate branch across town is a separate location, covered next.

Several locations and service areas

Google says to define "each local business location" as its own LocalBusiness, and its general guidelines say: "Put the structured data on the page that it describes". The url property is the URL "of the specific business location". In practice that means one page per branch, each carrying the markup for that branch only, rather than one block listing every address on the home page. Our guide to location and service-area pages covers how to build those pages so they aren't thin copies of each other. Google adds that LocalBusiness markup can go on any page, "though it may make more sense to put it on a page that contains information about your business".

Businesses that travel to customers and don't receive them, such as many plumbers or cleaners, have a harder question, because address is a required field. Schema.org has an areaServed property ("The geographic area where a service or offered item is provided"), but Google's LocalBusiness documentation doesn't list it among the properties it supports. Our approach, not a Google rule: if the street address isn't shown on the website, we don't put it in the markup either, because of the visible-content rule above. We describe the area on the page in plain words, can add areaServed for other readers of schema.org, and accept that a page without a full address isn't eligible for this rich result.

A complete example

A fictional plumbing business with one location, built from the fields above. The values are placeholders; Google's own examples use example.com in the same way.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "name": "Example Plumbing",
  "url": "https://www.example.com/locations/springfield/",
  "telephone": "+15555550100",
  "image": "https://www.example.com/img/storefront.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "100 Main St",
    "addressLocality": "Springfield",
    "addressRegion": "IL",
    "postalCode": "62701",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 39.80172,
    "longitude": -89.64371
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "17:00"
    }
  ]
}
</script>

Note the five decimal places on the coordinates and the country code in the phone number, both of which Google asks for. Everything in the block should also appear in the visible text of the page.

Testing and troubleshooting

Google's steps for releasing the markup:

1. Validate the code in the Rich Results Test and fix any critical errors. Fixing non-critical issues can improve quality but "isn't necessary to be eligible for rich results".
2. Deploy a few pages first and check them with the URL Inspection tool. Make sure the page isn't blocked by robots.txt, a noindex tag or a login. Our URL Inspection guide walks through the tool.
3. Allow time: Google says "it may take several days after publishing a page for Google to find and crawl it". Submitting a sitemap keeps it informed of later changes.

If the markup doesn't seem to work, Google points to its list of structured data errors, the Unparsable structured data report in Search Console and a step-by-step guide to troubleshooting missing rich results. Breaking the guidelines can bring a manual action; Google says that in that case "the structured data on the page will be ignored (although the page can still appear in Google Search results)". Fix it, then request a review in the Manual Actions report. Google also notes that spammy markup is not a syntax issue, so the Rich Results Test won't catch it.

Our checklist

This is how we set it up on the sites we build; the rules it rests on are Google's, the routine is ours.

• The most specific type, or an array of types if the business really is several things.
• name and a full address on every location page, written the same way as on the page and in the Business Profile.
• telephone with country code, url pointing at that location's own page, and geo with at least 5 decimals.
• Hours in openingHoursSpecification that match the printed hours, updated with the page when they change.
• No review or rating markup about the business itself.
• One block per location page, tested in the Rich Results Test, then checked with URL Inspection after launch.

Frequently asked questions

What fields does Google require for LocalBusiness structured data?

Only two: name and address. Google recommends telephone, url, geo, openingHoursSpecification, priceRange and department, plus menu and servesCuisine for food businesses.

Which LocalBusiness type should I use?

Google asks for the most specific sub-type possible, such as Restaurant, Dentist or Plumber. If the business fits several, list them as an array; Google says additionalType isn't supported.

Can I add star ratings to my own LocalBusiness markup?

No. Google recommends review and aggregateRating only for sites that capture reviews about other local businesses.

How do I mark up a business that is open 24 hours?

Set opens to 00:00 and closes to 23:59 for those days. To show a day closed, set both opens and closes to 00:00.

Does LocalBusiness markup replace Google Business Profile?

No. The markup describes the business on your own web page; your Business Profile is managed separately in Google's tools. Keep the details in both consistent.

For more on local search, see our guides to Google Business Profile, Business Profile verification, service-area pages and structured data basics.