Микроразметка Schema.org: что размечать коммерческому сайту и что это даёт

Начать стоит с ожиданий, потому что от них зависит, стоит ли вообще заказывать эту работу. Ни Яндекс, ни Google не называют Schema.org фактором ранжирования: страница с идеальной разметкой и слабым текстом останется там же, где была. Разметка влияет на две другие вещи. Первая — как выглядит сниппет: цена, хлебные крошки, вопросы под ссылкой, адрес и телефон организации. Вторая — насколько точно поисковая система понимает, о чём страница и какой сущности она принадлежит: у Google это связка с панелью знаний, у Яндекса — с карточкой организации и товарным сниппетом.

Отсюда следует жёсткое ограничение: разметка описывает только видимый контент. Если в JSON-LD стоит цена 12 000 ₽, а на странице написано «от 15 000 ₽» — это расхождение, которое обе системы трактуют как попытку обмана. Google за такое выдаёт ручные меры «спамная структурированная разметка», и расширенные результаты для сайта отключаются целиком, а не для одной страницы. Яндекс проще: несоответствие разметки содержимому — основание не показывать обогащённый сниппет. В обоих случаях итог один — работа сделана зря или во вред.

И третье, о чём подрядчики предпочитают молчать: расширенный сниппет не гарантирован даже при безупречной разметке. Поисковик решает сам, показывать ли цену или вопросы конкретному пользователю по конкретному запросу. Разметка — это условие допуска, а не кнопка «показать».

Это первый тип, который мы ставим любому коммерческому сайту, и первый, в котором находим ошибки при аудите. Organization описывает компанию как сущность: название, логотип, телефон, ссылки на профили в sameAs. LocalBusiness — его подтип для бизнеса с физическим адресом и приёмом клиентов: к нему добавляются address с разбивкой по полям, geo с координатами и openingHoursSpecification с графиком по дням недели. Для стоматологии, автосервиса или салона красоты нужен именно LocalBusiness — так данные на сайте совпадают с тем, что указано в карточке Яндекс.Бизнеса и в профиле Google, и системе проще связать сайт с точкой на карте.

Типичная ошибка — вешать полный блок Organization на каждую страницу сайта через общий шаблон. Поисковику это не помогает, а вот путаницу создаёт: на странице услуги главная сущность — услуга, на статье — статья, и дублирующая организация с адресом рядом размывает, о чём страница. Мы оставляем Organization или LocalBusiness на главной и на странице контактов, а на остальных страницах ссылаемся на неё через provider или publisher с тем же @id.

Второе, что проверяем: график и телефон в разметке берутся из того же места, что и текст на сайте. У себя мы держим одну константу с расписанием, из которой рендерятся футер, страница контактов и JSON-LD — иначе время работы в футере поменяли, а в разметке осталось старое.

Для страницы услуги ставится тип Service с name, description, provider (ссылка на вашу Organization) и areaServed, для товара — Product с name, image, sku, brand. Ценность в обоих случаях даёт вложенный Offer: price, priceCurrency со значением RUB и availability. Именно Offer превращает страницу в объект с ценой, который поисковик может показать прямо под заголовком.

Здесь важно честно развести две системы. Google показывает цену и наличие в расширенных результатах для Product — для Service отдельного расширенного результата нет, разметка услуги работает на понимание страницы, а не на внешний вид сниппета. Яндекс использует данные о товарах и ценах для товарного сниппета и принимает их из разметки страницы наряду с фидом. Поэтому магазину Product с Offer нужен обязательно, а сайту услуг Service — как способ связать страницу с организацией и явно назвать, что здесь продаётся и почём.

Обратная сторона — цены «от». В price пишется одно число, и если поставить туда нижнюю границу, а на странице стоит вилка, это уже спорно. Мы делаем так: если цена на странице «от 35 000 ₽», в разметке используем priceSpecification с minPrice или AggregateOffer с lowPrice, а не притворяемся, что цена фиксированная. Валидатор такое пропускает, а главное — разметка остаётся правдивой.

FAQPage — самый заметный тип для сайта услуг: список вопросов и ответов, размеченный как mainEntity из объектов Question с acceptedAnswer. В Яндексе это даёт сниппет с раскрывающимися вопросами под ссылкой; в Google с осени 2023 года такой расширенный результат оставлен только для сайтов государственных органов и медицинских организаций — коммерческий сайт услуг его там не получит, и обещать это клиенту нельзя. Но разметку мы всё равно ставим, и вот почему.

Пара «вопрос — короткий прямой ответ» — ровно та единица, которую вытаскивают генеративные ответы: блок Нейро в Яндексе, AI Overviews в Google, ответы ChatGPT и Perplexity. Разметка не заставляет их цитировать вас, но снимает неоднозначность: система видит, что это вопрос и что вот это — законченный ответ на него, а не фрагмент абзаца. Условие то же, что везде: вопросы должны быть видимы на странице, ответ в разметке — тот же текст, что и на экране, без «расширенной версии для робота». И это должны быть вопросы про эту страницу, а не пять одинаковых формулировок, размноженных по всему сайту.

