Local business schema markup: the complete guide

Structured data has one job on a local business page: describe, in a format a machine can parse reliably, what a human visitor can already see. It is one of the smaller levers in local SEO, and one of the few that either works or does not — there is no partial credit for markup a parser rejects.

Get that order backwards — markup asserting content that isn’t genuinely there — and schema stops being a technical nicety and becomes exactly the kind of manipulation search engines police. Get it right, and it still does a narrower job than most of the advice selling it implies.

Since 2023, Google has restricted or removed the rich results for two of the schema types local businesses were most often told to add. And on the best current, controlled evidence, schema does essentially nothing to influence whether an AI system decides to cite you. Neither of those facts is a reason to skip structured data. Both are reasons to be precise about what it actually does, because most of the content written about it isn’t.

Start with LocalBusiness, or the most specific subtype that’s actually true

Schema.org’s LocalBusiness type has around thirty more specific subtypes, and Google’s own guidance is to use the most specific one that genuinely applies rather than the generic type — it gives search engines and AI systems a clearer signal about what kind of business is on the page.

The subtypes cluster roughly like this:

Category	Example subtypes
Health and professional services	Dentist, MedicalBusiness, LegalService, FinancialService, ProfessionalService
Food and hospitality	FoodEstablishment, LodgingBusiness
Retail and trades	Store, HomeAndConstructionBusiness, AutomotiveBusiness, DryCleaningOrLaundry
Property and travel	RealEstateAgent, TravelAgency, SelfStorage
Care and family	ChildCare, AnimalShelter
Entertainment and activity	EntertainmentBusiness, SportsActivityLocation
Public and civic	GovernmentOffice, Library, EmergencyService

Source: Schema.org LocalBusiness type hierarchy

If nothing on that list — or the fuller schema.org list — accurately describes the business, LocalBusiness itself is a legitimate fallback rather than a compromise.

According to Google Search Central’s local business structured data documentation, only two properties are formally required: name and address. Everything else is recommended rather than mandatory, but a handful earn their place on almost every local business page:

• telephone, url, priceRange — the basics that make a knowledge panel or business carousel entry usable rather than just present.
• geo (latitude and longitude, to at least five decimal places per Google’s guidance) — worth adding for a fixed premises; reasonably omitted for a genuinely service-area business with no public address.
• openingHoursSpecification — structured day-and-time data, not a paragraph of prose describing hours.
• paymentAccepted, currenciesAccepted — relevant to businesses where this varies or is a genuine customer question.
• menu, servesCuisine — specific to food establishments, and only where a genuine menu URL or cuisine designation exists.

Google’s documentation names one rich result these properties actually feed: knowledge panels and business carousels showing hours, ratings, directions and quick actions when someone searches for the business by name or category.

It is not, on its own, a mechanism for ranking higher — see the FAQ on that point, and the ranking-factor evidence further down this page. What does move visibility in Maps and the local pack is covered in the Google Maps SEO guide.

A star rating on your own homepage is almost never eligible for a rich result

This is the schema mistake worth understanding precisely, because most local businesses make a version of it without realising, and the fix is not what most advice on the topic implies.

Google’s review-snippet guidance states the restriction directly: “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.”

That sentence rules out a specific, very common pattern — a business’s own homepage displaying curated testimonials, wrapped in AggregateRating schema, hoping for stars in the search result. It doesn’t matter whether the testimonials are genuine, whether the average is accurate, or whether the markup is coded correctly. Self-controlled review content on a business’s own site is structurally ineligible, by policy, for the star review rich result, full stop.

What the same guidance does allow, and what most of the visible star ratings in local search results actually come from, is an independent third party the business doesn’t control: overwhelmingly, a Google Business Profile, or another review platform whose review content the business cannot edit.

That’s a genuine opportunity — a complete, accurate, actively-managed Business Profile is doing real work here — but it’s a different asset from anything schema on the business’s own website can produce.

