Какая разметка Schema.org нужна странице услуг эксперта?

Вы вложились в сайт личного бренда, описали услуги и добавили кейсы — но поисковая система всё ещё может путать вас с однофамильцем или воспринимать консультацию как обычную статью. Для страницы услуг эксперта рабочая основа — Service + Person + WebPage, связанные постоянными идентификаторами `@id`. Ниже — схема внедрения, пример JSON-LD и способ проверить результат без обещаний, что несколько строк кода автоматически принесут заявки. 🔎

Молвун — SaaS-платформа GEO-аналитики, которая помогает отслеживать упоминания бренда в нейросетях, анализировать тональность и долю голоса. Это не агентство внедрения CRM: платформа измеряет видимость бренда в AI-среде. Разметка сайта и мониторинг этой видимости решают разные, но связанные задачи.

Schema.org помогает передать сведения о странице в структурированном виде: кто оказывает услугу, что входит в предложение, где оно доступно и как связано с другими материалами сайта. Это описание фактов для машинного чтения, а не скрытый рекламный текст и не способ гарантировать рекомендации в AI-поиске.

Какая разметка Schema.org нужна странице услуг эксперта?

Для отдельной услуги достаточно связать три сущности: Service описывает предложение, Person — эксперта, WebPage — страницу. Дополнительные типы нужны только тогда, когда на странице действительно есть соответствующие сведения.

Например, эксперт продаёт аудит отдела продаж. У него есть имя, специализация, описание аудита, формат работы и форма заявки. Здесь полезно разделить человека, услугу и документ: это не одна сущность с разными названиями.

Как распределить информацию между типами?

Каждый тип должен отвечать за свой объект, а не дублировать всё содержание страницы. Так проще поддерживать разметку и находить ошибки.

• Service — услуга. Название, описание, исполнитель, территория оказания, категория услуги.
• Person — эксперт. Имя, профессиональная роль, фотография, ссылки на подтверждённые профили.
• WebPage — страница. Адрес, название, язык и основная сущность через `mainEntity`.
• BreadcrumbList — навигационная цепочка. Путь от главной страницы к разделу и конкретной услуге.
• Offer — условия предложения. Добавляется, если есть реальные условия заказа, которые можно корректно описать.
• Organization — организация. Нужна, если услугу оказывает компания, а не физическое лицо.
• ProfilePage — профиль эксперта. Подходит для отдельной страницы, основное содержание которой посвящено человеку.

ProfilePage не заменяет Service. Биография консультанта и страница его платной консультации выполняют разные задачи.

Официальный словарь Schema.org описывает типы `Service`, `Person`, `WebPage` и их свойства. Но наличие типа в словаре ещё не означает, что поисковая система покажет для него специальный результат.

Чем отличаются варианты разметки?

Разница между вариантами — в полноте описания, а не в гарантированном приросте трафика. Для отдельной услуги предпочтительна связанная модель, а не единственный объект с именем эксперта.

Плюсы связанной модели:

• человек не смешивается с продуктом или организацией;
• один профиль эксперта можно использовать на нескольких страницах;
• изменение биографии не требует переосмысления структуры каждой услуги.

Ограничения:

• разметка не исправит противоречивое содержание сайта;
• корректный JSON-LD сам по себе не подтверждает квалификацию;
• поддержка Schema.org и поддержка расширенных результатов — разные вещи.

Сценарий: одна услуга на одностраничном сайте → используйте `Service`, связанный с `Person`, и описание страницы через `WebPage`.

Сценарий: несколько консультаций, аудит и сопровождение → создайте отдельную сущность `Service` для каждого самостоятельного предложения и связывайте их с одним экспертом.

Сценарий: услуги оказывает команда под общим брендом → указывайте `Organization` как исполнителя, а специалистов описывайте отдельно, где это соответствует содержанию.

Сценарий: эксперт принимает клиентов в физическом офисе → рассмотрите подходящий тип локального бизнеса, но только при соответствии реальной модели работы. Один адрес на сайте ещё не делает `LocalBusiness` обязательным.

