LocalBusiness Schema for Site Owners: Google’s 2 Required Fields
LocalBusiness schema is structured data that tells search engines the key facts about a physical business, such as its name, address, phone number and opening hours. Valid markup needs just two properties: name and an address written as a PostalAddress object. Add it, and search systems read your business details more clearly, which can help search engines interpret your business details.
TL;DR:
- Choose the most specific schema.org subtype that accurately fits your business; use generic LocalBusiness only when no narrower type applies.
- For a service area business that does not serve customers at its premises, omit streetAddress, publish location details you are comfortable sharing, and use areaServed to describe coverage.
- Give every physical branch its own page and LocalBusiness block, with that location’s address, phone number, hours, coordinates, and URL.
- Use openingHoursSpecification when hours vary, list closed days, and date seasonal exceptions with validFrom and validThrough; check overnight and closure formats with a validator.
- Test markup with Rich Results Test and Schema Markup Validator, then compare detected values with the page; valid markup does not guarantee Google will display rich results.
Table of Contents
- What LocalBusiness schema is and how it relates to schema.org and Google
- Required and recommended properties to include
- Choosing the right @type: prefer specific LocalBusiness subtypes
- Service-area businesses and multi-location setups
- Opening hours: formats, seasonal hours and overnight spans
- Example JSON-LD: copy-ready snippets for storefronts and service-area businesses
- Where to place LocalBusiness JSON-LD on your website
- Testing and validation workflow: tools and monitoring
- Common mistakes and quick fixes
- Author perspective: practitioner checklist and priorities from Blindspot
- How we can help you implement and validate your LocalBusiness schema
- FAQ
- Sources
What LocalBusiness schema is and how it relates to schema.org and Google
Schema.org is the shared vocabulary behind structured data. It organises its terms as a hierarchy of types, and LocalBusiness sits under Place and Organization, which is why it can carry both location details (address, coordinates) and business details (opening hours, price range). You can read the full definition, with example markup, in the schema.org LocalBusiness reference.
Schema.org tells you what you are allowed to say. Google tells you what it will actually use. Those are not the same list, and that gap trips up a lot of site owners. A property can be perfectly valid vocabulary and still do nothing in Search. Google’s own guidance is clear that its documentation determines which structured data features appear, so Google’s structured data policies are the page to treat as the rulebook for rich-result eligibility. When schema.org and Google disagree on what is required, follow Google.
Google’s introduction to structured data also makes a point worth remembering: accurate data for the essential fields beats a long tail of incomplete optional ones. Stuffing every property you can find into the block does not make it stronger. A short, correct block that matches your visible page does more.
The type system gives you many subtypes, each aimed at a kind of business. Some you will meet often:
- Plumber, Electrician, Locksmith, RoofingContractor: home service trades.
- Dentist, Physician, Optician: health practices.
- Restaurant, Bakery, CafeOrCoffeeShop: food and drink.
- AutoRepair, AutoDealer: motoring.
- HairSalon, BeautySalon, DaySpa: personal care.
- LegalService, AccountingService, RealEstateAgent: professional services.
Pick the one that describes what you do most precisely. Fall back to plain LocalBusiness only when nothing in the hierarchy fits. We cover that choice in detail further down.
Required and recommended properties to include
Two properties make LocalBusiness markup valid in Google’s eyes: name and address. The address must be a PostalAddress object, not a single string of text. Check that both properties are present when reviewing markup.
Google’s local business documentation lists name and address as required, and geo, openingHoursSpecification, telephone and url as recommended, along with the formatting rules Google applies to those fields. Beyond that short list, these are the properties that earn their place on most sites:
- telephone: the number customers actually ring, in a format customers can use to call.
- url: the canonical page for this location, not just your homepage by default.
- openingHoursSpecification: your opening hours, including any days you are closed.
- geo: latitude and longitude as a GeoCoordinates object, with enough precision to identify the location accurately.
- image: a real photo of the business, shop front or team.
- priceRange: a short indication of cost level, such as “££”.
- sameAs: links to your Google Business Profile and social profiles, so search systems can connect the same entity across the web.ross the web.
Google’s guidance is to prioritise accurate, complete data for essential fields such as address and hours over piling on optional extras, as its structured data introduction puts it. Treat that as your editing rule: finish the required and recommended fields properly before adding anything else.
Most validation problems come from formatting rather than missing fields. Keep these rules in mind:
Write addressCountry as an ISO country code. Write opening and closing times in a consistent, machine-readable time format. Give coordinates enough precision to identify the correct location. Keep priceRange short. A currency symbol band is enough, and an overly long value may read like a sentence rather than a range. 5. Use complete URLs for url, image and sameAs.
Why do these small rules matter? Search systems extract your details automatically. A time written as “9am-5pm” or a country written as “England” may be skipped or misread, and you never see the failure unless you test. Clean formats are what let the markup do its job quietly.
Choosing the right @type: prefer specific LocalBusiness subtypes
Schema.org stresses using the most specific subtype available rather than the generic parent. The reason is practical. A specific type tells search systems exactly what category you belong to, and it unlocks extra properties that plain LocalBusiness does not have.
Compare two ways to describe the same firm. Marking a plumbing company as LocalBusiness says “this is a local business of some kind”. Marking it as Plumber says what it does, in the vocabulary a search system already understands. That is less ambiguity for the system to resolve, and ambiguity is exactly what structured data exists to remove.
Here are common subtypes and the extra properties they bring:
- Restaurant: servesCuisine, menu, acceptsReservations, so diners can see what you serve and how to book.
- Dentist and other medical types: medicalSpecialty and related health properties that describe the practice.
- HairSalon and BeautySalon: the same base fields as any local business, with a category label that matches how customers search.
- AutoRepair: category clarity for motoring searches, plus the standard address, hours and contact fields.
- Store types such as BookStore or HardwareStore: a retail category that distinguishes you from service-only firms.
Check the schema.org page for your chosen type before you write the block, and choose the available inherited properties that fit your business.
What if nothing matches? Use LocalBusiness and let the other fields, such as your description and sameAs links, carry the detail. What if you are two things at once, say a café that is also a bookshop? You can declare an array of types, for example “@type”: [“CafeOrCoffeeShop”, “BookStore”]. Use that sparingly and only when both descriptions are true on the visible page. A business pretending to be four things reads as less clear, not more.
Service-area businesses and multi-location setups
Not every local business has a shop front. A mobile locksmith, a roofer or a cleaning firm travels to customers and may not want a public street address. For these service-area businesses, consider omitting streetAddress if you do not serve customers at your premises, and publish only the town or region details you are comfortable sharing. Use areaServed to describe the places you cover. Keep the visible page and schema consistent, and include address details you can publish.
Multi-location firms have the opposite problem: too much detail rather than too little. Each physical location should have its own LocalBusiness block on its own page, with that location’s address, phone number, hours and coordinates. A single homepage block describing multiple branches can make it unclear which phone number belongs to which address. Our guide on location page SEO and local evidence covers what visible content should sit alongside each page’s markup.
Where a location has distinct departments, such as a garage with departments that keep different hours, nest them using the department property. Each department can carry its own name, telephone and hours while staying tied to the parent location.
Pro Tip: If a location page could be swapped with another by changing only the town name, it is not ready for its own schema. Add genuine local detail first, then the markup.
Opening hours: formats, seasonal hours and overnight spans
Opening hours cause more validation headaches than any other field. You have two ways to write them. The shorthand property openingHours packs days and times into a text string, using a day-and-time string. The preferred property is openingHoursSpecification, which uses structured objects and handles every awkward case more reliably.
Use these guidelines:
- Prefer openingHoursSpecification for anything beyond a simple, regular week.
- List every day, including days you are closed, so the picture is complete.
- Use a consistent, machine-readable time format for opens and closes.
- Add validFrom and validThrough to describe seasonal hours or temporary closures, such as reduced winter hours or a bank holiday break.
- Write overnight spans carefully. Check how overnight hours are represented in a validator rather than assuming.
- Represent “closed all day” using a convention accepted by your validator.
A quick reference for the main properties:
| Property | Purpose | Example value |
|---|---|---|
| dayOfWeek | Day or days the entry covers | Monday |
| opens | Opening time | A machine-readable time |
| closes | Closing time | A machine-readable time |
| validFrom | Start date of a seasonal entry | A date |
| validThrough | End date of a seasonal entry | A date |
The simple rule: if your hours ever change, use the structured version and date its exceptions. Hard-coded hours that are never revisited are a common way markup can drift out of step with reality.
Example JSON-LD: copy-ready snippets for storefronts and service-area businesses
Replace every value with your own, and check the result in a validator before it goes live. This first example is a single-location storefront. It uses Plumber as the type, with a PostalAddress, geo, hours and sameAs.
{
"@context": "https://schema.org",
"@type": "Plumber",
"name": "Example Plumbing Ltd",
"url": "https://www.example.co.uk/",
"telephone": "Example phone number",
"image": "https://www.example.co.uk/images/shopfront.jpg",
"priceRange": "££",
"address": {
"@type": "PostalAddress",
"streetAddress": "Example Street",
"addressLocality": "Example Town",
"addressRegion": "Example Region",
"postalCode": "EXAMPLE",
"addressCountry": "Example country code"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": "Example latitude",
"longitude": "Example longitude"
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Example day"],
"opens": "Example opening time",
"closes": "Example closing time"
}
],
"sameAs": [
"https://www.facebook.com/exampleplumbing",
"https://www.instagram.com/exampleplumbing"
]
}
The service-area variant drops the street address and names the places covered instead:
{
"@context": "https://schema.org",
"@type": "Locksmith",
"name": "Example Mobile Locksmiths",
"url": "https://www.example.co.uk/",
"telephone": "Example phone number",
"address": {
"@type": "PostalAddress",
"addressLocality": "Example Town",
"addressRegion": "Example Region",
"addressCountry": "Example country code"
},
"areaServed": [
{ "@type": "City", "name": "Example Town" }
]
}
What you must personalise:
- name, url and telephone: exactly as they appear on the page and in your Google Business Profile.
- The @type: swap in the subtype that fits you.
- Coordinates: copy them from a mapping tool with enough precision to identify the location.
- Hours: match your real week, closed days included.
- sameAs and areaServed: only real profiles and only places you genuinely serve.
Common pitfalls when editing: leaving the example’s placeholder phone number in place, forgetting a comma and breaking the whole block, and pasting the storefront block onto a service-area page so a street address you never meant to publish appears.
Where to place LocalBusiness JSON-LD on your website
Put the markup on the page whose visible content it describes. For most firms that means the location page and the contact page. The homepage is a fair home for the block only when it truly represents your single primary location, as with a one-site business.
For several locations, resist the shortcut of one combined block in the site header or on the homepage. Build a separate page for each branch, with that branch’s block on it, and link between them. That structure tells search systems which details belong together, and it gives customers a page that matches what they searched for.
Consistency matters as much as placement. Use this checklist:
- Name, address and phone number in the schema should match the visible text on the same page, character for character where possible.
- The same details should appear on your Google Business Profile and other listings. Our NAP consistency workflow walks through keeping them aligned.
- Hours in the markup should match the hours shown to visitors.
- Each location’s url property should point to that location’s own page.
- No orphan blocks: do not leave markup on pages that no longer describe a real branch.
When the schema and the page disagree, search systems have to guess which one is right, and a guess is how wrong details end up in results.
Testing and validation workflow: tools and monitoring
Test every change, however small. This workflow takes a few minutes and catches nearly everything:
- Run the Rich Results Test on the live URL or a code snippet to check the markup and see which fields Google reads.
- Run a schema validator such as the Schema Markup Validator to check syntax and structure against the vocabulary.
- Compare the output with the page. Read the detected values aloud against what a visitor sees.
- Publish and request indexing for the updated page in Google Search Console.
- Monitor the enhancements reports in Search Console over the following days and weeks.
- Fix errors before warnings. Errors can make a block ineligible, while warnings usually flag missing recommended fields.
Beyond that one-off check, build testing into how your site is maintained. If you deploy through a development pipeline, add an automated test that fetches key pages and confirms the JSON-LD parses and still contains name and address. If you edit through a content management system, add schema to your pre-publish checklist and record when each location’s block was last verified. Regressions usually come from a template change or a plugin update, so a written record of what “correct” looks like saves hours of detective work.
Pro Tip: Keep a plain text copy of each location’s approved block in a shared document. When something breaks, you can compare against a known good version in seconds.
Common mistakes and quick fixes
Most faulty markup fails in the same handful of ways:
- Name mismatch with your Google Business Profile. Fix: choose one trading name and use it in the schema, on the page and in the profile.
- Generic LocalBusiness when a subtype exists. Fix: find the closest type in the schema.org hierarchy and switch to it.
- Malformed opening hours. Fix: move to openingHoursSpecification, use 24-hour times, and retest.
- Thin geo precision. Fix: re-copy coordinates with at least five decimal places.
- An overlong priceRange. Fix: shorten it to a symbol band such as “££” or a short range.
- Conflicting information across pages. Fix: pick the correct set of details, update every page and listing to match, and remove duplicate blocks that describe the same location differently.
Work through them in that order on an existing site.
Author perspective: practitioner checklist and priorities from Blindspot
Most schema advice treats the markup as the achievement. I think that is backwards: the markup is the receipt, and the real work is making the business facts consistent everywhere else. When I review a block, I check four things in order: that the name and address match the profile and the page, that the subtype is as specific as it can be, that hours are written in the structured format, and that the block passes both validators. After that, the fields I would protect above all are name, address, geo, opening hours and sameAs.
A small fix that often pays off: a business listed as a generic LocalBusiness, with hours typed as free text, becomes far easier for search and AI systems to quote once it is changed to its exact subtype with structured hours. It is ten minutes of work, and it removes guesswork for every system reading the page.
— Harry
How we can help you implement and validate your LocalBusiness schema
Getting the code right is only half of it. Our SEO and GEO service covers local SEO audits, schema implementation and ongoing monitoring, so your business details stay accurate as things change. A typical small engagement starts with an audit of your name, address and phone number across the site and your profiles, moves to writing and placing the markup, then validates it and sets up monitoring in Search Console.
If you want a second pair of eyes on your markup, look through our services or contact us for a scoped quote.
FAQ
What is a local business schema?
Local business schema is structured data, usually written as JSON-LD, that describes a physical business to search engines. It states facts such as the business name, address, phone number and opening hours in a format machines can read reliably.
How do I create a local business schema?
Choose the most specific schema.org type for your business, then write a JSON-LD block with at least a name and a PostalAddress. Add recommended fields such as telephone, geo and openingHoursSpecification, place the block on the matching page, and test it in the Rich Results Test and a schema validator.
What are the required properties for LocalBusiness schema?
Google’s local business documentation lists two required properties: name and address. The address must be a PostalAddress object rather than plain text. Everything else is recommended rather than required.
Should every location have its own schema?
Yes. Each physical location should carry its own block on its own page, with its own address, phone number and hours. A single block describing several branches creates conflicting signals for search systems.
Does schema markup guarantee rich results?
No. Valid markup makes a page eligible, but Google decides what to display. Following the rules in its structured data policies is the best way to stay eligible.
