Владелец сайта по остеклению смотрит отчёт и злится. Позиции есть, страницы держатся в топе, SEO-работы идут не первый месяц: тексты переписывали, блоки добавляли, кейсы оформляли, фотографии меняли. А кликов всё равно меньше, чем он ожидал.
Вопрос к подрядчику в такой ситуации возникает простой и довольно неприятный: «Вы вообще что делаете? Если сайт уже в топе, почему люди не переходят?» На эмоциях это звучит как обвинение, но сама проблема реальная. Позиции в отчёте есть, а бизнес не видит того эффекта, который привык ждать от этих позиций.
И тут не всегда помогает ответ «надо ещё поработать над текстами». Иногда текстов уже достаточно. Блоков тоже достаточно. Страница видна, но плохо объясняет машине, что именно она предлагает: услугу, регион, исполнителя, условия, цену, замер, гарантию, филиал.
Вот здесь и стоит вспомнить про микроразметку. Не как про волшебную кнопку, которая вернёт клики. Не вернёт. А как про способ сделать страницу менее мутной для поисковиков, агрегаторов и других машинных потребителей.
С сайтом услуг это особенно заметно. Интернет-магазин размечать проще: товар, цена, наличие, доставка. У услуги всё грязнее.
Услуга — это не товар без артикула
Многие примеры микроразметки в интернете написаны вокруг товаров. Там понятная модель: есть Product, есть Offer, есть цена, валюта, наличие. Если повезло, ещё бренд, рейтинг и отзывы.
С услугами так не работает. Остекление балкона, юридическая консультация, ремонт квартиры, внедрение CRM, SEO-аудит или установка кондиционера — это не товар на складе. У услуги может быть цена «от», расчёт после замера, разные регионы, несколько пакетов, сезонные условия и ещё три ограничения, которые менеджер объясняет по телефону.
Когда такую страницу размечают как товар, получается странно. Для человека на странице написано: «стоимость рассчитывается индивидуально». Для машины в JSON-LD лежит price: 0. Формально поле есть. По смыслу — уже плохо.
Машина не обязана угадывать, что ноль поставили не потому, что услуга бесплатная, а потому что кому-то хотелось заполнить поле.
Почему проблема не только в кликах
Если сайт в топе, но кликов мало, это не всегда значит, что SEO «ничего не делает». Но это и не значит, что всё хорошо. Позиция показывает, что страница видна в выдаче, но она не объясняет, насколько понятно поисковику, что именно находится на странице.
У сайтов услуг часто проблема не в одном конкретном теге. Проблема в том, что сайт сам не очень аккуратно объясняет свою модель. На одной странице «остекление балконов», на другой «остекление лоджий», на третьей «тёплое остекление». В тексте всё похоже. Цена где-то есть, где-то нет. Регион указан в футере. Замер бесплатный, но только в пределах города. Гарантия есть, но в другом разделе.
Человек ещё может собрать картину. Машина не обязана.
Что должна понять машина
Для страницы услуги важно не просто название. Нужно понять, кто оказывает услугу, где оказывает, что именно входит в работу, есть ли публичная цена и какие условия влияют на решение пользователя. Это может быть замер, выезд, гарантия, сроки, регион, филиал, формат работы или ограничение по типу объекта.
Часть этих данных живёт в тексте. Часть — в карточках. Часть — в футере. Часть — в блоке FAQ. Часть — в CMS. А часть вообще только в голове менеджера, который потом объясняет всё по телефону.
Микроразметка не заменяет нормальную страницу. Она помогает явно показать связи, которые на странице уже есть. Если услуга оказывается компанией, это можно связать через provider. Если услуга работает в конкретном регионе, можно указать зону оказания. Если на странице есть публичная цена, можно добавить предложение. Если есть каталог услуг, можно описать структуру предложений.
Ключевое слово здесь — «если». Не надо размечать то, чего на странице нет.
Что ставить на сайт услуг
На уровне компании обычно нужен Organization или более конкретный тип, если он подходит. Для локального бизнеса — LocalBusiness или его подтип. Там живут название, сайт, логотип, контакты, адрес, телефон, ссылки на профили.
На странице конкретной услуги логичнее описывать саму услугу через Service.
Например, упрощённо:
{ "@context": "https://schema.org", "@type": "Service", "name": "Остекление балконов", "description": "Остекление балконов и лоджий с замером и установкой", "provider": { "@type": "LocalBusiness", "name": "Компания по остеклению" }, "areaServed": { "@type": "City", "name": "Москва" } }
Это не красивый пример. Просто нормальный. Он не обещает лишнего: есть услуга, исполнитель и регион. Уже лучше, чем одинаковый Organization на всех страницах сайта.
Когда нужен Offer
Если на странице есть публичная цена, её можно указать в Offer.
{ "@context": "https://schema.org", "@type": "Service", "name": "Остекление балконов", "provider": { "@type": "LocalBusiness", "name": "Компания по остеклению" }, "offers": { "@type": "Offer", "price": 25000, "priceCurrency": "RUB" } }
Но тут начинается скучная часть. Цена в JSON-LD должна быть той же ценой, которую видит пользователь. Не старой. Не примерной из головы. Не той, которую когда-то поставили в шаблон, чтобы валидатор не ругался.
Если на странице написано «от 25 000 руб.», а в разметке лежит 50000, это не техническая мелочь. Это разные данные для разных читателей.
Если цены нет, Offer можно не выводить. Это нормально. Хуже вывести ноль и сделать вид, что так и было задумано.
{ "@type": "Offer", "price": 0, "priceCurrency": "RUB" }
Для человека «цена рассчитывается после замера» и для машины price: 0 — это разные заявления. И машина, в общем-то, не виновата.
Каталог услуг — не та же самая страница
У сайтов услуг часто есть разделы: остекление балконов, остекление лоджий, холодное остекление, тёплое остекление, отделка балконов, вынос балкона, ремонт окон. Это уже не одна услуга, а каталог.
Здесь можно смотреть в сторону OfferCatalog или связки через hasOfferCatalog. Но не надо превращать каждую страницу в карту всего бизнеса. Страница конкретной услуги должна описывать конкретную услугу. Страница раздела может описывать список услуг. Главная — компанию и основные направления. Контакты — адреса, телефоны, график, филиалы.
Проблемы начинаются, когда один и тот же JSON-LD лежит на всех URL.
{ "@context": "https://schema.org", "@type": "Organization", "name": "Компания по остеклению", "url": "https://example.com" }
Сам по себе Organization не плохой. Просто он не объясняет, что находится на конкретной странице услуги. Компания есть. А услуга как будто не описана.
FAQ — только если он есть
FAQ любят добавлять в разметку отдельно от страницы. Потому что вопросы и ответы выглядят полезно. Иногда их даже проще написать сразу в JSON-LD, чем нормально вставить в интерфейс.
Так делать не надо. Если вопрос и ответ есть на странице, их можно размечать. Если пользователь их не видит, микроразметка превращается во второй сайт внутри сайта. Это уже не описание страницы, а отдельная версия реальности.
Для сайта услуг FAQ может быть полезен. Например: сколько длится замер, входит ли доставка, работаете ли по области, можно ли сделать тёплое остекление зимой. Но сначала это должен быть нормальный видимый блок, а не тайное послание для поисковика.
Почему валидатор снова не спасает
Валидатор проверяет структуру. Он не проверяет бизнес-смысл. Он может увидеть корректный Service, корректный Offer, число в price, валюту RUB, нормальный JSON. И поставить зелёную галочку.
Он не будет звонить владельцу и спрашивать, правда ли остекление стоит 25 000 руб. Он не полезет в прайс, CRM, бухгалтерию и смету монтажника. У него нет такой работы.
Поэтому валидность — это только первый уровень. Дальше надо проверять, совпадает ли разметка с видимой страницей и с реальными источниками данных.
Для сайта услуг это особенно важно, потому что там много условностей. Цена от. Регион частичный. Замер бесплатный не всегда. Гарантия зависит от вида работ. Услуга может называться по-разному на разных страницах. Если всё это не привести к понятной модели, JSON-LD станет просто ещё одним местом, где данные могут устареть.
Как я бы проверял такую страницу
Сначала не валидатор. Сначала открываю страницу как пользователь и выписываю факты, которые она сообщает: услуга, компания, регион, цена, условия, контакты, сроки, гарантия, FAQ.
Потом смотрю, где эти же факты находятся в коде: title, description, Open Graph, JSON-LD, хлебные крошки, карточки, футер, локальные страницы. Дальше простой вопрос: они говорят одно и то же или нет?
Если в карточке написано «остекление балконов», в description — «ремонт окон», в JSON-LD — просто Organization, а регион спрятан только в футере, то проблема уже видна. Даже если валидатор зелёный.
После этого можно решать, что именно размечать. Не раньше.
Как поставить задачу разработчику
Плохая задача:
Добавить микроразметку на сайт услуг.
После такой задачи разработчик сам решает, где услуга, где компания, откуда брать цену, что делать без цены, как указать регион и нужно ли размечать FAQ. Иногда угадает. Иногда нет. Чаще сделает как в первом примере из поиска.
Нормальная задача выглядит иначе:
На страницах услуг вывести JSON-LD типа Service. Название и описание брать из данных услуги. Исполнителя связать с организацией сайта. Регион оказания брать из настроек страницы или филиала. Если на странице есть публичная цена, добавить Offer с той же ценой. Если публичной цены нет, Offer не выводить. FAQ размечать только если блок FAQ виден пользователю. Проверить страницу с ценой, страницу без цены и страницу раздела услуг.
Это уже не просто «вставить Schema.org». Это правило. Его можно реализовать руками разработчика. Но его нельзя придумывать на ходу в шаблоне.
Мини-чеклист для сайта услуг
Главная страница: компания, сайт, логотип, контакты, профили, основные направления.
Страница услуги: конкретная услуга, описание, исполнитель, регион оказания, цена только при наличии публичной цены.
Раздел услуг: список услуг или каталог предложений, если страница действительно является каталогом.
Контакты: адрес, телефон, часы работы, филиалы, если они есть.
Хлебные крошки: BreadcrumbList, если структура сайта реально есть.
FAQ: только видимые вопросы и ответы.
Цена: один источник для видимой страницы, description и JSON-LD.
Вместо вывода
Когда сайт услуг в топе, но кликов меньше, чем ждёт владелец, не всегда надо сразу переписывать ещё один текст и добавлять ещё один блок. Иногда сначала надо понять, что сайт вообще сообщает машине: кто оказывает услугу, где оказывает, какая услуга описана на этой странице, есть ли цена, есть ли условия и совпадает ли всё это с тем, что видит пользователь.
Микроразметка не делает плохую страницу хорошей. И не гарантирует клики. Но она быстро показывает, насколько у сайта в порядке данные.
Услуга — не товар. Поэтому и размечать её надо не как товар с плохой ценой, а как услугу со своими условиями, регионом, исполнителем и честным описанием.
Машина не обидится, если вы не заполните лишнее поле. Хуже, если вы заполните его данными, которым нельзя верить.
