Local schema: LocalBusiness, Service, and what most agencies skip.

Schema is code you add to your pages that tells search engines exactly what your business is, what it does, and where it operates. For a local business, the three types that matter most are LocalBusiness, Service, and the reviews and location data that hang off them. Most agencies add the first one, half-fill it, and call it done.

That gap is where local visibility leaks. A dental practice with a name and address in its schema looks like a name and address. A dental practice with services, service areas, opening hours, reviews, and the right subtype looks like a business Google can rank and describe. This post walks through what each schema type does, what most agencies skip, and how to check your own pages tonight.

What is LocalBusiness schema and why does it matter?

LocalBusiness schema is structured data that tells search engines your business is a physical, local operation with a name, address, phone number, and hours. It sits in the code of your page, usually as a block of JSON-LD in the head. Users never see it. Google, Bing, and AI answer engines read it to confirm who you are.

Without it, search engines guess. They scrape your footer, cross-reference your Google Business Profile, and hope the pieces match. When they match, you get shown. When they conflict — one phone number in the footer, another in the schema, a third on your Google profile — the engine trusts you less. Trust is the currency of local ranking.

The base LocalBusiness type covers the fundamentals: name, address, phone, hours, URL, and geo-coordinates. That is the floor. Getting the floor right already puts you ahead of most local competitors, because most local sites have no schema at all or have schema that was auto-generated and never checked.

Here is the part agencies skip: the subtype. LocalBusiness has dozens of more specific types beneath it. A law firm should use LegalService. A dentist should use Dentist. A plumber should use Plumber. A San Diego chiropractor using the generic LocalBusiness type is telling Google less than one using the Chiropractor type. The specific type carries meaning the generic one throws away.

What does Service schema add that LocalBusiness misses?

Service schema describes the individual things you do, so search engines can match your pages to searches for those specific problems. LocalBusiness says "we are a law firm in San Diego." Service schema says "we handle immigration appeals, family law, and estate planning." Those are different searches, and Service schema lets you speak to each one.

Think about how people actually search. Nobody types "law firm." They type "green card denial appeal San Diego" or "contested divorce attorney near me." Your homepage carries LocalBusiness schema. Your service pages should carry Service schema that names the exact service, describes it, links it back to the provider, and defines the area served.

A good Service schema block includes the service name, a plain description, the provider (linked to your LocalBusiness entity), the area served, and where relevant, the offer or price range. For a home-services business, this is where you list drain cleaning, water-heater installation, and leak detection as distinct services rather than burying them in a paragraph.

The reason this matters is matching. When Google reads a page that says, in structured data, "this is a Service called Water Heater Installation, provided by ABC Plumbing, serving San Diego County," it has far more to work with than a page that just mentions water heaters in the body text. You are handing the engine the match instead of asking it to infer one.

Most agencies stop at LocalBusiness because it is one block on one page. Service schema means one block per service, on every service page, kept in sync with what you actually sell. That is more work. It is also the work that separates a site that ranks for one keyword from a site that ranks for twenty.

What do most agencies skip?

Most agencies skip the connections between schema types, the review and rating data, and the ongoing maintenance that keeps schema honest. They install a plugin, it stamps a generic LocalBusiness block on every page, and the invoice goes out. Six months later the hours are wrong, the services page has changed, and the schema still says what it said on day one.

Here is the specific list of what gets left behind.

The @id and entity linking. Schema types can reference each other. Your Service block should point to your LocalBusiness block as its provider using an @id. Your LocalBusiness block should reference your logo, your social profiles, and your Google Business Profile. When these connect, search engines see one coherent business instead of scattered fragments. Most implementations leave every block isolated.

AggregateRating and Review. If you have reviews, schema can carry them. AggregateRating shows your average score and review count. Individual Review markup shows specific testimonials. This is what produces the star ratings that appear in some search results. Skip it and you leave those stars on the table. A word of caution: only mark up reviews that genuinely live on your site, and follow Google's rules, or the markup gets ignored or penalized.

areaServed and geo data. A plumber who serves five neighborhoods should say so in schema. A firm with one office but three service cities should define each. Agencies routinely leave areaServed blank, which tells Google nothing about your reach.

openingHoursSpecification done properly. Not just "9 to 5" as free text, but structured hours that account for different days, lunch closures, and holidays. Wrong hours in schema lead to customers arriving at a locked door, and to Google distrusting the rest of your data.

Keeping it in sync. Schema is not a one-time install. When you add a service, change a phone number, or move offices, the schema has to change too. Nobody owns this after launch at most agencies. This is why we treat schema as part of the foundation, not a bolt-on — the same reason we treat site speed as core. A slow site is a sales problem, not an IT problem, and stale schema is the same kind of quiet leak.

How does schema fit with everything else on the page?

Schema supports the page — it does not replace what the page says or how fast it loads. Structured data tells the engine what the content means. The content still has to be there, readable, and served quickly. Schema on a slow, thin page is a label on an empty box.

This is where technical foundations connect. Google reads your schema during the same crawl it uses to judge your page experience. If the page is slow to render, the crawl budget gets spent waiting, and your schema may not get processed cleanly. The three Core Web Vitals numbers that decide if Google bothers are the same numbers that decide whether your structured data gets read on time.

Schema also has to agree with the visible page. If your schema says you are a Dentist open until 6pm and your page copy says you close at 5pm, the mismatch costs you trust. Search engines cross-check. Consistency across schema, page content, footer, and Google Business Profile is the thing that compounds. Inconsistency is the thing that quietly caps your ranking.

We treat this as one system. When we build Search Foundations for a local business, schema, content, speed, and Google Business Profile get aligned together, because fixing one while ignoring the others leaves the leak open. Foundations first. That is not a slogan — it is the order the work has to happen in.

When we rebuilt the foundation for McShanes Solicitors, the schema work was not a separate line item. It was part of making every service page legible to search engines and to the people searching for those services by name. The structured data told Google exactly which legal services the firm handled and where. The content backed it up. The two moved together.

How do I check my own schema tonight?

You can audit your own schema in about fifteen minutes using free tools and a short checklist. You do not need a developer to find the gaps. You need one to fix them, but finding them is on you, and finding them tells you whether your current agency did the work.

Run this checklist:

1. Open Google's Rich Results Test. Paste your homepage URL. See whether any structured data is detected at all. Many local sites come back empty.
2. Check the type. If it says LocalBusiness, look for the specific subtype. Generic LocalBusiness is a missed opportunity. LegalService, Dentist, Plumber, or your actual category is better.
3. Test a service page. Paste a service-page URL, not just the homepage. Look for Service schema. If the service pages carry the same generic homepage block, that is a gap.
4. Confirm the NAP matches. Name, address, and phone in the schema must match your footer and your Google Business Profile exactly. Same phone format. Same suite number. Same spelling.
5. Look for reviews and hours. Check whether AggregateRating and openingHoursSpecification are present and correct.
6. Check the connections. In the raw JSON-LD, look for @id references linking Service to provider and LocalBusiness to sameAs social profiles. If every block stands alone, the entity is not connected.

If most of those come back thin or empty, you now know what your last agency skipped. That is useful. It turns a vague feeling that "our SEO isn't working" into a specific list of fixes.

Where this breaks down

Schema will not rescue a page that has nothing to say. If your service page is one paragraph of vague copy, perfect Service markup will not make it rank, because there is no substance for the engine to reward. Schema describes value — it does not create it. And no amount of structured data offsets a business with no reviews, wrong hours, and a site that takes six seconds to load. Fix the real thing first. Then label it correctly.