Service Schema Markup: provider, serviceType, areaServed & JSON-LD Examples

Quick answer

What you need to know

Use Service when the page primarily describes a service rather than a physical product or article. Give it a stable @id, name, description and URL; connect provider to a real Organization/Person; use serviceType for the category and areaServed only for areas you genuinely serve.

memorySemantic summary for search and AI

Service Schema.org represents an offered service. Useful fields include name, description, serviceType, provider, areaServed, url, offers and @id. provider should reference the real business entity; areaServed should describe real coverage.

Key properties

The table below summarizes the fields that most often determine whether the entity is clear and internally consistent. Only provide values supported by the page.

Property	Importance	How to use it
`name`	Core	Clear service name.
`description`	Core	What the service includes.
`provider`	Recommended	Real Organization or Person.
`serviceType`	Recommended	Concise service category.
`areaServed`	When geographic scope matters	Real country/region/city coverage.
`url / @id`	Recommended	Canonical page URL and stable entity identifier.
`offers`	Optional	Only for real visible commercial offers.

When Service is primary

Use Service when the page primarily describes an offered service. An About page may remain AboutPage; a dedicated consulting or installation page is a stronger Service candidate.

Provider relationship

provider should point to the real Organization or Person delivering the service. Reuse a shared Organization @id rather than duplicating the business.

serviceType

Use a concise factual service category, not a paragraph of keywords.

areaServed

Describe real geographic coverage. Do not narrow or expand geography just because location words appear on the page.

URL, @id and mainEntity

A stable @id makes relationships clearer. WebPage can point to Service as mainEntity and Service.url can point to the canonical service page.

Offers

Use Offer only when a real price or package is visible. Quote-based services do not need a fake price.

Related entities

Organization, BreadcrumbList and FAQPage can coexist as secondary graph nodes.

Quality checklist

Confirm name, provider, serviceType, areaServed and description against visible content; do not classify the page as Product just because equipment is mentioned.

JSON-LD examples

Service + provider + WebPage

This example links the service to its provider without inventing a price.

{
    "@context": "https://schema.org",
    "@graph": [
        {
            "@type": "Organization",
            "@id": "https://example.com/#organization",
            "name": "Example Integrators"
        },
        {
            "@type": "WebPage",
            "@id": "https://example.com/services/av-integration/#webpage",
            "url": "https://example.com/services/av-integration/",
            "mainEntity": {
                "@id": "https://example.com/services/av-integration/#service"
            }
        },
        {
            "@type": "Service",
            "@id": "https://example.com/services/av-integration/#service",
            "name": "AV System Integration",
            "serviceType": "Audiovisual system integration",
            "provider": {
                "@id": "https://example.com/#organization"
            },
            "areaServed": {
                "@type": "Country",
                "name": "United States"
            },
            "url": "https://example.com/services/av-integration/"
        }
    ]
}

Google, Bing and Yandex

Google

Google does not document a universal Service rich result comparable to Product, but Service remains useful semantic data.

Bing

Bing supports Schema.org JSON-LD and can use service/entity relationships to understand the page.

Yandex

Yandex supports Schema.org selectively; Service markup should still be accurate even when a dedicated snippet is not guaranteed.

Important: valid structured data does not guarantee a rich result. Each search engine decides whether to use the data and how to present it.

Common mistakes

warningService page classified as Product.
warningService.url points to the homepage.
warningDuplicate Organization on every service page.
warningKeyword-stuffed serviceType.
warningFake areaServed or price.

Frequently asked questions

Does Service Schema guarantee a rich result?

No. It improves semantic description, but search engines decide presentation.

Do I need Offer for a service?

Only when a real offer or price is visible.

Can Service and FAQPage exist together?

Yes. Service remains the primary entity.