LocalBusiness Schema: Correct Markup With Examples
Correct LocalBusiness schema needs the right required fields, the most specific subtype, and exact NAP match to your Google Business Profile.
Correct LocalBusiness schema markup requires the name and address properties at minimum, with the address nested as a full PostalAddress object — street address, locality, region, postal code and country — but a genuinely useful implementation goes well beyond the bare minimum to include phone number, opening hours, geo coordinates, price range and a specific business subtype rather than the generic LocalBusiness type. The single detail that trips up more businesses than any schema syntax error: the name, address and phone number in your markup have to match your Google Business Profile listing exactly, character for character. A mismatch between what your schema says and what your GBP listing shows undermines the trust signal the markup is supposed to reinforce.
Key takeaway
- Google’s required properties for LocalBusiness rich results are name and address (as a full nested PostalAddress); everything else is recommended but strengthens the listing’s completeness and trustworthiness.
- Use the most specific schema.org subtype available — Restaurant, Dentist, ProfessionalService, HomeAndConstructionBusiness — rather than the generic LocalBusiness type, since it more precisely describes what the business actually is.
- NAP data in schema must match your Google Business Profile and website content exactly; even small formatting differences (Ste vs Suite, missing unit numbers) weaken the consistency signal.
- Multi-location businesses need a unique LocalBusiness entry per location page, not one schema block reused sitewide — a shared block tells search engines every page describes the same entity.
The required properties, and why “required” understates what you actually need
Google’s structured data documentation lists name and address as the formally required properties for LocalBusiness to be eligible for enhanced display in search results, with address specified as a nested PostalAddress object containing streetAddress, addressLocality, addressRegion, postalCode and addressCountry. Meeting only the required fields gets your markup technically valid, but it leaves out the properties that actually make the listing useful to a search engine trying to understand and potentially display your business: telephone, openingHoursSpecification, geo coordinates, priceRange, image, and url are all recommended rather than required, yet a business that includes them is giving Google a materially more complete picture than one that ships the bare minimum.
A correct, complete example
A well-formed implementation for a single-location professional service business, using JSON-LD (Google’s preferred format), looks like this:
| Property | Example value | Required or recommended |
|---|---|---|
| @type | ProfessionalService (or the most specific subtype that fits) | Required — use the specific subtype, not generic LocalBusiness |
| name | Exact business name, matching GBP | Required |
| address | Nested PostalAddress: streetAddress, addressLocality, addressRegion, postalCode, addressCountry | Required |
| telephone | Local number in consistent format, matching GBP | Recommended |
| openingHoursSpecification | Structured day-of-week and time ranges | Recommended |
| geo | latitude and longitude as GeoCoordinates | Recommended |
| priceRange | e.g. “$$” | Recommended |
| image | URL to a representative photo of the business | Recommended |
| sameAs | Array of verified social/profile URLs, including GBP | Recommended |
In JSON-LD, that structure is placed inside a script tag with type=”application/ld+json” in the page head or body, as a single JSON object with “@context”: “https://schema.org” and “@type” set to the specific business subtype. Validate it with Google’s Rich Results Test before publishing — syntax errors (a missing comma, an unescaped quote in a business name) are the most common reason schema fails to parse even when the underlying data is correct.
A minimal JSON-LD block, annotated
For a small business wondering what this actually looks like in the page source, a minimal but complete block resembles the following: an opening script tag declaring the JSON-LD type, an @context pointing to schema.org, an @type set to the specific business subtype, then name, address as a nested object, telephone, and openingHoursSpecification as an array of day/time objects. Every property sits as a plain key-value pair inside the outer object — there’s no special syntax beyond standard JSON, which is part of why JSON-LD has become the format Google recommends over microdata or RDFa: it can sit in one block in the page head, separate from the visible HTML, without needing to be woven into every element it describes. The most common way this breaks is entirely mundane — a trailing comma after the last property in an object, an unescaped apostrophe inside a business name string, or a schema block that was correct at launch but never got updated when the business changed its hours or moved address. None of these are exotic problems, which is exactly why a periodic validation pass, not just a one-time launch check, is worth building into a standard maintenance routine.
Choosing the right subtype instead of defaulting to LocalBusiness
Schema.org defines a hierarchy under LocalBusiness with dozens of specific subtypes — Restaurant, Dentist, Attorney, HomeAndConstructionBusiness, Store, ProfessionalService, and many more, each inheriting LocalBusiness’s properties while adding type-specific ones (a Restaurant can specify servesCuisine and menu, for instance). Defaulting to the generic LocalBusiness type when a more specific subtype exists is a common shortcut that leaves useful signal on the table — it tells Google less about what the business actually does, and it forfeits type-specific properties that could otherwise be included. Check the schema.org LocalBusiness hierarchy for the closest match before falling back to the generic type.
Matching schema to your Google Business Profile exactly
Schema markup doesn’t operate in isolation — Google cross-references it against other signals about the same business, including your Google Business Profile listing, and inconsistencies between the two undermine the confidence Google can place in either one. This means the name field in your schema needs to match the business name in GBP exactly, including punctuation and legal suffixes; the address needs the same suite or unit formatting; and the phone number needs the same format and area code presentation. This is the same underlying discipline covered in NAP consistency — schema is simply one more place that data needs to agree with everywhere else it appears, and it’s often the place businesses forget to update after a phone number or address change on the GBP listing itself.
Match it exactly
Google’s structured data guidelines require that markup reflect the same content visible to users on the page, and cross-reference local business data against other sources it trusts, including Business Profile listings. A schema block that disagrees with your live GBP listing is a consistency problem, not just a technical one.
Source — Google Search Central general structured data guidelines
Multi-location schema: one entity per page, not one block sitewide
The most common multi-location schema mistake is deploying a single LocalBusiness block sitewide — often via a theme setting or a plugin default — that describes only the company’s headquarters, then leaving every individual location page without its own distinct markup. Every branch needs its own LocalBusiness entry with that specific location’s name, address, phone number and hours, placed on that location’s own page. For businesses managing this at real scale, generating schema programmatically from the same structured location database that feeds the page content and Google Business Profile listings — rather than hand-coding it per page — keeps everything in sync as locations open, close, or change hours; see our multi-location SEO guide for the underlying data architecture that supports this.
A quick pre-publish checklist
- Validate the markup in Google’s Rich Results Test and Schema.org’s validator before publishing.
- Confirm name, address and phone number match your Google Business Profile listing exactly, including formatting.
- Use the most specific schema.org subtype available, not the generic LocalBusiness type.
- Include openingHoursSpecification, geo coordinates and priceRange where applicable — all recommended, all worth the extra few lines.
- For multi-location sites, confirm each location page carries its own unique entity, not a shared sitewide block.
- Re-validate after any redesign or CMS migration — schema markup is a common casualty of template changes that nobody remembers to check.
Frequently asked questions
What are the required fields for LocalBusiness schema?
Google’s documentation specifies name and address as required, with address structured as a full nested PostalAddress object including street address, locality, region, postal code and country. Recommended properties like phone, hours and geo coordinates aren’t strictly required but meaningfully strengthen the markup.
Does adding LocalBusiness schema guarantee a rich result in Google Search?
No. Valid structured data makes a page eligible for enhanced display, not guaranteed to receive it — Google decides whether and how to use the markup. Correct, complete schema improves the odds but isn’t a guarantee on its own.
Should I use the generic LocalBusiness type or a more specific subtype?
Use the most specific subtype that accurately describes the business — Restaurant, Dentist, ProfessionalService, and dozens of others exist under the LocalBusiness hierarchy. A specific subtype communicates more to Google and can support additional type-specific properties the generic type doesn’t offer.
Does every location need its own schema markup?
Yes, for multi-location businesses. Each location page should carry a unique LocalBusiness entity matching that specific branch’s name, address and phone number — a single schema block reused across all pages incorrectly signals that every page describes the same entity.
What’s the most common schema mistake businesses make?
Mismatched data between the schema markup and the Google Business Profile listing — different address formatting, an outdated phone number, or a business name that doesn’t match exactly. This inconsistency undermines the trust signal the markup is meant to reinforce.
The bottom line
LocalBusiness schema is a small technical task with an outsized consistency requirement attached: get the required and recommended properties right, choose the most specific subtype available, and — above all — make sure it matches your Google Business Profile and website content exactly. For multi-location businesses, treat schema generation as part of the same structured data pipeline covered in our local SEO guide, not a separate one-off task per page.
If your schema hasn’t been audited since your last site redesign, our SEO plans include a structured data review as standard.
