LocalBusiness Schema Markup: 7 Essential Properties to Add

So your shop, clinic, or office shows up in search, but every competitor sitting above you has star ratings, opening hours, and a map pin baked right into the result, and you don't. Nine times out of ten that gap is structured data, and today we're going to close it properly.

Picture a customer searching for your service in your city. They scroll past five plain blue links and click the one listing with visible stars, hours, and an address right there in the snippet. A properly built LocalBusiness schema markup setup is usually the only real difference between those two listings.

Schema.org defines LocalBusiness as a type for "a particular physical business or branch of an organization," covering everything from restaurants and clinics to law firms and bowling alleys. It inherits properties from the broader Organization and Place types, which is why a single LocalBusiness block can carry contact details, geographic coordinates, and reviews all at once.

LocalBusiness schema markup is the vocabulary that turns a page full of plain text into something a search engine can actually parse into facts: this is the business name, this is the phone number, these are the hours. Without it, Google has to guess at those details from unstructured copy, and guesses are unreliable.

According to Ahrefs, this markup exists specifically to help pages surface in Local Search results and in Google Maps, which is exactly where most local purchase decisions begin. Get the setup wrong and you are not disqualified, you simply miss out on the richer display other businesses are getting for free.

Before touching any code, it helps to know what the standard actually asks for. From the base LocalBusiness type you get openingHours, priceRange, paymentAccepted, and currenciesAccepted. From the inherited Organization type you get address, telephone, email, aggregateRating, and review. From Place you inherit geo, image, photo, and the more detailed openingHoursSpecification.

Google's own structured data guidelines are narrower than the full schema.org vocabulary. Google only strictly requires name and a complete address object with street, locality, region, postal code, and country. Everything else, telephone, a page specific url, opening hours, geo coordinates, and price range, is recommended rather than mandatory.

That distinction matters because plenty of guides treat the full schema.org property list as a checklist of requirements, when in reality Google is asking for the minimum needed to confirm identity and location, and leaving the rest to improve how the listing looks once it qualifies. Knowing this upfront keeps a LocalBusiness schema markup project from sprawling into properties nobody actually checks.

Step one of a complete LocalBusiness schema markup setup is the identity block: name, @type, and the address object. The name should match what appears on your signage and your Google Business Profile exactly, no keyword stuffing, no extra city names appended. The address should use the full PostalAddress structure rather than a single text string, since each field, street address, locality, region, postal code, and country, maps to a distinct property Google can validate.

Step two adds telephone and opening hours. Use a single primary contact number in full international format, and express hours with the standard shorthand, for example Mo-Fr 09:00-18:00, rather than a sentence describing your schedule. If your hours genuinely vary by day, use openingHoursSpecification instead of the simpler openingHours property so each day gets its own entry.

Every one of these values needs to match what is published everywhere else your business appears online, your website footer, your Google Business Profile, and any directory listing. That matching is the entire idea behind NAP consistency, and it is worth reading in full if you haven't already: see our breakdown of NAP consistency as a local SEO ranking factor.

Step three is geo, your latitude and longitude as a GeoCoordinates object. Google recommends at least five decimal places of precision, which is roughly the difference between pointing at your building and pointing at your entire block. You can pull exact coordinates from Google Maps itself by right clicking your pin.

Step four covers priceRange and, carefully, aggregateRating. Price range is a short symbolic string under a hundred characters, something like $$, and it exists to set expectations rather than list exact prices. This is also the point where a LocalBusiness schema markup setup starts looking complete rather than minimal. Ratings are where most local businesses get tripped up, so it deserves its own warning.

BrightLocal's review schema guide explains that Google changed policy in 2019 so that reviews a business places about itself are no longer eligible for star display in search results. If the entity being reviewed controls the reviews describing itself, whether added directly or through an embedded widget, the star rating simply will not render. The workaround most sites use is marking up reviews of specific products or services instead of the business entity itself, which schema.org explicitly supports and Google still honors.

Step five, and the one skipped most often, is validation before you publish. Paste your finished code block into Google's Rich Results Test, available through Search Console help, and check it against a live URL rather than only a snippet, since some errors only surface once the page actually renders.

Google's own documentation for the tool flags one gotcha worth remembering directly: the Rich Results Test quietly ignores comments written inside your structured data block during testing, which means a page that passes the test can still throw errors once it goes live, because that comment skipping behavior is not part of the actual JSON-LD standard. Strip every comment from the final code before you ship it, not just before you test it.

Once the test passes with no errors and no missing fields, publish the page, then recheck it again a few days later through the URL Inspection tool in Search Console to confirm Google actually read the markup the way you intended.

A complete LocalBusiness schema markup setup does not exist in isolation. Search Engine Journal's guide to local schema describes structured data as acting like a translator, turning your website's content into a format search engines can classify quickly, and notes that it helps Google associate your site with your Google Business Profile even when that profile listing is incomplete or unclaimed.

That alignment only works if the facts actually agree. If your schema lists one phone number, your Google Business Profile lists a second, and an old directory listing lists a third, you have given Google three conflicting answers to the same question and no reason to trust any of them fully. Before you publish new markup, it's worth confirming your Google Business Profile itself is complete and accurate; our Google Business Profile setup guide walks through that from scratch.

Reviews deserve the same discipline. If you're actively trying to grow your review count as part of this process, our guide on getting more Google reviews pairs naturally with the aggregateRating properties covered in step four above.

Most broken LocalBusiness schema markup implementations aren't caused by complicated properties, they're caused by small, avoidable slips that nobody catches before publishing.

None of these mistakes are difficult to fix once you know to look for them, which is really the whole point of treating LocalBusiness schema markup as a maintenance task rather than a one time project.

That gap is exactly what a complete, accurate LocalBusiness schema markup setup is working toward, not a guaranteed ranking boost on its own, but a better looking, more trustworthy listing once you've already earned visibility through the other signals that actually move rankings.

Properties at a Glance

Property	Required by Google	Notes
name	Yes	Must match signage and your Google Business Profile
address	Yes	Use the full PostalAddress object, not plain text
telephone	Recommended	One primary number, full international format
openingHours	Recommended	Use openingHoursSpecification if hours vary by day
geo	Recommended	Five decimal places of precision or more
priceRange	Recommended	Short symbolic string, under 100 characters
aggregateRating	Conditional	Only for reviews of products or services, not the business itself