Микроразметка сайта: что заказать подрядчику и как принять результат

Разметка не покупает место в поисковой выдаче

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

Микроразметка помогает обозначить для машины смысл данных: это цена товара, это автор статьи, а это адрес организации. Посетитель читает обычную страницу, поисковая система получает дополнительные обозначения. Маркетолог связывает каждое такое обозначение с уже существующим содержимым корпоративного сайта, каталога или блога. Google поддерживает JSON-LD, Microdata и RDFa, рекомендуя первый формат. Выбор записи делает разработчик. Для заказчика существенно другое: когда редактор меняет цену или контакт, новое значение попадает и в видимую страницу, и в описание для робота. Ручное заполнение второй копии данных легко оставляет устаревшие сведения, о которых человек, редактирующий сайт, даже не знает.

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

Я предпочитаю начать с одного действительно нужного типа и его обновления: небольшой корректный набор проще принять и сопровождать, чем множество автоматически добавленных блоков, среди которых компания не сможет объяснить происхождение цены, рейтинга или даты. Затем тот же подход можно распространить на остальные подходящие страницы.

Какие страницы есть смысл описывать

Сначала составляют короткий перечень шаблонов сайта. Карточка товара, статья, контакты и список разделов содержат разные сведения. По ним выбирают типы, которые поддерживает нужная поисковая система. Для части типов Schema.org отдельного оформления поискового результата нет.

В галерее Google перечислены, в частности, Product, Article, Breadcrumb и Organization. Product описывает товар, Article — статью, Breadcrumb — положение страницы в структуре, Organization — сведения об организации. Этот список помогает обсуждать предмет задания, но не заменяет требования конкретного типа. Объём лучше считать по шаблонам. Когда сотни карточек строятся одинаково, общее изменение охватывает их все. Приёмка при этом включает разные состояния: доступный товар, отсутствие цены, снятую позицию и другие случаи вашего каталога.

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

Для каждого поисковика исполнитель выбирает тип и объясняет ожидаемый результат: какие сведения о товаре или компании он передаст, где они уже показаны человеку и какой официальный документ описывает их использование, поскольку Google и Яндекс поддерживают разные возможности. Поэтому фраза «всё прошло валидатор» требует уточнения: какой инструмент использовался, что он распознал и для какого поискового представления проверялся результат. Технически правильная запись может описывать тип, для которого отдельный результат не предусмотрен.

Цена и наличие берутся из того же каталога

Для карточки товара сначала сверяют смысл цены. Читатель видит стоимость выбранного варианта, определённую валюту и состояние наличия. Разметка передаёт те же сведения. Если на экране показывается одна комплектация, а в данных для робота другая, внешне исправная карточка описывает неверное предложение.

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

У Яндекса в описании товарных данных названы price, priceCurrency и availability. В примере валюта передана как RUB, а наличие — значением InStock. Заказчику достаточно узнать эти обозначения, чтобы попросить выгрузку распознанных значений и сравнить её с карточкой. Менять цену нужно один раз. Я выбираю общие данные каталога для видимого блока и разметки: когда сотрудник меняет цену, новое значение появляется в обоих местах, а ему не приходится искать и редактировать скрытую копию.

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

Статья описывает собственные заголовок, автора и даты

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

В документации Google для Article есть поля author, headline, image, datePublished и dateModified. Для дат используется формат ISO 8601, а сведения о часовом поясе рекомендованы. Маркетолог передаёт исполнителю реальное авторство и правила отображения дат, чтобы тот не выбирал их по времени последней сборки сайта.

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

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

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

Контакты и навигация не расходятся с сайтом

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

В справке Яндекса об организациях используются Organization и более конкретные типы, включая LocalBusiness. Для сети филиалы описываются как отдельные компании, а поддержка openingHours относится к названным в справке типам. Поэтому один общий адрес, автоматически подставленный на все страницы филиалов, требует исправления по смыслу. Контактный справочник удобнее копий. Компания назначает место, где меняются телефон, адрес и часы работы, а исполнитель показывает, какие страницы и блоки получают эти значения после обновления.

Навигационная цепочка описывается типом BreadcrumbList. В нём встречаются name, item и position: название, адрес и положение элемента. Заказчику полезно сравнить их с реальной структурой разделов. После перемещения товара в другую категорию обновляют и путь, передаваемый в разметке.

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

Валидатор отвечает за код, редактор — за сведения

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

Google предлагает Rich Results Test и URL Inspection для технической проверки. Первый показывает распознаваемые расширенные результаты, второй помогает изучать страницу в контексте поиска. Отчёт исполнителя содержит конкретные URL, найденные типы, ошибки и предупреждения. Вместо одного снимка успешного теста попросите перечень адресов и распознанных значений, чтобы маркетолог мог открыть нужную карточку, сравнить цену и наличие с отчётом, а затем повторить то же действие после обычного редактирования товара сотрудником компании. Если предупреждение касается полезных данных, которые у компании есть, их стоит добавить, а если сведения отсутствуют, создавать вымышленные отзывы, рейтинг или свойства ради полного набора полей недопустимо.

Для каталога принимают характерные состояния, для блога — разные шаблоны и авторов, для контактов — филиалы. Затем меняют одно существенное значение и повторяют просмотр результата. Такая проверка показывает не только исходную правильность разметки, но и способность сайта поддерживать её дальше. Если после смены цены сведения для робота остаются прежними, сотрудникам придётся повторять ручную сверку при каждом обновлении каталога.

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

С чего начать заказ микроразметки

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

В задании на доработку сайта можно закрепить следующий результат:

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

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

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