A second restriction from the same guidance matters just as much in practice: Google explicitly prohibits aggregating reviews or ratings pulled in from other websites and republishing them as your own AggregateRating. A business copying its Google rating onto its homepage and marking it up as if the website itself collected those reviews is doing exactly what this rule exists to catch.

None of this means Review and AggregateRating markup is worthless for a local business site — it means the honest use case is narrower than most content on the subject suggests. If a business genuinely, independently collects and displays reviews it doesn’t control the source of (a testimonials page fed by an embedded, unedited third-party review widget the business has no ability to curate, for example), that’s closer to the pattern the guidance permits.

For most local businesses, the practical conclusion is simpler: treat the Business Profile as the review asset, and treat schema on your own site as something that describes what’s visible there — not a shortcut around where the rating actually has to live to be eligible for stars. Getting more of those independent reviews in the first place is a separate discipline, covered in the local review strategy guide.

FAQPage schema stopped earning a rich result in May 2026 — here’s what’s still worth doing

This is worth stating plainly, because a large amount of circulating advice hasn’t caught up with it: FAQPage structured data no longer produces a rich result in Google Search, for anyone, and hasn’t since 7 May 2026.

The path there took three years. Google first restricted the FAQ rich result in September 2023, limiting it to “well-known, authoritative government and health websites” — a change that quietly removed the feature’s value for the overwhelming majority of sites that had implemented it, including essentially every local business.

The restriction became a full deprecation in 2026: Google announced on 8 May that the feature would stop appearing from 7 May, and removed the documentation entirely on 15 June once the change had taken effect. There is, as of this page’s research, no FAQ rich result to earn — not a narrowed one, not a conditional one, none.

That changes what adding FAQPage schema to a local business page is actually for. It is no longer a rich-result play for anyone outside the government and health sites the September 2023 restriction was written for, and treating it as one is now simply out of date.

What it can still contribute is more modest and worth naming honestly: FAQPage markup, applied to a genuine, fully visible FAQ section, gives a clean, unambiguous machine-readable structure to question-and-answer content that a crawler or an AI system’s extraction process might otherwise have to infer from an accordion widget or inconsistent heading structure.

That’s a real but narrower benefit than “gets you a rich result,” and it comes with the same condition every other schema type on this page carries: it has to describe a genuine, standalone FAQ section a visitor can read, not a handful of section headings dressed up as questions to get the markup on the page.

BreadcrumbList: low effort, still useful, still simple

Nothing about breadcrumb markup has changed, and it remains one of the lowest-risk, most straightforwardly useful schema types available.

BreadcrumbList, describing your site’s actual navigation hierarchy — home, category, specific page — is still a supported rich result, low-effort to implement correctly because it should mirror navigation you’ve almost certainly already built, and helps both users and crawlers understand where a page sits within the site. There is no version of this one to get wrong beyond making the markup match the navigation that’s genuinely on the page.

Organization, LocalBusiness and Person aren’t interchangeable

A common shortcut — using generic Organization schema for a business that has physical premises or a defined service area — undersells what’s available. Google’s Organization structured data documentation is explicit on this point: for a business that’s a restaurant, a physical store, or any comparable local presence, the recommendation is to use the most specific LocalBusiness subtype rather than generic Organization markup.

Organization schema has no required properties and is built for administrative identity — a knowledge panel logo, a disambiguated business name, a corporate presence that may have no single physical location at all. It’s the right tool for a company as a legal or corporate entity; it’s the wrong tool for a branch a customer can walk into or a service-area business a customer can call.

Person schema deserves a mention here too, for a different reason: it’s the schema type most directly tied to E-E-A-T — the experience, expertise, authoritativeness and trust signals Google’s quality guidance asks content to demonstrate.

A local business page written or reviewed by a named person — an owner, a practitioner, a specialist — can mark that person up with genuine, verifiable properties: their actual role, a link to a real bio or about page, and sameAs links to professional profiles that are genuinely theirs.

The discipline is identical to everything else on this page: only mark up a person and a role that visibly appear, with links that genuinely resolve to that person, not an aspirational credential or a stock byline nobody on the team actually holds. That is the TRUSTED half of the FOUND, TRUSTED, CHOSEN framework doing its work at the markup level.

