46% of all Google searches carry local intent. That is nearly half of every search, every single day, from people looking for a business in their area (Google, via Search Engine Roundtable, 2018; supported by BrightLocal, 2025).
Most of those searches end at Google’s summary of your client’s website. Not the website itself. Google’s version of it.
And that summary is only as accurate as the data you give Google to work with.
Local schema markup is how you control that data. Done right, it tells Google exactly who the business is, where it operates, what it offers, and how customers have rated it. The result is richer search listings, stronger local pack presence, and more qualified clicks.
Here is what this guide covers:
- What local schema markup is and how it communicates with search engines
- The core LocalBusiness schema: required properties, recommended properties, and a complete code example
- How AggregateRating and Review schema work – including what Google actually allows
- Service Area schema for businesses that travel to their customers
- Three ways to implement schema (no-code, plugin, and manual)
- How to test and validate your markup before it goes live
- The most common mistakes that make schema invisible or worse, penalized
What is local schema markup?
Schema markup is structured data code added to a webpage. Its purpose is simple: it translates your page into a format search engines can read clearly and without guesswork.
Google, Bing, and Yahoo built Schema.org in 2011 as a shared vocabulary for this purpose. When you use it, you are speaking directly in the language they process.
Local schema is the subset of Schema.org designed for businesses with a physical location or a defined service area. It describes your business name, address, phone number, operating hours, service categories, and more.
The format Google recommends is JSON-LD (JavaScript Object Notation for Linked Data). It lives inside the <head> tag of your page and does not touch your visible HTML content. That separation is what makes it the cleanest option to deploy and maintain.
How does it appear in search results?
Google can read local schema data to produce rich results: star ratings, business hours, and address details shown directly in the SERP. Not every implementation earns a rich result, but having structured data in place is a prerequisite for getting one.
Why local schema matters
You may already be managing Google Business Profiles, building citations, and working on reviews for your clients. That is all the necessary work. Schema fills a specific gap left by the rest of your local strategy.
76% of people who conduct a local search visit a related business within 24 hours. Those are fast decisions made on fast information. Schema is what ensures Google surfaces accurate information at that exact moment.
Here is what it does for local visibility:
- Rich results eligibility. Star ratings, hours, and address details can appear directly in search results, making your listing more informative at a glance. This increases click-through rates for listings that would otherwise look identical to competitors.
- Local Pack reinforcement. Schema confirms the NAP data (name, address, phone) that Google’s local ranking algorithm uses to verify business identity. Inconsistency between your schema and your Google Business Profile creates ambiguity that Google does not reward.
- Voice search and AI Overview readiness. Structured, accurate data is how AI-generated summaries and voice assistants pull correct business details. The businesses showing up in those results have done the groundwork.
- Trust in accuracy. 62% of consumers say they would avoid a business if they found incorrect information about it online. Schema keeps your data accurate and consistent within Google’s understanding of the site.
LocalBusiness schema: the foundation
This is where every implementation starts. LocalBusiness is the primary schema type for any business with a physical presence.
Choosing the right subtype
LocalBusiness has over 90 subtypes listed on Schema.org. Using the correct one gives Google better context than the generic type alone.
Examples:
- Restaurant for food businesses
- MedicalClinic for healthcare providers
- LegalService for law firms
- AutoRepair for mechanics
- HomeAndConstructionBusiness for contractors
Always use the most specific type available. Using LocalBusiness when Dentist exists is a missed opportunity. Search engines read specificity as confidence.
Required and recommended properties
| Property | Status | What it contains |
| @context | Required | Set to “https://schema.org“ |
| @type | Required | Your specific business type |
| name | Required | Official business name |
| address (PostalAddress) | Required | Street, city, postal code, country |
| telephone | Recommended | Phone with country code |
| url | Recommended | Official website URL |
| openingHoursSpecification | Recommended | Hours for each day of the week |
| geo (GeoCoordinates) | Recommended | Latitude and longitude |
| image | Recommended | Business photo or logo URL |
| priceRange | Recommended | Price level indicator (e.g., “$$”) |
| aggregateRating | Recommended | Customer rating data |
| sameAs | Recommended | Links to verified social profiles |
Full JSON-LD example
This is a complete, copy-ready LocalBusiness block. Paste it inside the <head> tag of the relevant page and update the values:
<script type=”application/ld+json”>
{
“@context”: “https://schema.org”,
“@type”: “LocalBusiness”,
“name”: “Greenleaf Landscaping”,
“url”: “https://www.greenleaflandscaping.com”,
“telephone”: “+1-555-234-5678”,
“image”: “https://www.greenleaflandscaping.com/images/exterior.jpg”,
“priceRange”: “$$”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “142 Garden Ave”,
“addressLocality”: “Portland”,
“addressRegion”: “OR”,
“postalCode”: “97201”,
“addressCountry”: “US”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: 45.5231,
“longitude”: -122.6765
},
“openingHoursSpecification”: [
{
“@type”: “OpeningHoursSpecification”,
“dayOfWeek”: [“Monday”, “Tuesday”, “Wednesday”, “Thursday”, “Friday”],
“opens”: “08:00”,
“closes”: “18:00”
},
{
“@type”: “OpeningHoursSpecification”,
“dayOfWeek”: “Saturday”,
“opens”: “09:00”,
“closes”: “14:00”
}
],
“sameAs”: [
“https://www.facebook.com/greenleaflandscaping”,
“https://www.instagram.com/greenleaflandscaping”
]
}
</script>
Multi-location businesses
If a client operates from multiple locations, create a separate schema block for each one. Each location page includes its own JSON-LD with address, phone, and hours. Never stack multiple addresses in a single schema block – Google treats it as a single entity and gets confused. [Which, as any SEO knows, is never good for visibility.]
Review schema: adding ratings the right way
The star ratings you see inside Google search results come from AggregateRating schema. It is one of the most visible schema types in local SERPs and one of the most frequently misused.
What Google actually allows
This is the part most guides leave out or bury.
Google’s review structured data guidelines are specific: you can only mark up reviews that are hosted on your own website. First-party reviews, collected by you and displayed on your pages, are eligible.
You cannot mark up reviews from Google, Yelp, Trustpilot, or any third-party platform. Doing so violates Google’s structured data policies and can result in a manual action against the page.
If your client does not yet have on-site reviews, add a review collection mechanism before implementing this schema type.
AggregateRating code example
Add this block inside your LocalBusiness schema, alongside the other properties:
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.8”,
“reviewCount”: “127”,
“bestRating”: “5”,
“worstRating”: “1”
}
Keep ratingValue and reviewCount accurate and up to date. Google cross-references these values against the actual reviews rendered on the page. If the numbers do not match what a crawler can verify, the markup gets ignored. Or worse, flagged.
Build a process for updating this as review counts change. It should not be a one-time setup.
Service Area schema: for businesses that go to their customers
Not every local business serves clients at a fixed address. Plumbers, mobile groomers, cleaning companies, and delivery services travel to the customer. The Standard LocalBusiness schema does not fully describe this model.
The areaServed property does.
How to define a service area
You can define service coverage using a named place – a city, state, or country – or a geographic boundary using GeoCircle. You can also combine both in the same block:
<script type=”application/ld+json”>
{
“@context”: “https://schema.org”,
“@type”: “LocalBusiness”,
“name”: “Swift Plumbing Services”,
“url”: “https://www.swiftplumbing.com”,
“telephone”: “+1-555-789-0123”,
“areaServed”: [
{
“@type”: “City”,
“name”: “Seattle”
},
{
“@type”: “City”,
“name”: “Bellevue”
},
{
“@type”: “GeoCircle”,
“geoMidpoint”: {
“@type”: “GeoCoordinates”,
“latitude”: 47.6062,
“longitude”: -122.3321
},
“geoRadius”: “30000”
}
]
}
</script>
The geoRadius value is in meters. 30,000 meters covers a 30km radius, which is a reasonable starting point for most service-area businesses.
One practical note: many SABs choose not to display their physical address publicly on their Google Business Profile. If your client has made that choice, reflect it in the schema too.
Either leave out the address field entirely or link hasMap to the GBP URL and nothing more – consistency between the GBP and schema data matters.
How to implement local schema markup
There are three routes. Pick the one that fits the technical setup.
- Manual JSON-LD is the most precise method. Copy your completed block and paste it inside the <head> tag of the relevant page. Most CMS platforms have a custom HTML or script injection field in the theme settings or individual page settings that handles this without touching core template files.
- WordPress plugins work well for clients who manage their own sites. Rank Math generates LocalBusiness schema through its settings panel. Yoast SEO supports it with the Local SEO add-on. Schema Pro gives you more granular control at the page level if you need different properties across different pages.
- Google Tag Manager is the right choice for larger sites or multi-location client accounts. Create a Custom HTML tag, paste your JSON-LD, and set the trigger to fire on the relevant pages. It lets you deploy and update the schema across dozens of pages without having to touch each one individually.
One rule that applies to all three methods: do not limit the schema to the homepage. Every relevant page benefits. Your homepage carries the main LocalBusiness block. Individual service pages can carry service-specific schema. Location pages each get their own address and hours.
Testing and validating your schema
Do not publish the schema and assume it works. Test first.
Google’s Rich Results Test (search.google.com/test/rich-results) is the primary tool. Paste a URL or paste the code directly. It tells you which rich results the page qualifies for, and which properties are missing, incorrect, or triggering warnings.
Schema.org Validator (validator.schema.org) checks your markup against the official Schema.org vocabulary. It catches property-level errors that the Rich Results Test sometimes does not flag.
Google Search Console is how you monitor performance after deployment. The Enhancements tab shows which pages have valid schema, which have warnings, and which have errors. Check it 2 to 4 weeks after implementation, after Google has had time to recrawl the pages.
Common schema mistakes that reduce visibility
These errors consistently appear in local SEO audits.
Using the generic type when a specific one exists. If the client is a dentist, “@type”: “Dentist” is better than “@type”: “LocalBusiness”. Always go specific.
NAP inconsistency. The name, address, and phone in your schema must match exactly what appears on the Google Business Profile and the site’s contact page. Minor differences – “Ave” versus “Avenue,” “St.” versus “Street” – create ambiguity in Google’s entity matching. It sounds pedantic. It costs rankings.
Marking up third-party reviews. Already covered above, but this one trips up experienced practitioners, too. Only first-party, on-site reviews are eligible under Google’s structured data guidelines.
Schema only on the homepage. Location, service, and contact pages all contain relevant business data. They all benefit from their own schema blocks.
Outdated data after business changes. The schema does not update itself. When a client changes their hours, moves to a new address, or gets a new phone number, the schema needs to be updated too. Build a review step into your client onboarding checklist.
Where to go from here
Local schema is not a tactic that will move rankings overnight. Anyone who tells you otherwise is selling something you do not need.
What it does is give Google accurate, structured information about the business. That leads to richer listings, fewer situations where Google shows the wrong address, and stronger NAP consistency across the full local SEO picture.
Start with the LocalBusiness block. Get the required properties right before adding the optional ones. Test everything in the Rich Results Test. Check Search Console four weeks later.
The SEO professionals consistently winning in local search are rarely the ones doing the most exotic things. They are the ones who do the foundational work completely, accurately, and without shortcuts.
This is one of those foundational pieces. You already have the code. Now implement it.
