Start with the page facts
A service page can name an offer while leaving important details unresolved. The heading says “strategy”, the body describes several different engagements, the footer names the provider, and a location appears only in a testimonial. Adding Service schema markup at that point would encode the ambiguity rather than solve it.
Start with the page a buyer can read. It should identify the service, who provides it, what the engagement covers and any location or commercial terms that matter. Our guide to structuring a page for search and AI systems covers that wider page anatomy. Service schema has the narrower job of describing the service that the page already makes clear.
Google's introduction to how structured data markup works says structured data should describe the page it appears on. It can make a page eligible for a supported search feature, but valid markup doesn't guarantee that Google will show one. Every field in the graph therefore needs a visible source on the page.
Give the Service node one clear job
Schema.org defines Service as a service provided by an organisation or person. Its vocabulary includes serviceType, provider, areaServed, offers and hasOfferCatalog. Those properties let a page identify an offer, connect it to its provider and describe supported coverage or commercial structure.
Vocabulary support and Google feature support are separate questions. Service is a valid Schema.org type, but Google doesn't document a standalone Service rich result. Don't use it to promise rankings, rich snippets, Knowledge Panels, Maps visibility, Business Profile gains or AI citations.
AI search doesn't change that boundary. Google's current guidance for AI features and websites says no special Schema.org markup is required for AI Overviews or AI Mode. The ordinary foundations still apply, including crawlable content and structured data that matches visible text.
The practical goal is accuracy. A Service node gives parsers a consistent expression of a service page's facts. It doesn't create facts the business hasn't published.
Connect the service to its provider
The service and the business perform different jobs in a connected graph. A Service node describes the page-specific offer. An Organization or eligible LocalBusiness node describes the provider's identity and business or location facts. Schema.org's provider property accepts an organisation or person, so the Service node can reference the provider rather than repeating its details.
Google's LocalBusiness structured data documentation focuses on business and location information such as the business type, address and opening hours. Those are provider facts. They aren't a substitute for a Service node that identifies what an individual service page offers.
Use a stable provider @id only when the site already emits and governs that identifier. The same ID should refer to the same entity across the site. Our Organization schema implementation guide explains how to choose and maintain that provider node. If no governed provider ID exists, establish it in the publishing template before referencing it from service pages.
That distinction prevents a common implementation problem. Copying the full provider object into every service template gives names, URLs and locations more places to drift. A reference keeps the service page connected to one maintained identity.
Map visible claims to schema properties
Consider a fictional Australian consultancy called Southbank Strategy Studio. Its service page visibly offers a “Website positioning workshop”, says the studio provides it to businesses in Western Australia, and lists a fixed workshop fee of AUD 2,400. The example is fictional, but the evidence rule is real.
name should match the service named in the H1 or service heading. serviceType can express the recognised type of service in plain text. provider should reference the studio's governed ID. areaServed can state Western Australia because the page clearly states that coverage. An Offer can carry the fee only because the same price and currency are visible to a reader.
If the page says “contact us for a proposal”, don't invent a price. If delivery is available in Perth but the page never says so, don't add Perth for local relevance. Ratings and reviews belong only when the page shows genuine, policy-compliant evidence for the marked-up item. A complete-looking graph with unsupported fields is less reliable than a smaller truthful graph.
The same rule applies to offer catalogues. Schema.org defines hasOfferCatalog as a relationship to an OfferCatalog. Use it when the visible page presents a real set of service options that the business maintains. A page about one workshop usually needs one Service and, when appropriate, one Offer. It doesn't need a catalogue created for markup completeness.
JSON-LD can't repair an unclear heading, hidden condition or unusable interaction. Fix those issues in the page and template first. The website accessibility and SEO guide explains why semantic headings, labels and readable text matter to people and machines.
Build a connected JSON-LD example
The graph below is copy-adaptable, not copy-ready. Southbank Strategy Studio and its URLs are explicitly fictional. Assume the page visibly contains the service name, description, Western Australia coverage and AUD 2,400 fee. Assume the separate organisation implementation already emits https://www.example-studio.test/#organization as the stable ID for this provider.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebPage",
"@id": "https://www.example-studio.test/services/website-positioning-workshop#webpage",
"url": "https://www.example-studio.test/services/website-positioning-workshop",
"name": "Website Positioning Workshop",
"mainEntity": {
"@id": "https://www.example-studio.test/services/website-positioning-workshop#service"
}
},
{
"@type": "Service",
"@id": "https://www.example-studio.test/services/website-positioning-workshop#service",
"name": "Website Positioning Workshop",
"serviceType": "Website positioning workshop",
"description": "A facilitated positioning workshop for service businesses preparing a website project.",
"provider": {
"@id": "https://www.example-studio.test/#organization"
},
"areaServed": {
"@type": "AdministrativeArea",
"name": "Western Australia"
},
"offers": {
"@type": "Offer",
"price": "2400",
"priceCurrency": "AUD",
"url": "https://www.example-studio.test/services/website-positioning-workshop"
}
},
{
"@type": "Organization",
"@id": "https://www.example-studio.test/#organization",
"name": "Southbank Strategy Studio",
"url": "https://www.example-studio.test/"
}
]
}
</script>The WebPage identifies the canonical page and points to the Service as its main entity. The Service carries the facts specific to this offer. Its provider resolves to the same organisation node used elsewhere. The offer describes a visible fee without implying availability, discounts or conditions that the page doesn't state.
Adapt the smallest accurate graph. Remove offers when the page doesn't publish a price or other real offer detail. Remove areaServed when coverage isn't explicit. Change the provider type only when the business model and governed provider record support that choice.
Validate what the graph says
Validation needs more than one tool because each check answers a different question. Begin with the rendered canonical page, since that's the version a crawler and buyer receive. Parse the JSON-LD, then use the Schema.org Validator to check vocabulary and relationships. That result doesn't establish eligibility for a Google feature or prove that the business claims are true.
Check Google's documentation separately for any search feature you expect to test. Service isn't a documented standalone Google rich-result type, so a missing Service preview isn't an implementation failure. After deployment, inspect the live HTML again and confirm the intended node, IDs and canonical URL survived the publishing path.
The order matters because a green syntax result can distract from a wrong price, stale location or unresolved provider reference. Use this pre-publication check against the final page and record what changed.
Maintain schema with the service page
Service schema becomes stale when the page changes without the graph. Give editorial ownership to service names, descriptions, coverage and offer wording. Give the commercial owner responsibility for prices, packages and availability. Give the technical owner responsibility for template mapping, stable IDs and rendered output.
Define refresh triggers in the same place as the content record. Review the graph when a service is renamed, merged, removed or split into packages. Review it when coverage or pricing changes, when the provider ID pattern changes, or when a new component starts emitting structured data. Remove the Service node when its canonical page is retired unless another current page becomes the authoritative home for that service.
The vocabulary and platform rules also move. Review the official Schema.org Service definitions and Google's structured data policies at least annually, then review sooner when either source or the service-page template changes. Record the access date so the next owner knows which rules informed the implementation.
Audit one valuable service page first
Start with a service page that influences real enquiries. Read its visible claims, inspect the template output and find the provider node it references. Then compare every schema field with the final page. One focused audit usually reveals whether the gap sits in the content, the template or ongoing governance.
If the page can't express one service cleanly or the template can't render a connected graph, the next job is service-page and website template design. If the page is clear but validation, duplication or policy ownership is weak, use an SEO and structured-data audit to govern the implementation.
The right first result isn't a longer graph. It's one valuable service page whose visible offer, provider relationship and structured data all say the same thing.