Use Service schema when a page visibly describes a real service provided by a specific business or location. Connect the service to that provider, add only facts the page can support, and treat the markup as a description of the page rather than a shortcut to rankings or AI recommendations.
That distinction matters for a multi-location HVAC company, plumbing rollup, restoration group, med spa, or franchise. LocalBusiness markup identifies the branch. Service markup can identify what that branch actually does. Neither can rescue a thin location page, invent a service area, or force Google or an answer engine to feature the business.
Important
Page truth comes first. If a customer cannot verify the service, provider, coverage, and next step on the page, do not try to solve the gap inside JSON-LD.
What Service schema actually says
Schema.org defines Service as work performed by one party for another. Its vocabulary can describe a service type, provider, area served, hours available, offer, and URL. The provider can point to an Organization or LocalBusiness entity elsewhere in the same JSON-LD graph.
Google's LocalBusiness documentation has a different job. It explains how Google uses supported local business markup in Search and which properties apply to that feature. Google also says its Search Central documentation, not the full Schema.org vocabulary, is the definitive source for Google Search behavior.
In practice, a valid Schema.org type and a Google Search feature are not the same thing. Service is useful vocabulary for describing an offering. It is not a standalone promise that Google will show a special result for that service.
If your team is still deciding what each branch page should contain, start with the location page checklist. If the operational facts are sound but the code is inconsistent, Cheers' website optimization platform is built to audit and manage that layer across locations.
Start with page truth, not JSON-LD
Before choosing properties, answer four questions in ordinary page copy: What service is offered? Which location or organization provides it? Where is it available? What can the customer do next?
An HVAC branch page might say that its Phoenix team repairs heat pumps, serve a defined set of nearby cities, explain after-hours coverage, and link to one booking path. A med spa location page might list the treatments available at that clinic without implying that every provider performs every procedure. A restoration branch might separate water mitigation, mold remediation, and reconstruction because licenses, response rules, or coverage differ.
Those examples are not requests for longer keyword lists. They are requests for operational specificity. The visible page should carry the service name, provider, coverage, proof, and customer action. The structured data can then repeat those relationships in a machine-readable form.
For teams that need the code format explained first, What Is JSON-LD? covers the syntax and deployment model.
How Service and LocalBusiness should connect
The cleanest pattern is usually one graph. Give the location a stable @id, then point each Service entity back to that provider. The service URL should resolve to the page where a customer can read about the offering.
A shortened fictional example for a Phoenix HVAC branch looks like this:
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "HVACBusiness",
"@id": "https://example.com/phoenix#location",
"name": "Example Heating Phoenix",
"url": "https://example.com/phoenix"
},
{
"@type": "Service",
"name": "Heat pump repair",
"serviceType": "Heat pump repair",
"provider": {
"@id": "https://example.com/phoenix#location"
},
"areaServed": {
"@type": "City",
"name": "Phoenix"
},
"url": "https://example.com/phoenix/heat-pump-repair"
}
]
}The relationship is more important than the volume of properties. The Service points to the branch that performs the work. The service page points customers to a real offering. The branch identity stays separate from the parent brand, even when the corporate site publishes both records.
Use a specific LocalBusiness subtype when it accurately describes the location. A plumbing branch can use Plumber. A clinic might use a relevant medical or health subtype if the vocabulary and visible business facts support it. Do not choose a type merely because it sounds more valuable.
For a multi-location brand, stable identifiers reduce accidental fragmentation. The same location @id can be referenced by its services, page, parent organization, and other structured entities. The sameAs guide for local businesses explains the narrower job of linking a known entity to authoritative external profiles.
What Service schema cannot do
Service markup cannot prove service quality, eligibility, availability, or local prominence on its own. It cannot make a branch eligible for a Google Business Profile, turn a service area into a staffed location, or establish that a technician holds a required license. Those claims need visible facts and appropriate public evidence.
Google's structured data policies say markup must represent the main content of the page, be up to date, and not mislead users. Google also states that valid markup does not guarantee a rich result.
The same restraint applies to AI Search. Google's current AI Search guidance says no special Schema.org markup is required for AI Overviews or AI Mode. Google recommends continuing normal structured data work because it can support Search features, not because it guarantees inclusion in a generated answer.
Be especially skeptical of claims that adding Service schema caused a ranking lift or AI citation. A page launch often changes copy, internal links, crawl paths, speed, and structured data together. Without a controlled test, one before-and-after result cannot isolate schema as the cause.
Decide where the markup belongs
On a dedicated service page
Use Service markup when the page explains one offering in enough detail to help a customer decide. The provider should be the organization or location responsible for the work. Add areaServed only if the page states that coverage clearly.
On a location page
A location page can include several Service entities when it visibly lists the services that branch performs. Keep the list selective. Hundreds of nearly identical service objects can become a maintenance problem and do not make a generic page more useful.
On a combined location and service page
A combined Phoenix heat-pump repair page can describe both the local provider and the specific service. This is often the clearest fit when availability, proof, hours, or the booking path genuinely changes by market.
On a corporate page
Use the parent organization as provider only when the organization, rather than a specific branch, is the accurate service provider. If fulfillment and booking happen locally, connect the service to the location that owns that customer experience.
Roll it out across 20 to 500 locations
The hard part is not producing one valid block of JSON-LD. It is keeping hundreds of page and markup combinations aligned with operations. A practical rollout has six controls:
- Maintain one approved record for each location, service, coverage rule, URL, and booking path
- Create a location-by-service matrix that operations can review before marketing publishes it
- Generate visible page facts and structured data from the same approved source when possible
- Omit services a branch cannot reliably deliver, even if another location offers them
- Validate a sample from each template and market type before a portfolio release
- Recheck changed URLs in Search Console and monitor customer actions, indexing, and search appearance separately
That source record should have a named owner. Marketing can manage templates and measurement, but operations needs to approve service availability. A regional leader should be able to answer why one branch offers a service and another does not.
Acquisitions create a common failure point. The acquired company may keep old service pages while the parent brand publishes new location markup. Before adding more entities, decide which URLs are canonical, which business fulfills the work, and when the old record should redirect.
A 30-day implementation plan
Week 1: audit page truth
Sample high-revenue and high-risk locations. Compare each page with the booking flow, branch service matrix, Google Business Profile, and operating rules. Record missing or conflicting facts before touching schema.
Week 2: design the graph
Define stable @ids for the parent organization and locations. Choose the Service fields the pages can support. Build one storefront example, one service-area example, and one exception before extending the template.
Week 3: validate the release
Use the Schema.org Validator to check vocabulary and graph relationships. Use Google's Rich Results Test to see which Google-supported structured data the page exposes. Fix errors and misleading fields, then deploy a small group.
Week 4: inspect and measure
Inspect deployed URLs in Google Search Console. Confirm that the rendered page and JSON-LD agree. Track indexing and search appearance, but keep calls, forms, bookings, and revenue in separate outcome reports. If an AI answer cites the page, record the prompt, engine, date, and cited URL rather than crediting schema alone.
Service schema is worth using when it makes a true page easier to interpret and govern. The useful question is not whether every branch can add more markup. It is whether every marked-up service traces back to a visible offer, a real provider, a defined market, and a working customer path.
Sources
- Schema.org: Service. Defines the Service type and properties such as provider, areaServed, hoursAvailable, offers, and url.
- Schema.org: LocalBusiness. Defines the local business vocabulary and more specific business types.
- Google Search Central: Introduction to structured data. Explains how Google reads structured data, recommends JSON-LD, and distinguishes Google Search documentation from the wider Schema.org vocabulary.
- Google Search Central: LocalBusiness structured data. Documents Google's supported local business feature and implementation guidance.
- Google Search Central: General structured data guidelines. Supports the visible-content, accuracy, and no-guarantee requirements.
- Google Search Central: AI features and your website. States that AI Overviews and AI Mode do not require special schema markup.
- Schema.org Validator. Checks Schema.org vocabulary and graph structure.
Amadeus Peterson is the CTO & Co-Founder of Cheers, the local search platform for multi-location service businesses.