speakable — свойство WebPage или Article, где через cssSelector указывается, какие блоки страницы содержат прямой ответ на её интент. Официально Google описывает его как инструмент для голосовых ассистентов и новостных сайтов, гарантий по коммерческим страницам нет. Мы используем его как маркер: на страницах услуг и статьях блога указываем селектор блока «быстрый ответ» под заголовком. Эффект в лучшем случае косвенный, но и стоимость нулевая.

BreadcrumbList — самый недооценённый тип: он ставится на все внутренние страницы и почти никогда не ломается. Каждый элемент itemListElement — это ListItem с position, name и item (URL). Google при наличии разметки показывает в сниппете вместо адреса страницы путь «Главная › Услуги › Техническое SEO», Яндекс использует те же данные для хлебных крошек в выдаче. Для клиента это значит, что сниппет становится понятнее — видно, в каком разделе он окажется, — а поисковик получает явную структуру сайта.

Крошки в разметке — зеркало видимых: те же уровни и те же URL с завершающим слешем, что и канонические адреса. Расхождение здесь не наказывается, но мешает поисковику собрать единую структуру сайта.

Article — для статей блога. Обязательный минимум: headline, datePublished, dateModified, author как Person с именем, publisher со ссылкой на Organization и image. Честнее всего стоит заполнять dateModified и author: дата обновления показывается в сниппете и двигает переобход, а автор с реальным именем работает на доверие — и у Google с его требованиями к экспертности, и в генеративных ответах, где системы предпочитают источники с понятным авторством. На страницу услуги Article не ставится: для неё уже есть Service.

Разметку можно встроить двумя способами. Microdata — это атрибуты itemscope, itemtype, itemprop прямо на HTML-тегах, вокруг видимого текста. JSON-LD — отдельный блок <script type="application/ld+json"> в коде страницы, где те же данные лежат в виде структуры. Обе системы понимают оба формата: Яндекс в справке Вебмастера поддерживает JSON-LD, Microdata и RDFa, Google прямо называет JSON-LD рекомендуемым.

Мы выбираем JSON-LD по трём практическим причинам. Первая — он не зависит от вёрстки: дизайнер переделал карточку услуги, переставил блоки — разметка не рассыпалась, потому что живёт отдельно. С microdata каждая правка шаблона рискует потерять itemprop. Вторая — его можно собирать из тех же данных, что и страницу: у нас цена, FAQ и хлебные крошки на странице услуги и в JSON-LD берутся из одного объекта в коде, и расхождение между текстом и разметкой физически невозможно. Третья — его удобно проверять и отлаживать: один блок, который читается глазами и целиком вставляется в валидатор.

Единственное преимущество microdata — она физически привязана к видимому контенту, и разметить то, чего нет на странице, сложнее. Для JSON-LD правило «только видимое» приходится соблюдать осознанно: скрипт может описывать что угодно. На конструкторах и в готовых CMS обычно есть «мастер микроразметки», который генерирует разметку сам — если он работает, переделывать его не надо, но проверить, что он выдаёт, стоит.

Инструментов три, и они смотрят разное. Валидатор микроразметки в Яндекс.Вебмастере — по URL или вставленному коду показывает, какие сущности распознаны и где нарушен формат. Rich Results Test от Google проверяет пригодность страницы для расширенных результатов и предупреждает о недостающих полях. Третий — Schema Markup Validator на validator.schema.org — проверяет только синтаксис по словарю, без привязки к поисковику. После внедрения ошибки накапливаются в отчётах «Улучшения» Search Console и в диагностике Вебмастера — их стоит смотреть раз в месяц, а не только при запуске.

Что мы находим в аудитах в первую очередь. Рейтинг со звёздами (AggregateRating) на страницах, где нет ни одного отзыва с оценкой, — самая массовая ошибка. Google с 2019 года не показывает звёзды для отзывов, которые компания разместила о себе сама, а Яндекс требует, чтобы оценки были видны на странице; такая разметка в лучшем случае бесполезна, в худшем — повод для санкций. Вторая ошибка — Organization с полным адресом в шаблоне каждой страницы. Третья — FAQPage на странице без блока вопросов, потому что «так у конкурента». Четвёртая — сломанные @id или URL в BreadcrumbList после переезда на новые адреса.

Порядок работ у нас простой. Сначала прогоняем главные типы страниц через Валидатор и Rich Results Test и фиксируем, что распознано и с какими предупреждениями. Потом сверяем каждое поле разметки с тем, что видно на странице: цену, телефон, график, вопросы. Убираем всё, что не подтверждается контентом, и только после этого добавляем недостающее — Offer на страницы с ценой, BreadcrumbList на внутренние страницы, Article на блог. В техническом SEO это одна из первых задач; если разметка уже есть, но неизвестно, работает ли, — она входит в аудит сайта отдельным пунктом.