Service schema for what you actually, currently, provide

For a business with distinct, well-defined services, Service schema — or Offer where pricing is genuinely public — makes each service independently understandable to something parsing the page, rather than leaving it entirely to prose.

The condition that matters most here is currency, not accuracy at the point of writing. A services list is one of the more common places schema quietly goes stale, because a business stops offering something, updates the visible page copy, and forgets the markup describes the version of the business that existed six months earlier.

If a Service block still lists something the page itself no longer mentions, that’s the same visible-versus-marked-up mismatch as every other mistake on this page — just easier to miss, because nobody thinks of a services list as “schema” in the same way they think of reviews or FAQs.

The mistakes that turn schema from an asset into a liability

Every mistake below shares one root cause — markup describing something other than what’s genuinely on the page — but it’s worth seeing the concrete forms it actually takes, because “don’t mark up invisible content” reads as obvious right up until it’s a specific decision in a specific project.

Star ratings from curated testimonials. Already covered above in detail, and common enough to repeat here as the first entry on this list: AggregateRating built from testimonials the business selected and controls is structurally ineligible for the rich result it’s usually added to chase, regardless of code correctness.

FAQ markup around content that isn’t really a FAQ. A set of blog subheadings, or a list of service bullet points, reformatted as question-and-answer pairs purely to attach FAQPage schema. Even now that the rich result is gone, this pattern still fails the underlying rule — it’s marking up a shape of content that doesn’t genuinely exist as a FAQ a visitor would recognise as one.

Services or offers that have been discontinued. A Service or Offer block still describing something the business stopped doing, priced at a rate that changed, because the schema wasn’t part of the same edit that updated the visible page.

One block of JSON-LD copied across every location page. For a multi-location business, the schema equivalent of the templated location page: the same LocalBusiness block, same address, same hours, pasted onto branch after branch with only the visible page text swapped in. It describes the wrong location on every page but one, which defeats the entire purpose of location-specific markup — the multi-location local SEO guide covers the same failure at the content level, and it’s worth fixing both at once rather than separately.

A fabricated aggregate rating. Not a mismarked genuine rating — an invented figure, “4.9 out of 5 from 230 reviews,” attached to a business that has neither the reviews nor, in some cases, the review platform to have generated that number. This is the clearest case on this list of markup crossing from a technical error into deception, and it’s the pattern Google’s guidelines describe most directly when they prohibit fake reviews and misleading content.

Syntax errors that make the markup silently useless. An unclosed brace, a missing comma, an incorrectly nested @type — errors that don’t throw a visible warning anywhere on the live page, so the schema block simply gets ignored by anything trying to parse it, with no signal to the person who published it that anything is wrong.

This is a pure technical failure rather than a content-integrity one, but it produces the same practical result as never having added the schema at all. It is also the easiest mistake on this list to catch before publishing, and it belongs in the same sweep as the technical checks that actually matter.

Google’s structured data general guidelines state the consequence for the content-integrity failures plainly: a manual action removes a page’s eligibility for rich results specifically — it does not, by that same documentation, directly affect how the page ranks in ordinary search results.

That’s a real distinction worth understanding precisely rather than either dismissing it (losing rich-result eligibility site-wide is a genuine, tangible cost for a business that had earned any) or overstating it into a ranking penalty it isn’t documented to be. Fabricated reviews specifically also sit inside Google’s broader policies against deceptive and manipulated content, which is a separate exposure from the structured-data-specific one.

How to check whether your markup is actually working

Two tools cover this, and both are Google’s own, which matters given how much unofficial “schema checker” content exists that doesn’t reflect current guidance.

Google’s Rich Results Test, run against a live URL or pasted code, shows which rich result types the page currently qualifies for and surfaces any errors in the markup — the syntax mistakes from the section above are exactly what this catches before they cost you anything. Run it after implementing new schema, and again after any change to the content it describes.