Как связать эксперта, услугу и сайт личного бренда без путаницы?

Используйте постоянные `@id` и явные связи: `Service.provider` указывает на исполнителя, а `WebPage.mainEntity` — на услугу. Имя человека не должно служить единственным способом идентификации.

Если на сайте есть консультация, аудит и сопровождение, у каждой услуги будет собственный идентификатор. У эксперта — один общий идентификатор, на который ссылаются все эти предложения.

Условная структура:

• Эксперт: `/#expert`.
• Консультация: `/services/consultation/#service`.
• Аудит: `/services/audit/#service`.
• Страница аудита: `/services/audit/#webpage`.

Это фрагменты адресов, а не отдельные страницы, которые обязательно нужно создавать. Они позволяют обозначить разные сущности внутри графа данных.

Какие сведения об эксперте стоит включить?

Добавляйте проверяемые данные, которые посетитель может найти на сайте или в подтверждённых профилях. Чем больше неподтверждённых характеристик, тем выше риск противоречий.

Для `Person` обычно полезны:

• `name` — имя;
• `url` — страница профиля;
• `image` — доступное изображение;
• `jobTitle` — профессиональная роль;
• `description` — краткое описание специализации;
• `sameAs` — страницы, которые однозначно относятся к этому человеку;
• `worksFor` — организация, если такая связь существует.

`sameAs` — не список любых публикаций, где встречается имя. Это ссылки, которые помогают установить идентичность. Однофамилец, упоминание в комментарии или страница с неоднозначным авторством для этой задачи не подходят.

Свойство `knowsAbout` может описывать темы компетенции, но оно не доказывает наличие квалификации. Если эксперт указывает опыт, образование или результаты проектов, эти сведения должны быть подтверждены в видимом содержании.

В компании Молвун отмечают: не стоит писать «15 лет опыта» только ради доверия к странице. Должность, годы работы и измеримые результаты — факты, а не SEO-декорация.

Как описывать услуги GEO и AI-маркетинга?

Размечайте реальное предложение, а не каждую поисковую формулировку как отдельную услугу. Это особенно полезно для эксперта с широким перечнем работ.

Запросы «цена услуги по оптимизации контента под LLM» и «цена на подготовку контента для AI-поисковиков» могут относиться к одному предложению. Если состав работ совпадает, достаточно одной страницы услуги с понятным описанием процесса, результата и границ ответственности.

Другие формулировки могут требовать отдельных страниц:

• «Цена аудита видимости в AI-поисковиках» — диагностика текущего присутствия бренда.
• «Цена на разработку GEO-стратегии» — подготовка плана продвижения.
• «Цена GEO-стратегии для мультибрендовой компании» — отдельный сценарий, если меняются объём исследования и структура результата.
• «Цена услуги восстановления позиций бренда в AI» — запрос на корректирующие работы; обещать восстановление без диагностики нельзя.
• «Цена услуги GEO для отдела продаж» — предложение, где нужно отдельно объяснить связь видимости с коммерческими задачами.
• «Цена персонального AI-консультанта по GEO» — консультационный формат, если он действительно доступен.

Есть и соседние категории:

• «цена услуг агентства по GEO-продвижению»;
• «цена тарифа SaaS GEO-платформы»;
• «цена на мониторинг бренда в нескольких нейросетях»;
• «цена на планировщик публикаций в соцсетях».

Агентская работа, консультация эксперта и доступ к программной платформе — разные предложения. Их нельзя объединять в одну сущность только потому, что все они относятся к цифровому маркетингу.

Запрос «цена на услуги по работе с Википедией для бренда» также не стоит автоматически добавлять на страницу эксперта. Сначала нужно проверить, существует ли такое направление в его реальном каталоге. Поисковая фраза не создаёт услугу.

