Service Schema.org: provider, serviceType, areaServed и примеры JSON-LD

Короткий ответ

Что нужно знать

Используйте Service, когда основное содержание страницы — услуга. Задайте устойчивый @id, name, description и URL; provider свяжите с реальным Organization/Person; serviceType используйте как тип услуги, areaServed — только для реально обслуживаемой территории.

memoryСемантическая сводка для поиска и AI

Service Schema.org представляет услугу. Полезные поля: name, description, serviceType, provider, areaServed, url, offers и @id. provider должен ссылаться на реального исполнителя, areaServed — на реальную географию.

Ключевые свойства

Ниже — практический минимум и свойства, которые чаще всего влияют на корректность сущности. Заполняйте только те значения, которые реально подтверждаются страницей.

Свойство	Важность	Как использовать
`name`	Ключевое	Название услуги.
`description`	Ключевое	Что входит в услугу.
`provider`	Рекомендуется	Реальный исполнитель.
`serviceType`	Рекомендуется	Краткая категория.
`areaServed`	Если важна география	Реальная территория.
`url / @id`	Рекомендуется	Canonical и устойчивый ID.
`offers`	Опционально	Только реальная цена/пакет.

Когда Service — основная сущность

Service подходит для отдельной страницы услуги, а общая «О компании» может оставаться AboutPage.

provider

provider должен ссылаться на реальную Organization/Person. Лучше переиспользовать общий @id.

serviceType

Короткая фактическая категория услуги без переспама.

areaServed

Только реальная география, а не города из ключевых слов.

URL, @id и mainEntity

WebPage может указывать Service как mainEntity, Service.url — на canonical страницы.

Offer

Добавляйте только при реальной цене; для расчёта по запросу фиктивный price не нужен.

Связанные сущности

Organization, BreadcrumbList и FAQPage могут быть дополнительными узлами.

Проверка

Сверьте name, provider, serviceType, areaServed и description с видимым контентом.

JSON-LD примеры

Service + provider + WebPage

Пример без выдуманной цены.

{
    "@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": "Интеграция AV-систем",
            "provider": {
                "@id": "https://example.com/#organization"
            },
            "areaServed": {
                "@type": "Country",
                "name": "United States"
            },
            "url": "https://example.com/services/av-integration/"
        }
    ]
}

Google, Bing и Яндекс

Google

Google не документирует универсальный Service rich result, но корректный Service остаётся полезной семантикой.

Bing

Bing поддерживает Schema.org JSON-LD и может использовать связи услуги и provider.

Yandex

Яндекс поддерживает Schema.org выборочно; Service должен оставаться точным описанием страницы.

Важно: корректная микроразметка не гарантирует расширенный результат. Поисковая система сама решает, использовать ли данные и как их отображать.

Типичные ошибки

warningService ошибочно классифицирован как Product.
warningService.url ведёт на главную.
warningДублируется Organization.
warningserviceType набит ключами.
warningВыдуманы areaServed или price.

Частые вопросы

Гарантирует ли Service rich result?

Нет. Поисковик сам решает способ использования данных.

Нужен ли Offer?

Только если на странице есть реальная цена или пакет.

Можно Service и FAQPage вместе?

Да. Service остаётся основной сущностью.