Search Console’s structured data reports, under Enhancements, show the same information at the scale of the whole site rather than one page at a time, plus a Manual Actions report where any structured-data penalty would actually appear if one had been issued.

Neither tool checks the one thing that causes the most serious mistakes on this page: whether the content the markup describes is genuinely, visibly present for a human reader.

That check has to be manual, and the practical version of it is simple — whenever hours, pricing, services or review content change on the page, treat updating the corresponding schema as part of the same edit, not a follow-up task that may or may not happen. A quarterly audit, opening the Rich Results Test against a sample of key pages and comparing the markup line by line against what’s actually displayed, catches the drift that accumulates between those edits.

What schema does for the SERP, and what it doesn’t do for AI citation

This is worth separating explicitly, because a large amount of “AI SEO” advice blurs the two together, usually to sell a service built around adding markup.

For classic search results, the picture above holds: correct, current schema earns eligibility for a specific, narrowing set of rich results — knowledge panels, business carousels, breadcrumbs, star ratings from genuinely independent review sources — none of which function as a ranking factor in their own right.

Whitespark’s 2026 Local Search Ranking Factors survey, built from 47 local search experts scoring 187 factors, put “website content marked up in schema” at a raw score of 49, in the bottom third of every factor the panel rated for local pack impact — well below fundamentals like primary Business Profile category and review signals.

It’s worth reading that figure as what it is: a survey of expert opinion on correlation, not a measured causal test, the same caveat that applies to most circulating local ranking-factor claims — but a low score from the people closest to the topic is still informative about where schema sits in the priority order.

For AI systems specifically — ChatGPT, Perplexity, Google’s AI Overviews and AI Mode — the evidence is more direct, and more inconvenient for anyone selling schema as an AI-visibility lever. Google’s own AI features documentation is unambiguous: “You don’t need to create new machine readable files, AI text files, or markup to appear in these features. There’s also no special schema.org structured data that you need to add.” That’s Google Search Central’s current guidance, not a third party’s interpretation of it.

The closest thing to a controlled test of the opposite claim backs the same conclusion. Ahrefs added JSON-LD schema markup to 1,885 pages that were already receiving 100 or more AI Overview citations, tracked the change against 4,000 matched control pages over the following month, and found a small, statistically significant decline in AI Overview citations, with changes on AI Mode and ChatGPT that were statistically indistinguishable from zero.

This site’s own AI local search statistics page carries the full detail, including the study’s own stated limitation — it tested pages already receiving heavy citation, so it says nothing about whether schema helps a previously uncited page earn its first one. Within that scope, though, “adding schema increases AI citation” is a claim a controlled test directly checked and did not find.

One specific number is worth flagging by name, because it circulates widely enough to look authoritative: a claimed 44% lift in AI citations from adding schema and FAQ markup, usually attributed to BrightEdge. No BrightEdge study establishing that figure could be located in the sources reviewed for this page. A real, publicly findable BrightEdge statistic does carry the number 44% — for something unrelated, describing how much more often Google’s AI Overviews criticise brands compared with ChatGPT.

This reads as a straightforward misattribution that hardened into received wisdom through repetition, sitting directly against both Google’s own documentation and the one controlled study available, rather than merely lacking support for it. It does not belong on this page as a reason to add schema, and it shouldn’t appear on any page making that argument.

None of this means structured data is inert for how Google’s systems understand a page. Google’s introduction to structured data states plainly that it uses structured data found across the web “to understand the content of the page, as well as to gather information about the web and the world in general”.

That is a broader, ongoing role in Google’s knowledge systems that AI features draw on indirectly. It is a separate thing from the specific, tested claim that adding markup measurably increases how often an AI system cites that particular page.

The honest synthesis is a narrower recommendation than most content on this topic offers: keep schema accurate because inaccurate structured data can misinform anything reading it directly, including an AI system extracting facts — but don’t add or expand schema specifically because someone has told you it will improve your AI citation rate.

