LocalBusiness Schema Guide + JSON-LD Example

Q: What properties does LocalBusiness schema require?

Google leans on name, a structured address (`PostalAddress` with street, city, region, postal code, country), `geo` coordinates, `telephone`, and `openingHoursSpecification`. Recommended additions include `url`, `image`, and `priceRange`. The hours and address should use the nested object formats rather than plain strings.

Let me set expectations honestly, because a lot of local SEO content oversells this: LocalBusiness schema on your website does not get you into the Google map pack. Your Google Business Profile (GBP) does that. The map pack, the knowledge panel, and the "near me" results are driven by your verified GBP, proximity, and reviews, not by JSON-LD on your homepage. So why add LocalBusiness schema at all?

Because it corroborates. When your website's structured data states the same name, address, phone, and hours that your Google Business Profile lists, you are giving Google consistent, machine-readable confirmation of your business details from a second source you control. Consistency across sources is one of the things Google's local systems weigh. The schema is the supporting witness, not the star witness. That framing keeps you from wasting time expecting rankings the markup cannot deliver, while still doing the thing that genuinely helps.

You can build a valid LocalBusiness block with our Schema Markup Generator, which handles the nested address and hours objects that are easy to get wrong by hand. If you are new to structured data generally, our structured data guide covers the basics this post builds on.

Required and recommended properties

For LocalBusiness, Google leans on a specific set of properties. The ones that carry the most weight:

name is the business name, exactly as it appears on your storefront and your GBP.

address is a nested PostalContact (PostalAddress) object with streetAddress, addressLocality (city), addressRegion (state or province), postalCode, and addressCountry. Do not cram the whole address into one string; use the structured sub-properties.

geo is a nested GeoCoordinates object with latitude and longitude. Pull the exact coordinates from your GBP pin so they match.

telephone is the phone number in a consistent format, ideally with the country code (+1-555-123-4567).

openingHoursSpecification is an array of OpeningHoursSpecification objects, each listing the days and the open and close times. This is the property people most often skip or malform, and it is the one that feeds hours into any surface that reads it.

url points to the specific location's page, and image links a real photo of the business. priceRange (as $ to $$$$) is recommended for restaurants and retail.

A worked example

Here is a complete LocalBusiness block for a single-location dentist. Notice the specific subtype, which we will come back to.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Riverside Family Dental",
  "image": "https://riversidefamilydental.com/img/office.jpg",
  "url": "https://riversidefamilydental.com/",
  "telephone": "+1-503-555-0147",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "218 Willamette Ave, Suite 4",
    "addressLocality": "Portland",
    "addressRegion": "OR",
    "postalCode": "97204",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 45.5187,
    "longitude": -122.6765
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
      "opens": "08:00",
      "closes": "17:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Friday",
      "opens": "08:00",
      "closes": "13:00"
    }
  ]
}
</script>

Paste that into the <head> of the location's page. If you run one location, the homepage is fine.

Match your NAP exactly

NAP is name, address, phone. The single most common local schema mistake is a NAP that does not match the Google Business Profile: the schema says "Riverside Family Dental," the GBP says "Riverside Dental Care," and the footer says "Riverside Family Dental, LLC." To Google, those are three slightly different businesses.

Pick the exact name, address format, and phone number your GBP uses, and make the schema, the visible page content, and the GBP all say the same thing, character for character. "Suite 4" versus "Ste. 4," a phone number with dashes versus one with dots, an abbreviated street type versus a spelled-out one: these small inconsistencies are the noise you are trying to eliminate. The point of the markup is consistency, so an inconsistent NAP defeats the entire exercise.

Choose the specific subtype

LocalBusiness is the generic type, but schema.org defines dozens of specific subtypes that all inherit from it: Dentist, Restaurant, Attorney, Plumber, HairSalon, AutoRepair, Bakery, and many more. Use the most specific type that fits your business rather than the generic LocalBusiness.

Two reasons. The specific subtypes carry extra properties that make sense for them (a Restaurant gets servesCuisine and menu; a FoodEstablishment gets acceptsReservations), and using the precise type tells Google exactly what kind of entity you are rather than making it infer. If no subtype fits, fall back to LocalBusiness, but check the schema.org list first, because there are more subtypes than most people expect.

Multi-location businesses

If you have several locations, do not put one LocalBusiness block on the homepage listing every address. Give each location its own page (/locations/portland, /locations/seattle) and put a distinct LocalBusiness block on each one, with that location's own address, geo coordinates, phone, and hours. Each block should match that location's own Google Business Profile.

Link the location pages from a locations index, and make sure your internal linking reflects the structure so both crawlers and users can reach every location page. One page per location with one matching schema block per page is the pattern that scales without confusing Google about which details belong to which storefront.

What to skip

A few things people add to LocalBusiness markup that earn nothing. You do not need sameAs links to every social profile you own; one or two authoritative profiles are plenty, and a wall of them is noise. You do not need to invent an aggregateRating from thin air, and you certainly should not, because fabricated ratings that do not appear on the page are a policy violation that can draw a manual action. And you do not need a separate block for your Organization and your LocalBusiness if you are a single-location business; the LocalBusiness block already inherits from Organization, so one is enough.

Spend the saved effort on the two things that actually move the needle for local search: keeping your Google Business Profile accurate and complete, and making your NAP identical everywhere it appears. The schema supports those; it does not replace them.

Frequently Asked Questions

Will LocalBusiness schema get me into the Google map pack?

No. The map pack is driven by your verified Google Business Profile, proximity, and reviews, not by schema on your website. LocalBusiness markup corroborates the details in your GBP by confirming the same name, address, phone, and hours from a source you control, which supports consistency but does not itself produce map-pack rankings.

What properties does LocalBusiness schema require?

Google leans on name, a structured address (PostalAddress with street, city, region, postal code, country), geo coordinates, telephone, and openingHoursSpecification. Recommended additions include url, image, and priceRange. The hours and address should use the nested object formats rather than plain strings.

Should I use LocalBusiness or a more specific type like Restaurant?

Use the most specific subtype that fits. Schema.org defines subtypes like Restaurant, Dentist, and Attorney that inherit from LocalBusiness and add relevant properties. The specific type tells Google exactly what kind of business you are; fall back to the generic LocalBusiness only when nothing more precise applies.

How do I handle schema for multiple locations?

Give each location its own page and put a separate LocalBusiness block on each, with that location's own address, coordinates, phone, and hours matching its own Google Business Profile. Do not list every location in one block on the homepage, which blurs which details belong to which storefront.

Why does my NAP need to match my Google Business Profile exactly?

The value of the markup is consistency. If your schema, your visible page, and your GBP show even slightly different names, address formats, or phone formats, you undercut the confirmation the schema is supposed to provide. Match the name, address, and phone character for character across all three.

LocalBusiness Schema: The Markup That Backs Up Your Google Business Profile