The best schema for a service page is a JSON-LD block that describes the business with the most specific LocalBusiness subtype and describes each service the page covers with a Service object. Link the two with the provider property, list the places you serve in areaServed, and mark up only what a visitor can read on the page. That setup tells search engines and AI tools who you are, what you do and where, in a format built for machines. Below you get the types to use, a working example, the service-area rules, the mistakes that cost you, and how to test it all.
TL;DR
- Use JSON-LD, the format Google recommends, and place it on the service page it describes.
- Describe the business with the most specific LocalBusiness subtype, and each service with its own Service object that points back to the business through provider.
- Put cities and regions in areaServed. A service-area business should not invent a separate address for every city page.
- Mark up only what a visitor can actually see on the page: the service name, description, area and business details.
- Test with the Rich Results Test and the Schema Markup Validator before and after every change.
Table of Contents
- What schema markup does for a service page
- Which schema types belong on a service page
- A working JSON-LD example
- How to add service schema, step by step
- Service-area businesses: handling cities and regions
- Pricing and ratings inside service markup
- Does FAQ markup belong on a service page?
- Common mistakes on service page schema
- How to check your markup
- Should schema be on every page?
- Where we can take this work off your plate
- Our view: schema is a trust signal, not a trick
- FAQ
- Sources
What schema markup does for a service page
Schema markup is structured data: a standardized block of code that classifies the content of a page. Search engines read it alongside your visible copy. Google's introduction to structured data describes it as a format for giving information about a page and classifying what is on it. Your page may say "We install tankless water heaters in Phoenix." The markup says, in unambiguous terms, that a plumbing business offers a water heater installation service in the Phoenix area.
For a local service business, that clarity matters in two places.
Google Search and Maps. Google's LocalBusiness documentation explains that when people search for businesses on Search or Maps, results may show a knowledge panel with business details. With LocalBusiness structured data you can tell Google about hours, departments, reviews and more. Markup does not guarantee a panel, but it gives Google clean facts to work with.
AI answers. Tools that summarize the web have to decide which business a page is about and what it sells. Explicit entities, services and areas reduce guesswork. We cover that side of the topic in our posts on schema markup for GEO and why structured data helps SEO and AI visibility.
One point of scope: schema does not replace a strong page. It describes a page that already earns its place with clear copy, real proof and a way to contact you. Think of it as labeling, not as a ranking trick.
Which schema types belong on a service page
Most service pages need two types working together: a business type and a Service type.
The business: the most specific LocalBusiness subtype
Google's Organization structured data guidance recommends using the most specific schema.org subtype that matches your organization. For local businesses it recommends the most specific subtype of LocalBusiness for administrative details. In practice:
- A plumber uses Plumber, not LocalBusiness.
- An electrician uses Electrician.
- A roofer uses RoofingContractor.
- An HVAC company uses HVACBusiness.
- A marketing firm or consultancy that has no better match falls back to ProfessionalService or LocalBusiness, depending on what the vocabulary offers at the time you build.
Browse the LocalBusiness hierarchy on schema.org and pick the narrowest type that honestly fits.
The offering: the Service type
Schema.org defines Service as a service provided by an organization, such as a delivery service or print services. The properties you will use most:
| Property | What it holds | Example |
|---|---|---|
| name | The service as the page names it | Tankless Water Heater Installation |
| description | A short summary matching visible copy | Same-week installation and haul-away of old units |
| serviceType | The category of service | Water heater installation |
| provider | The business offering it (Organization or Person) | Your LocalBusiness node |
| areaServed | Where you deliver it (AdministrativeArea, GeoShape, Place or Text) | Phoenix, AZ |
| offers | A price or offer (Demand or Offer) | Only if the page shows pricing |
| availableChannel | How the service is accessed (ServiceChannel) | Phone, online booking |
Not every property is needed. Fill the ones the page supports and skip the rest.
Keep the two jobs separate
Google's documentation covers LocalBusiness for eligibility in business-related results. Service is a schema.org vocabulary type that helps describe the offering and its relationship to the business. Treat LocalBusiness as the node that carries your name, address, phone and hours. Treat each Service as its own node that references the business. That keeps the business node clean instead of stuffing it with a list of services.
A working JSON-LD example
Here is a service page for a single service, written as one connected graph. Replace the sample details with your real ones.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Plumber",
"@id": "https://www.example.com/#business",
"name": "Example Plumbing Co.",
"url": "https://www.example.com/",
"telephone": "+1-602-555-0100",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main St",
"addressLocality": "Phoenix",
"addressRegion": "AZ",
"postalCode": "85001",
"addressCountry": "US"
},
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "08:00",
"closes": "17:00"
}]
},
{
"@type": "Service",
"@id": "https://www.example.com/water-heater-installation/#service",
"name": "Tankless Water Heater Installation",
"serviceType": "Water heater installation",
"description": "Installation of tankless water heaters for homes, including removal of the old unit.",
"provider": { "@id": "https://www.example.com/#business" },
"areaServed": [
{ "@type": "City", "name": "Phoenix" },
{ "@type": "City", "name": "Tempe" }
]
}
]
}
Three things to notice. The business has an @id, so the Service can point to it with provider rather than repeating the details. The service name and description mirror what the page says. And the cities in areaServed are the ones the page actually lists.
How to add service schema, step by step
1. Inventory what each page says
Write down, for every service page, the service name, a one-sentence description, the area you serve, any price shown, and your business details. This is your source of truth. Markup should only restate what is on the page, so build the markup from this list and not from memory.
2. Pick one page per service
A page that covers one service gets one primary Service object. A hub page that lists several services can carry a Service object for each one it names and describes. Do not add a complete Service object for something the page never mentions.
3. Write the JSON-LD
Use the example above as a template. Google lists JSON-LD, Microdata and RDFa as supported formats and states that JSON-LD is the recommended one. JSON-LD sits in a script tag of type application/ld+json, separate from your HTML, so it is easier to maintain than inline attributes.
4. Place it
Three common routes exist: an SEO plugin or built-in CMS feature, a custom block in the page head or body, or a generator whose output you paste in. A plugin is convenient for sitewide business data, but service-level detail often needs a custom block because each page has different content. Whichever route you use, make sure each service page ends up with exactly one coherent block, not two plugins each adding conflicting versions.
5. Test
Run the page through Google's Rich Results Test and the Schema Markup Validator (more on both below). Fix errors first, then warnings that apply to properties you care about.
6. Keep it in sync
When you change prices, drop a service or add a city, change the markup in the same edit. Out-of-date markup is the quiet failure behind many schema problems, and we wrote about it in our post on schema drift and AI citations.
Service-area businesses: handling cities and regions
Many service businesses travel to customers and run a page per city. The markup rules are simple but often broken.
Use one business entity. If you have a single office, describe it once and reference it from every page. Do not create a new LocalBusiness with a made-up address for each city page. Unless you truly have a physical location in that city, the markup would be inaccurate, and it contradicts your Business Profile.
Put geography in areaServed. Each Service lists the places it covers. Schema.org allows areaServed to hold an administrative area, a geographic shape, a place or plain text, so you can start with city names and add precision where it helps.
Disambiguate when it matters. Many US place names repeat across states. If you list "Springfield" or "Columbia," add the state so the entity is unambiguous. A City object can carry a containedInPlace property pointing to the state:
"areaServed": {
"@type": "City",
"name": "Tempe",
"containedInPlace": { "@type": "State", "name": "Arizona" }
}
Match your Business Profile. The business name, phone number and address in markup should match your Google Business Profile and the footer of your site. If you hide your address on the profile because you serve customers at their homes, do not print it in the markup either. Our guide on optimizing your Google Business Profile and reputation walks through that side.
Be honest about reach. List the areas you really serve. Padding areaServed with fifty cities you never visit does not help a customer, and it weakens the trust signal the markup is supposed to provide.
Pricing and ratings inside service markup
If your page shows a price, you can add an offers property to the Service. Keep it faithful to the page: if the page says "from $199," the markup should say the same thing, with the currency stated. If the page gives no price, leave offers out. For businesses that publish ranges or packages, our guide to structuring service pricing with priceRange and Offers covers the options.
Reviews follow the same rule. Only mark up reviews and ratings that appear on the page and genuinely reflect customer feedback. For B2B providers, our post on B2B service schema and rating markup shows how those pieces fit together.
Does FAQ markup belong on a service page?
If your service page has a real FAQ section, you can mark it up with FAQPage, which schema.org defines as a web page presenting one or more frequently asked questions. The questions and answers must be visible to visitors. Whether FAQ markup influences citations in AI tools is a live question, and we looked at it in our FAQPage schema analysis for Perplexity and ChatGPT. Write the FAQ for customers first: price questions, timing, what is included, and where you work.
Common mistakes on service page schema
- Marking up content that is not on the page. Google's general structured data guidelines are the rulebook for eligibility. Describe what visitors can see.
- Using the generic LocalBusiness type when a specific one exists. The narrowest accurate subtype gives clearer signals.
- One fake location per city. Covered above: it is inaccurate, and inaccurate is worse than nothing.
- Duplicate blocks. A theme, a plugin and a hand-written script each outputting schema can contradict one another. Audit what your page actually outputs.
- Mismatched details. A phone number in markup that differs from the one in the footer or the Business Profile creates confusion.
- Invented services. Add a Service object only when the page names and describes that service.
- Never updating. Markup written once and forgotten drifts from the page.
How to check your markup
Google's structured data overview points to two tools. The Rich Results Test shows which Google rich results a page can generate. The Schema Markup Validator checks any schema.org markup for syntax and vocabulary problems without applying Google-specific rules. Use both: one tells you what Google can use, the other tells you whether the markup is well formed.
A short routine:
- Test the live URL, not just a pasted snippet.
- Fix errors, then review warnings for properties that matter to you.
- Re-test after any template, plugin or theme update.
- Check Search Console's enhancement reports over time for pages Google has processed.
To find out whether a site already has markup, run a few key pages through either tool, or view the page source and search for application/ld+json.
Should schema be on every page?
Not the same schema. Each page should carry markup that fits its content. A sitewide Organization or LocalBusiness block can identify the business, while a service page adds its Service object, a blog post adds Article details and a contact page adds contact information. The test is simple: does the markup describe something the visitor can see on this page? If yes, include it. If no, leave it out.
Where we can take this work off your plate
Schema is one layer in a bigger local visibility setup that also includes your profile, reviews, content and site. We build that across our Local Domination program, which starts at $450 per month, and our E-E-A-T Engine offer for AI search visibility. Each page of your site also needs copy that earns the markup, which is why we pair this work with conversion-focused web design and local SEO. If you want to see where your service pages stand, start with our services overview.
Our view: schema is a trust signal, not a trick
We look at schema through one lens: does it make a business easier to understand, and does that turn into leads? Service pages are where buyers decide, so these are the pages where clean data pays back.
Our approach combines AI-focused strategies with traditional local tactics, because the same facts have to agree everywhere: your page, your Business Profile, your reviews and your markup. When they agree, search engines and AI tools can describe you with confidence.
That is why we treat structured data as part of a system, built from one source of truth and kept current as services and service areas change. A one-time snippet is a start. A maintained system is what supports visibility over months, and it is what we design our programs around.
Diane O'Brien
FAQ
What is the best schema type for a service page?
Use the most specific LocalBusiness subtype for the business, plus a Service object for the service the page describes. Connect them with the provider property. If you are not a local business, use Organization or its best-fitting subtype instead.
Do I need LocalBusiness schema if I travel to my customers?
Yes, you can still describe your business with a LocalBusiness subtype and list the places you cover in areaServed. Use your real business details, and do not create a separate address for each city you serve. Keep the details consistent with your Google Business Profile.
Will service schema make my page show rich results?
Not necessarily. Google documents LocalBusiness structured data for business information in Search and Maps, but eligibility and display are Google's decisions. The markup's main job is to state clearly who you are and what you offer, which helps both search engines and AI tools understand the page.
Which format should I use: JSON-LD, Microdata or RDFa?
Use JSON-LD. Google supports all three formats but recommends JSON-LD, and it is easier to add and update because it lives in its own script block.
How do I know whether my markup is valid?
Test the page URL in Google's Rich Results Test and in the Schema Markup Validator. The first shows what Google can use for rich results, and the second checks general schema.org validity. Re-test after any site update.
Sources
- Introduction to structured data markup in Google Search
- Local business (LocalBusiness) structured data
- Organization structured data
- General structured data guidelines
- Structured data overview and testing tools
- Service, Schema.org type
- LocalBusiness, Schema.org type
- FAQPage, Schema.org type