The best available evidence, from Google’s own documentation and the one controlled test that exists, says it won’t. This site’s local SEO for AI search guide covers what the current evidence does suggest actually predicts AI citation, which is a different and shorter list than schema markup.

A worked example: one dentist’s LocalBusiness markup, field by field

The example below is a hypothetical business — Riverside Dental Studio does not exist — built to show a realistic, complete Dentist implementation rather than a minimal one.

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Riverside Dental Studio",
  "url": "https://www.riversidedentalstudio.example/",
  "telephone": "+44 20 7946 0958",
  "priceRange": "££",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "14 Bridge Street",
    "addressLocality": "Meadford",
    "postalCode": "MF1 2AB",
    "addressCountry": "GB"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 51.50735,
    "longitude": -0.12776
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:30",
      "closes": "17:30"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "09:00",
      "closes": "13:00"
    }
  ],
  "paymentAccepted": "Cash, Credit Card, Debit Card"
}

Field	What it does
@type: "Dentist"	The most specific accurate subtype, rather than generic LocalBusiness — gives search engines and AI systems a clearer signal than the generic type alone
name	Must match the practice's actual trading name, exactly as it appears on the page and on the Business Profile
url	The specific page this markup lives on, or the practice's canonical homepage — not a generic domain root if the practice has its own subpage
telephone	The number a visitor would genuinely dial, matching the visible page and the Business Profile — this is a NAP-consistency field, not a decorative one
priceRange	A relative indicator only, and only included because it's genuinely meaningful for a dental practice's positioning; omit it where it would just be guessed
address	Required by Google's own guidance, structured as PostalAddress rather than a single string, so each component (street, locality, postcode, country) is separately machine-readable
geo	Included because this is a fixed premises with a public address; a service-area-only business with no public location could reasonably omit this
openingHoursSpecification	Structured day-and-time data rather than a prose sentence — this is what actually populates an accurate hours display, and what needs updating the moment real hours change
paymentAccepted	Included because it's a genuine, relevant question for this business type; not every business needs this field

Notice what’s absent: no aggregateRating, no review.

If Riverside Dental Studio displays testimonials it curates on its own homepage, adding star-rating markup around them would be exactly the self-serving pattern covered earlier in this guide — ineligible for the rich result regardless of how accurately it’s coded, and worth leaving out rather than adding on the assumption that any schema is better than none.

A working schema checklist

• LocalBusiness or the most specific accurate subtype implemented, with name and address present at minimum
• NAP details matching your website, your Business Profile and this markup exactly
• Review and AggregateRating schema added only where reviews genuinely display, and only where your site doesn’t control the reviews being rated — check the self-serving restriction before adding this, not after
• FAQPage schema, if used, matched to a real, visible FAQ section — understood as a machine-readability aid, not a rich-result mechanism, since that rich result no longer exists
• BreadcrumbList reflecting actual site navigation
• Service or Offer blocks checked against the current, live services list, not a snapshot from when the page was built
• Every location’s LocalBusiness block carries that location’s own real details — no block copied unchanged across branches
• Markup validated with Google’s Rich Results Test, and re-validated after any change to the content it describes
• A process — ideally a shared CMS field, not a manual reminder — for updating schema in the same edit as the hours, pricing or services it describes

Schema markup is a foundation, not a growth lever on its own, and increasingly not even the SERP-visibility lever it once was for FAQ content specifically. See the Local SEO complete guide for where structured data fits into the broader set of technical foundations worth getting right, and what actually moves the numbers around it.

If you would rather start from where the enquiries are actually being lost than from the markup, the growth diagnostic is the faster route to that answer.

Questions

Does schema markup directly improve rankings?

No, by Google's own guidance. Structured data helps search engines understand and correctly represent your content, which can influence how you're displayed — rich results, knowledge panels, correctly labelled business facts — rather than acting as a ranking factor in its own right. Whitespark's 2026 local ranking factors survey scored schema markup 49 out of a possible top score, placing it in the bottom third of 187 factors its expert panel rated for local pack impact.

What schema type should a local business use?