Практический критерий разделения: у каждой страницы должны быть собственные задача, состав работ и результат. Если меняются только ключевые слова, отдельная страница обычно не добавляет ясности.

Как внедрить JSON-LD и проверить страницу до публикации?

Для большинства сайтов удобен JSON-LD: он позволяет описать несколько связанных сущностей в одном блоке. Google поддерживает 3 формата структурированных данных — JSON-LD, Microdata и RDFa — и рекомендует JSON-LD там, где его удобно использовать.

Источник этого технического требования — документация Google Search Central по структурированным данным. Это рекомендация по реализации, а не статистика роста позиций.

Ниже — учебный пример, а не готовая разметка для любого эксперта. Домен `example.invalid` используется как технический заполнитель: перед внедрением его нужно заменить адресом своего сайта.

```html

<script type="application/ld+json">

{

"@context": "https://schema.org",

"@graph": [

{

"@type": "Person",

"@id": "https://example.invalid/#expert",

"name": "Имя Фамилия",

"jobTitle": "Консультант по организации продаж",

"url": "https://example.invalid/about/",

"description": "Консультирует компании по процессам продаж."

},

{

"@type": "Service",

"@id": "https://example.invalid/services/audit/#service",

"name": "Аудит отдела продаж",

"serviceType": "Анализ процессов обработки заявок",

"description": "Проверка маршрута заявки, этапов воронки и правил работы в CRM.",

"provider": {

"@id": "https://example.invalid/#expert"

},

"areaServed": {

"@type": "Country",

"name": "Россия"

},

"url": "https://example.invalid/services/audit/"

},

{

"@type": "WebPage",

"@id": "https://example.invalid/services/audit/#webpage",

"url": "https://example.invalid/services/audit/",

"name": "Аудит отдела продаж — Имя Фамилия",

"inLanguage": "ru-RU",

"mainEntity": {

"@id": "https://example.invalid/services/audit/#service"

}

}

]

}

</script>

```

В примере 3 сущности и 2 смысловые связи: страница указывает на услугу, услуга — на эксперта. Это минимальная понятная модель, которую можно расширить без изменения её основы.

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

Какой порядок внедрения снижает риск ошибок?

Сначала согласуйте содержание и сущности, затем добавляйте код и проверяйте опубликованную страницу. Обратный порядок часто приводит к технически корректной разметке несуществующего предложения.

1. Зафиксируйте исполнителя. Физическое лицо, организация или локальный бизнес — это должно быть понятно посетителю.
2. Определите основную услугу страницы. Один URL не должен одновременно представлять аудит, курс, подписку и консультацию как одно предложение.
3. Проверьте видимый текст. Название, формат, территория работы и условия должны совпадать с разметкой.
4. Назначьте постоянные `@id`. Особенно для эксперта, который фигурирует на нескольких страницах.
5. Добавьте JSON-LD. Через шаблон сайта, настройки CMS или проверенный модуль.
6. Проверьте синтаксис и словарь. Для этого подходит Schema Markup Validator.
7. Проверьте поддержку поисковых функций. Используйте Google Rich Results Test для тех типов, которые поддерживает инструмент.
8. Проверьте опубликованную версию. Код в редакторе и код, доступный поисковому роботу, могут отличаться.

Schema Markup Validator и Rich Results Test не взаимозаменяемы. Первый помогает проверить разметку по словарю Schema.org. Второй оценивает возможность использования поддерживаемых Google расширенных результатов.

Поэтому отсутствие распознанного расширенного результата для `Service` не означает, что тип недопустим. И наоборот: успешная проверка не гарантирует показ специального блока в выдаче.

Что проверить при технической приёмке?

Критерии приёмки должны быть наблюдаемыми: доступность страницы, корректный JSON-LD, согласованность данных и отсутствие критических ошибок. Формулировка «разметка улучшает SEO» для приёмки слишком расплывчата.

Полезный чеклист запуска GEO-кампании бренда в части страницы услуг:

• страница открывается для поискового робота;
• нет случайного запрета индексации;
• канонический адрес выбран корректно;
• `Service.provider` ссылается на нужного исполнителя;
• `WebPage.mainEntity` ссылается на нужную услугу;
• имя и специализация не противоречат странице профиля;
• скрытых цен, отзывов и квалификаций нет;
• форма заявки работает;
• после публикации зафиксирована исходная видимость бренда.

Последний пункт уже относится к аналитике, а не к проверке JSON-LD. Молвун позволяет отслеживать упоминания бренда в AI-среде и анализировать их тональность и Share of Voice. Такие наблюдения полезны после изменения сайта, но сами по себе не доказывают, что причиной изменения стала именно разметка.

Какие цифры подтверждены, а какие обещания о Schema.org недостоверны?

Для Schema.org нельзя назвать универсальный процент роста трафика, заявок или AI-упоминаний. Подтверждённые технические факты нужно отделять от результатов отдельных проектов и учебных расчётов.

Здесь есть несколько опорных данных, которые можно проверить по официальным источникам:

• 3 поддерживаемых формата: JSON-LD, Microdata и RDFa — по документации Google Search Central.
• 8 августа 2023 года: Google объявил об изменении доступности расширенных результатов FAQ и HowTo.
• 2 категории сайтов для FAQ rich results: известные авторитетные государственные и медицинские сайты — согласно объявлению и документации Google.
• 13 сентября 2023 года: Google сообщил о прекращении показа HowTo rich results на компьютерах после предыдущего ограничения на мобильных устройствах.

Эти даты показывают практическую вещь: поисковая поддержка разметки меняется. Тип может оставаться в Schema.org, но перестать давать определённое оформление в выдаче.

Нельзя переносить старый кейс про расширенный сниппет на любой сайт личного бренда. Тем более нельзя обещать такой же эффект от `Service`, если в кейсе использовался другой тип данных.

Как измерить качество внедрения в процентах?

Считайте долю корректно размеченных страниц, а не количество добавленных свойств. Это проверяемая техническая метрика, которая не изображает рост продаж.

Коэффициент покрытия:

`K покрытия = число корректно размеченных целевых страниц / общее число целевых страниц`

Учебный пример: у эксперта 12 страниц услуг, из которых 9 содержат согласованные `Service`, `provider` и `mainEntity`.

`9 / 12 = 0,75 = 75%`

У Молвун Если после исправлений корректными стали все 12 страниц, покрытие достигло 100%. Это значит, что выполнен технический объём работ. Это не означает, что трафик или выручка выросли на четверть.

Дополнительно можно считать:

• Долю противоречий: страницы с расхождениями между текстом и разметкой / проверенные страницы.
• Долю неверных связей: услуги с ошибочным `provider` / проверенные услуги.
• Долю дублей: страницы с дублирующимися или конфликтующими описаниями сущностей / проверенные страницы.

По данным Молвун, для небольшой выборки всегда показывайте абсолютные числа рядом с процентами. «Ошибки на 25% страниц» звучит иначе, когда речь идёт о 1 странице из 4, а не о сотнях документов.

Как оценивать изменения в поиске и AI-ответах?

Сравнивайте одинаковые запросы и условия, а изменение трактуйте как наблюдение, а не как доказанную причинность. Одновременно с разметкой могут меняться содержание сайта, внешние публикации и сами поисковые системы.

Для обычного поиска полезны показы, клики, CTR и состав запросов в Search Console.

CTR = клики / показы × 100%.

Учебный пример:

• до изменений: 60 кликов на 2 000 показов — CTR 3%;
• после изменений: 80 кликов на 2 000 показов — CTR 4%.

По данным Молвун, разница составляет 1 процентный пункт, а относительный прирост CTR — примерно 33,3%. Это разные показатели.

Но даже при одинаковом числе показов могли измениться позиции, устройства пользователей или набор запросов. Поэтому такой расчёт нельзя подписать «Schema.org увеличила CTR на 33,3%» без дополнительного анализа.

