Almost every service business I audit has the same schema decision sitting unmade in their code: service schema vs local business schema, and which one should actually anchor the site. Most sites don't decide. They apply LocalBusiness because a plugin defaulted to it, or they apply Service because a blog post said to, and nobody asks whether the choice matches how the business actually operates. That mismatch doesn't throw an error. It just describes the business slightly wrong to every system reading it.
Why this schema question actually matters
Schema.org's type hierarchy exists to let you tell Google specifically what kind of entity a page describes, and the two types get confused constantly because they overlap in places and diverge in ways that aren't obvious from the property lists alone. LocalBusiness is built around a physical location a customer visits or that visits them within a defined area. Service describes an offering, independent of whether that offering is tied to one location, ten locations, or none at all. A business that picks the wrong one isn't lying to Google, exactly, but it is handing over a structurally imprecise description of itself, and Google's systems build a model of your business partly from how coherently your markup lines up with your actual content and behavior.
I see this most often with two kinds of businesses: a consultancy that serves clients nationally but still describes itself with LocalBusiness because that's the schema the theme shipped with, and a multi-location business that only marks up its headquarters with LocalBusiness and never mentions the other locations in markup anywhere. Both are fixable, and fixing them is less about ticking a technical box and more about making the markup say what's actually true.
What LocalBusiness schema is built to describe
LocalBusiness assumes a physical presence customers can locate: an address, a service area if you travel to customers, hours of operation, and a geographic anchor point. Its subtypes get specific fast. ProfessionalService, HomeAndConstructionBusiness, LegalService, and dozens more exist because Google wants the precision of a specific vertical when one applies, rather than the generic parent type. A law firm using plain LocalBusiness instead of LegalService or Attorney is leaving specificity on the table that could otherwise help Google match the page to more precise queries and local pack results.
The properties that matter most for LocalBusiness are the ones that anchor it geographically and operationally: address, geo coordinates, telephone, openingHours, and areaServed if you travel to clients rather than the reverse. A business that fills in the type correctly but skips areaServed is telling Google it operates from a single point and nowhere else, which undersells a business that actually drives to clients across a metro area or a multi-county region.
Work With John
Your site should be your best salesperson. If it is not, that is a fixable problem.
I work with US service businesses and B2B brands to build SEO systems that produce consistent, compounding leads. I will tell you exactly what is broken. No pitch.
Book a free strategy callWhat Service schema is built to describe and where it differs
Service schema describes what's being offered, not where the offering happens. It connects to a provider (which can itself be a LocalBusiness or an Organization), and it can carry its own properties: serviceType, areaServed, offers, and a description distinct from the business's general description. The distinction that trips people up: Service is meant to sit alongside a business entity, describing one thing that business does, not to replace the business entity itself.
This is why a services page for a single offering, say tax preparation on an accounting firm's site, usually benefits from Service markup nested under or connected to the firm's LocalBusiness or ProfessionalService entity, rather than either type standing alone as a substitute for the other. Get this wrong and you end up with a services page that schema-wise looks like an orphaned offering with no clear provider, which is a weaker entity signal than a clearly connected pair.
The mistake of picking one schema type for the whole business
The failure I run into constantly: a business with six distinct services (say, an HVAC company doing installs, repairs, maintenance contracts, and duct cleaning) marks up its homepage as a single LocalBusiness entity and stops there. Every service page on the site either repeats the same LocalBusiness block verbatim or has no schema of its own at all. That approach describes the business once and describes none of what it actually sells.
The better structure treats the business as one LocalBusiness (or an appropriate subtype) and each core service as its own Service entity connected back to that provider through the makesOffer or provider property, ideally matched to its own page rather than crammed onto the homepage. This gives Google a map of what the business does that mirrors how a visitor actually navigates the site: one entity, several offerings, each with its own description and, where relevant, its own areaServed and price range. It's more setup work than dropping a single generic block sitewide, but it's the difference between markup that describes a company name and markup that describes a company's actual services.
How to structure schema when you offer services from a location and also serve a wider area
The hardest case is the one a lot of service businesses actually are: a physical office in one city, but work performed across a broader region, sometimes with a mix of in-person and remote delivery. The pattern that holds up here is keeping LocalBusiness anchored to the real physical address (never fabricate a location for a service area you don't operate from), and using areaServed on both the LocalBusiness entity and the individual Service entities to define the actual geographic reach. If the business genuinely serves multiple named regions, list them specifically rather than a vague radius value, since named areaServed values give Google clearer entities to match against a searcher's location.
A common overcorrection I see: businesses that serve a wide area start listing every city they've ever done a job in in the areaServed property, sometimes dozens of place names. That's not more accurate, it's noisier, and it risks reading as an attempt to rank for locations the business doesn't meaningfully serve, which is a pattern Google's local algorithms have gotten better at discounting over time. A tighter, honest list of the regions you actually operate in consistently outperforms an exhaustive one padded for reach.
What multi-location businesses get wrong on top of this
Everything above gets harder once a business has more than one physical location, because now there's a decision about whether each location needs its own LocalBusiness entity or whether one Organization entity with multiple location subtypes covers it. The pattern that actually works: each location that has its own address, phone number, and hours gets its own LocalBusiness entity, connected to a parent Organization through the parentOrganization or subOrganization properties, or through department if the locations operate as branches of one legal entity. Services then attach to whichever location or locations actually provide them, rather than being duplicated identically across every location page regardless of whether that location offers all six services or only two.
I've seen multi-location sites solve this by literally copying the exact same address-and-hours-agnostic Service blocks onto every location page, which produces schema claiming every location offers every service, even when the actual visible page content says otherwise for a location that only handles two of the six. That's the same visible-versus-markup mismatch that causes trouble with reviews and pricing, just applied at the location level instead of the service level. The fix is the same discipline: markup should describe what's true on that specific page, not a template value copied sitewide for convenience.
A worked example: a multi-service consultancy that had the types backwards
A consulting business I looked at had one LocalBusiness block on its homepage, correctly formatted, address correct, hours correct. Every one of its six service pages, though, repeated that exact same LocalBusiness JSON-LD verbatim, changing nothing but the page URL in the block's mainEntityOfPage property. Google's Rich Results Test flagged nothing, because the syntax was fine on every page. But structurally, the site was telling Google it had one location and no distinguishable services, when the actual site had detailed, differentiated service pages a visitor could read easily.
The fix was building a distinct Service entity for each of the six offerings, each with its own serviceType and description pulled from that page's actual content, each referencing the same parent LocalBusiness through the provider property. Nothing about the visible page changed. What changed was that the site's machine-readable structure finally matched its actual structure: one business, six distinguishable services, each describable and matchable to a different kind of search query. That kind of clarity is part of what I mean when I talk about the technical layer that decides visibility without a visitor ever noticing it's there.
How this connects to entity clarity, not rankings directly
None of this is a ranking lever you pull and watch move a position. What it does is give Google's systems, and increasingly AI-driven search features, a cleaner, more specific model of what your business is and does, which affects eligibility for the SERP features that do influence clicks: local pack inclusion, service-specific rich results, and how confidently an AI summary can describe your business correctly. That's an entity clarity question more than a rankings question, and it sits close to the trust signals I cover in what E-E-A-T actually measures, since a business that describes itself precisely and consistently across its markup is demonstrating exactly the kind of coherence those signals reward.
If you're still deciding whether schema is worth the setup time at all, it's worth reading this alongside does schema markup actually help SEO, which covers what these signals can and can't move on their own. And if your markup already exists but you're not sure it's accurate, the schema markup mistakes that undermine sites like this are usually hiding in exactly the kind of copy-pasted blocks described above. Both are part of the broader Technical SEO work I cover regularly, and it's the kind of structural audit I run as part of ongoing SEO engagements for service businesses trying to get their site's technical layer to actually match what they do.
Getting Service and LocalBusiness schema right isn't complicated once you separate the two questions they answer: where the business operates, and what it actually sells. Most sites only ever answer the first one, and only partially. Answering both, specifically and honestly, is what turns schema from a checkbox into an accurate description of the business a machine can actually use.