LocalBusiness, or a more specific subtype where one genuinely fits — Dentist, Restaurant, LegalService, RealEstateAgent, and around thirty others defined by schema.org. Layer in BreadcrumbList for site navigation and Review or AggregateRating only where reviews genuinely display on the page, matched to what's actually visible. Use Organization schema instead of LocalBusiness only where the entity is not a physical or service-area local business — Google's own documentation recommends the most specific LocalBusiness subtype for a restaurant or physical store, not generic Organization markup.

Can schema markup hurt my site?

Yes, if it describes content that isn't genuinely present on the page. Google's structured data guidelines are explicit: don't mark up content that isn't visible to readers, and don't mark up irrelevant or misleading content such as fake reviews. The stated consequence is a manual action that removes rich-result eligibility for the page — it doesn't directly affect ranking, but fabricated or invisible markup is exactly what that policy exists to catch, and repeat or severe violations can intersect with Google's broader spam policies.

Is FAQPage schema still worth adding to a local business page in 2026?

Not for the rich result — Google restricted FAQ rich results to well-known government and health sites in September 2023, then deprecated the feature for everyone, with it ceasing to appear in Google Search from 7 May 2026. Documentation for it was removed on 15 June 2026. It's still fine to keep FAQPage markup describing a genuine, visible FAQ section, but the reason to do it now is clean, self-contained content for readers and answer engines to extract — not a rich result, which no longer exists for this markup type.

Why isn't my business's star rating showing up in Google search results?

Almost certainly because of Google's self-serving review restriction. If the entity being reviewed controls the reviews about itself — testimonials curated and displayed on your own website — pages using LocalBusiness or any Organization-type structured data are explicitly ineligible for the star review rich result, regardless of how the markup is coded. That eligibility generally belongs to independent third-party review platforms, principally your Google Business Profile, not your own site.

Does schema markup help a business get cited by ChatGPT, Perplexity or Google's AI Overviews?

The current evidence says no, and Google's own AI features documentation states there's no special schema.org structured data needed to appear in AI Overviews or AI Mode. A controlled Ahrefs study that added JSON-LD schema to 1,885 already heavily-cited pages found a small statistically significant decline in AI Overview citations and changes indistinguishable from zero for AI Mode and ChatGPT. A widely repeated claim that schema produces a 44% citation lift traces to a misattributed statistic with no locatable source.

What's the difference between Organization and LocalBusiness schema?

Organization describes a company in general — its administrative details, logo and knowledge panel identity — and has no required properties. LocalBusiness (or its subtypes) describes a specific physical or service-area presence with genuinely local properties: an address, opening hours, geo-coordinates, a price range. Google's own documentation recommends the most specific LocalBusiness subtype for a restaurant or physical store rather than generic Organization markup, reserving Organization for entities without that kind of local footprint.

How do I check whether my structured data is actually working?

Google's Rich Results Test, run against a live URL or pasted code, shows which rich result types your markup currently qualifies a page for and flags errors that would otherwise be silently ignored. Search Console's structured data reports under Enhancements show the same information at scale across a whole site, plus any manual actions. Neither tool checks that the marked-up content is actually visible on the page — that check is manual, and it's the one most schema mistakes fail.

Does every location need its own LocalBusiness schema, or can one Organization block cover a whole business?

Every location with its own address, hours or phone number needs its own LocalBusiness markup carrying that location's real details. Copying one block of JSON-LD unchanged across every location page, with only the visible page text differing, produces schema that describes the wrong branch on every page except one — the structured-data version of the templated location pages that create ranking and duplicate-content problems generally.

What happens if my hours or address change on the page but I forget to update the schema?

The markup then describes something the page no longer shows, which is precisely the mismatch Google's structured data guidelines exist to catch, and it can misinform anyone or anything reading the schema directly rather than the visible text — including an AI system extracting facts from the page. Treat schema as part of the content it describes, not a separate technical layer: whoever updates the hours table should update the schema in the same change, ideally through a template or CMS field that drives both at once.