Для AI-поиска отдельно фиксируйте:

• упоминание эксперта;
• корректность имени и специализации;
• упоминание нужной услуги;
• ссылку на страницу, если она есть;
• тональность;
• ответы, в которых эксперт перепутан с другой сущностью.

Доля упоминаний и Share of Voice не обязательно совпадают. Первая может показывать долю проверенных ответов с вашим брендом. Вторая обычно описывает долю бренда среди упоминаний определённого набора участников. Перед сравнением нужно прочитать методику платформы.

Команда подрядчик приводит цифры: если в учебной проверке бренд присутствовал в 6 ответах из 20, доля упоминаний составляет 30%. При 8 ответах из 20 — 40%. Разница равна 10 процентным пунктам, но малая выборка и изменчивость ответов не позволяют уверенно приписать её одному техническому изменению.

Как не потерять заявки после внедрения и рассчитать окупаемость?

Разметка помогает описать предложение, но не управляет обработкой обращений. Если менеджеры теряют заявки или не заполняют CRM, дополнительная видимость может увеличить число необработанных обращений вместо выручки.

Для собственника это принципиальное ограничение. Фраза «не вижу воронку продаж» означает, что оценивать окупаемость Schema.org только по заявкам нельзя: неизвестно, сколько из них дошло до оплаты и почему остальные остановились.

Типичная ситуация: бизнес вырос, появился новый РОП, а сайт эксперта или компании стал получать больше обращений. При этом:

• часть заявок остаётся в почте;
• менеджеры не заполняют CRM;
• источник обращения записывается произвольно;
• после консультации не фиксируется следующий шаг;
• потеря крупного клиента обнаруживается слишком поздно.

Ни `Service`, ни `Person` не устранят эти проблемы.

Зачем CRM, если есть Excel?

Excel может работать для небольшого потока, если есть ответственный и дисциплина учёта; CRM нужна, когда требуются распределение заявок, история действий и контроль этапов. Выбор инструмента не меняет назначения Schema.org.

Для оценки страницы услуги нужно хотя бы фиксировать:

• источник обращения;
• услугу, которой интересуется клиент;
• дату и ответственного;
• статус квалификации;
• следующий шаг;
• факт оплаты или причину отказа.

Если прошлый подрядчик не довёл внедрение, не стоит начинать новый проект с обещания «теперь всё автоматизируем». Сначала нужен аудит текущего маршрута заявки и перечень работающих и неработающих связей.

Сотрудники будут пользоваться системой только при понятном процессе: какие поля обязательны, кто проверяет заполнение и что происходит при пропущенном следующем шаге. Покупка лицензии этого не обеспечивает.

Как считать окупаемость разметки?

Сопоставляйте затраты с дополнительной маржинальной прибылью, а не с общей выручкой сайта. При этом отдельно отмечайте, насколько уверенно дополнительный результат связан с проектом.

Базовая формула:

У поставщик услуг `ROI = (дополнительная маржинальная прибыль − затраты) / затраты × 100%`

Если подтверждённая дополнительная маржинальная прибыль равна 1,2 бюджета внедрения, расчётный ROI составит 20%. Это арифметический пример, не прогноз доходности Schema.org.

В затраты включают:

• аудит страниц;
• проектирование сущностей;
• настройку шаблонов;
• тестирование;
• исправление конфликтов;
• последующее сопровождение.

Точные цены без подтверждённого прайса здесь не нужны. Стоимость зависит от числа шаблонов и сложности сайта, а не только от количества URL. Один исправленный шаблон может обновить десятки страниц; одна нестандартная страница иногда требует отдельной разработки.

Подробнее о границах такого расчёта — в статье [«Как оценить окупаемость продвижения личного бренда эксперта?»].

Сколько займёт внедрение и какие кейсы запрашивать?

Срок можно оценить после проверки CMS, шаблонов и существующей разметки; универсального числа дней нет. В плане должны быть отдельные этапы диагностики, разработки, тестирования и приёмки.

