---
title: "Service Schema: JSON-LD Example and Guide"
description: "Learn what Service schema describes, how provider, areaServed and offers fit together, and why valid markup does not guarantee Google rich results."
url: https://superschema.ai/schema-markup/service-schema
author: "Clint Johnson"
date_published: 2026-09-30
---

# Service schema: a practical JSON-LD guide

Service schema is Schema.org markup that describes a service, its provider and relevant details such as the area served or an offer. Add it to a page that explains the service, using facts that readers can verify on that page.

A good implementation makes the relationships clear. The company is one entity, the service is another, and an offer describes the terms under which that service is available. Keeping these separate helps your team maintain a coherent description as the business changes.

## What is service page schema?

“Service page schema” usually means using the Schema.org [Service type](https://schema.org/Service) on a page about a specific service. It is not a separate Schema.org type.

For example, an agency's implementation service and its ongoing support service can each have their own page and Service entity. Both can point to the same provider. A homepage that describes the agency as a business needs a different emphasis; see our [Organization schema guide](https://superschema.ai/hubspot-aeo/organization-schema).

Choose a more specific Service subtype when one accurately describes the offering. Do not select a type solely because you hope it will unlock a search feature. The description should continue to make sense if a person reads it without knowing anything about SEO.

## Which properties should you include?

Schema.org defines a vocabulary rather than a universal checklist of required Service fields. Start with enough information to identify the offering and explain its relationships.

| Property | What it describes | Practical choice |
| --- | --- | --- |
| `@id` | The identity of this service | A stable page URL with a service fragment |
| `name` | The service's name | Use the name readers see |
| `description` | A summary of the service | State the scope without extra promises |
| `url` | A page about the service | Use its public canonical URL |
| `serviceType` | The kind of service | A specific, ordinary description |
| `provider` | Who performs or operates it | An Organization or Person |
| `areaServed` | Where it is provided | A truthful place, region or text value |
| `offers` | An offer to provide it | Include only supported commercial terms |

The [serviceType definition](https://schema.org/serviceType) accepts text. You do not need to invent a category identifier to describe “HubSpot CMS implementation.”

The [provider definition](https://schema.org/provider) distinguishes the party performing the service from a seller that might offer it on the provider's behalf. For a consultancy selling its own work, those parties can be the same organization.

## A complete fictional Service JSON-LD example

Here is a fictional service page for Northline Consulting. Its visible copy states that the company provides HubSpot CMS implementation to UK organizations. A fixed package includes page templates, content migration and launch checks for GBP 4,000. That amount is invented for this example and is not SuperSchema pricing.

```html
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Northline Consulting",
      "url": "https://example.com/"
    },
    {
      "@type": "Service",
      "@id": "https://example.com/services/hubspot-cms#service",
      "name": "HubSpot CMS implementation",
      "url": "https://example.com/services/hubspot-cms",
      "description": "Page templates, content migration and launch checks for UK organizations using HubSpot CMS.",
      "serviceType": "HubSpot CMS implementation",
      "provider": {
        "@id": "https://example.com/#organization"
      },
      "areaServed": {
        "@type": "Country",
        "name": "United Kingdom"
      },
      "offers": {
        "@type": "Offer",
        "@id": "https://example.com/services/hubspot-cms#offer",
        "url": "https://example.com/services/hubspot-cms",
        "price": "4000.00",
        "priceCurrency": "GBP",
        "seller": {
          "@id": "https://example.com/#organization"
        },
        "itemOffered": {
          "@id": "https://example.com/services/hubspot-cms#service"
        }
      }
    }
  ]
}
</script>
```

This is a single graph containing the provider and the service. References connect the offer to the service and the seller to the organization. The identifiers end in different fragments so an organization, a service and an offer do not accidentally share one identity.

In [JSON-LD](https://www.w3.org/TR/json-ld11/#node-identifiers), `@id` identifies a node and can connect descriptions of that node. Keep your organization identifier consistent when adding other service pages. Give each distinct service its own identifier.

Copying the code unchanged would describe the fictional company. Replace the domain, identity, description, geography and commercial terms before implementation.

## How should areaServed work?

[areaServed](https://schema.org/areaServed) describes the geography in which the service or offered item is provided. It can use an AdministrativeArea, GeoShape, Place or text. A Country is a kind of Place, which makes it suitable for the example above.

Do not use your office address as a shortcut for service coverage. A company with a London office might serve the UK, several countries or only a local area. Those are different facts.

Likewise, “remote delivery” does not establish worldwide availability. Check the actual commercial scope: language, jurisdiction, delivery limitations and who the business accepts as a customer. If the page does not state a service area, resolve that content question before adding an expansive geographic claim.

## Do services need offers and prices?

The [offers property](https://schema.org/offers) links a service to an Offer or Demand. An [Offer](https://schema.org/Offer) can describe the terms for providing something; its purpose is broader than attaching a price to a product.

Include a fixed price when the page publishes that price for a defined scope. Schema.org's [price guidance](https://schema.org/price) and [priceCurrency definition](https://schema.org/priceCurrency) describe the amount and currency separately. In the example, `4000.00` and `GBP` describe one fixed package.

If your work is quoted individually, omit the fixed-price offer from this example. Do not use `0` to mean “contact us,” or convert a starting price into an exact package price. An incomplete description can be improved later; a false price is already misleading.

## Does Service schema create Google rich results?

As of September 29, 2026, Google's [structured data feature gallery](https://developers.google.com/search/docs/appearance/structured-data/search-gallery) does not list a dedicated Service rich result. Valid Schema.org Service markup and eligibility for a Google search feature are separate questions.

Use the [Schema Markup Validator](https://validator.schema.org/) to inspect the Service model. Use Google's Rich Results Test for supported Google features that also apply to the page. An empty rich-result result for Service alone does not establish that the Schema.org description is invalid.

Do not add a Product type or fabricated ratings just to make a tool report more eligible items. Evaluate each additional type against the page and the relevant feature requirements. Our [schema validation guide](https://superschema.ai/hubspot-aeo/schema-validation) walks through that decision.

Nor does Service markup prove that an AI engine will cite the page. Google says there is [no special Schema.org markup required](https://developers.google.com/search/docs/appearance/ai-features) for AI Overviews or AI Mode. Treat clear, accurate markup as one part of a useful website, and measure outcomes separately.

## How do you implement it on HubSpot?

Put the script on the service page and verify the published output. Follow the [HubSpot placement guide](https://superschema.ai/hubspot-aeo/structured-data-on-hubspot) for the page editor workflow. For the broader content and access checks, read the [HubSpot AEO guide](https://superschema.ai/hubspot-aeo/guide).

Assign an owner to the service description. When the package, provider, coverage or price changes, update the visible page and its JSON-LD in the same change.

> **Build markup for your service**
>
> Use the facts from your own service page to draft and validate the markup.
>
> **[Use the Service schema generator](https://superschema.ai/service-schema-generator)**
>
> [Want implementation help? Explore SuperSchema Managed](https://superschema.ai/managed)

## Sources

Primary sources reviewed September 29, 2026.

- [Schema.org: Service](https://schema.org/Service), [provider](https://schema.org/provider), [areaServed](https://schema.org/areaServed) and [serviceType](https://schema.org/serviceType)
- [Schema.org: offers](https://schema.org/offers), [Offer](https://schema.org/Offer), [price](https://schema.org/price) and [priceCurrency](https://schema.org/priceCurrency)
- [W3C: JSON-LD 1.1 node identifiers](https://www.w3.org/TR/json-ld11/#node-identifiers)
- [Google: Supported structured data features](https://developers.google.com/search/docs/appearance/structured-data/search-gallery)
- [Google: Structured data testing tools](https://developers.google.com/search/docs/appearance/structured-data)
- [Google: AI features and your website](https://developers.google.com/search/docs/appearance/ai-features)