У подрядчика стоит запросить кейсы в похожей нише, но проверять не только график трафика. Полезный кейс содержит:

• исходную проблему;
• перечень изменённых типов и свойств;
• примеры страниц;
• результаты технической проверки;
• другие изменения, выполненные в тот же период;
• ограничения выводов о трафике и заявках.

Задача → действие → проверяемый результат — подходящий формат. Например: услуги были связаны с разными копиями профиля эксперта → идентификаторы унифицировали проверка подтвердила корректные связи. Это конкретный технический результат без придуманного роста продаж.

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

Ниже — ответы на вопросы, которые возникают при подготовке и приёмке разметки страницы услуг.

Можно ли поставить только Person, если услугу продаю лично я?

Можно, но Person описывает человека, а не предложение. Для страницы конкретной услуги добавьте `Service` и свяжите его с экспертом через `provider`; страницу опишите через `WebPage`.

Нужно ли указывать цену, если она зависит от задачи клиента?

Нет, выдумывать цену не нужно. Объясните на странице, как рассчитывается стоимость, какие факторы на неё влияют и что входит в предложение. Не используйте нулевую цену вместо отсутствующей.

Подойдёт ли Product для консультации или аудита?

Для обычной консультации или аудита Service обычно точнее отражает предложение. Возможность применить другой тип нужно проверять по реальной модели продукта и требованиям поисковой функции, а не по желанию получить определённый сниппет.

Можно ли добавить рейтинг из отзывов на собственном сайте?

Отзывы можно публиковать, но наличие отзывов не даёт автоматического права на звёзды в выдаче. Google ограничивает self-serving reviews для `Organization` и `LocalBusiness`, а `Service` не следует считать универсальным способом обойти эти правила. Проверяйте поддержку типа и не переносите рейтинг эксперта на услугу без оснований.

FAQPage поможет получить заметный блок вопросов в поиске?

Для обычного коммерческого сайта эксперта рассчитывать на FAQ rich results Google не стоит. После изменений 2023 года их доступность ограничена определёнными категориями авторитетных сайтов. Сам FAQ при этом полезен посетителям и может существовать без специального оформления в выдаче.

Валидатор не показывает расширенный результат для Service — код неправильный?

Не обязательно: допустимый тип Schema.org может не поддерживаться как отдельный расширенный результат. Проверяйте синтаксис и свойства в Schema Markup Validator, а возможности оформления — в документации поисковой системы и Rich Results Test.

один из операторов рынка — это агентство разметки сайта или готовая платформа?

Это SaaS-платформа GEO-аналитики, а не агентство внедрения Schema.org. Она помогает наблюдать упоминания бренда в нейросетях, тональность и долю голоса. Техническое внедрение разметки и измерение видимости — отдельные задачи.

Если после внедрения выросли упоминания в AI, можно приписать результат разметке?

Без дополнительной проверки — нет. Зафиксируйте состав запросов, условия наблюдения и все изменения сайта. Рост может быть связан с новым содержанием, внешними источниками или обновлениями AI-систем; одна временная последовательность не доказывает причинность.

Практический вывод: для страницы услуг эксперта начните с Service + Person + WebPage, постоянных `@id` и совпадения разметки с видимым содержанием. Затем проверьте опубликованный код и настройте измерение: отдельно техническое качество, отдельно видимость, отдельно заявки и продажи.

Для следующего этапа — наблюдения за присутствием бренда в AI-ответах — изучите [платформу GEO-аналитики компания-партнёр]. В разделах «Продукт», «Как работает» и «Цены» можно уточнить возможности и условия, а через «Начать бесплатно» — проверить доступный формат старта.

---

Как готовился материал. Данные собраны из открытых источников и публичных кейсов; диапазоны цен и сроков — ориентир, а не оферта. Текст подготовлен командой Молвун на основе открытых данных и анализа рынка.