Schema.org на сайте — описание сущностей вместо пересказа страницы

На карточке товара уже есть цена, наличие и характеристики. На странице компании — адрес и контакты. Кажется, что поисковик всё прочитает сам. Иногда прочитает, но разметка Schema.org позволяет передать эти сведения в явной структуре: не просто строка «Москва», а адрес организации; не просто число, а цена предложения.

Schema.org — это словарь типов и свойств для описания сущностей. JSON-LD, Microdata и RDFa — форматы, в которых этот словарь можно записать в страницу. Эти три понятия часто смешивают, а затем ждут от «микроразметки» автоматических звёзд и роста позиций.

Разметка не добавляет факты сайту. Она делает проверяемее те факты, которые сайт уже готов показать человеку.

Первый слой — словарь Schema.org: например, Organization, Product, Article, их свойства и связи. Второй — способ передать данные в HTML. Google в большинстве случаев рекомендует JSON-LD: блок данных можно поддерживать отдельно от видимой разметки, а не встраивать атрибуты в каждый элемент интерфейса. Третий слой — потребитель: поисковик, приложение или другой сервис решает, что он поддерживает и как использует данные.

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

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

Перечень функций меняется независимо от словаря. На дату проверки Google продолжает документировать, в частности, Product, фрагменты отзывов и BreadcrumbList, но больше не показывает расширенные результаты для HowTo, а показ расширенных результатов FAQ прекращён 7 мая 2026 года. Яндекс отдельно документирует поддерживаемые сценарии, включая товарные данные и навигационные цепочки. Существование FAQPage, HowTo или другого типа в Schema.org не подтверждает поддержку поискового оформления ни одной системой.

Тип отвечает на вопрос «что это?». Свойства уточняют его: у товара есть название, описание, предложение и цена; у статьи — заголовок, автор, дата публикации; у организации — имя, адрес, телефон. Вложенная сущность показывает связь: Offer относится к конкретному Product, а не висит на странице как случайное число.

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

Это особенно важно для интернет-магазина: данные карточки часто живут в CMS, учёте и витрине одновременно. Разметка, которая обновляется вручную в шаблоне, быстро начинает расходиться с ценой и наличием на экране.

Когда одна и та же сущность встречается на нескольких связанных страницах, ей нужен устойчивый идентификатор. В JSON-LD для этого используют @id: он идентифицирует узел графа и помогает связать описания одной организации, товара или автора, а не создавать несколько похожих объектов без отношения друг к другу. @id не объявляет страницу канонической и не заменяет rel="canonical", который относится к выбору предпочтительного URL документа. Идентификатор выбирают стабильно и меняют только вместе с идентичностью сущности или моделью данных, а не автоматически при каждом изменении адреса страницы.

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

Главный критерий не формат, а владение данными. Команда должна понимать, где формируются значения, кто отвечает за схему и как изменения проходят проверку. Если разработчик прописал JSON-LD разово, а редакция затем меняет страницу вручную, ошибка станет вопросом времени. Устройство CMS напрямую влияет на этот риск.

title, description и Open Graph описывают документ или карточку ссылки. Schema.org описывает сущности и их свойства. Нельзя заменить одно другим: Open Graph не делает товар структурированным для поисковой функции, а JSON-LD не обязан создавать красивое превью в мессенджере. Практическая граница полей разобрана в статье о мета-тегах страницы.

Не стоит также добавлять максимальное число типов «на всякий случай». Лишняя или противоречивая разметка усложняет поддержку и может не соответствовать видимой странице. Минимальный полезный набор почти всегда лучше каталога полей, смысл которых никто не проверяет.

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

Перед публикацией разметку проверяют в валидаторе Schema.org и в Google Rich Results Test для поддерживаемых Google функций; распознавание разметки Яндексом можно отдельно проверить его валидатором микроразметки. Затем смотрят исходный ответ URL, а не только локальный шаблон: данные могут исчезнуть из-за кеша, ошибки сборки или условия в CMS. После релиза полезно мониторить отчёты поисковых консолей и выборку реальных страниц.

Проверка синтаксиса не подтверждает бизнес-истину. Валидатор не знает, существует ли товар, актуальна ли цена и видит ли пользователь тот же текст. Нужна связка из четырёх вопросов:

Если URL закрыт от робота или не становится основной версией, корректный JSON-LD не обходит эти условия. Сначала следует проверить индексацию сайта, а уже затем спорить о поисковом представлении.

У проверки есть четыре разных уровня. Синтаксис отвечает, читается ли JSON-LD, Microdata или RDFa. Валидатор Schema.org проверяет разметку относительно словаря, но не пригодность для расширенного результата. Бизнес-проверка устанавливает, соответствует ли значение видимой странице и источнику данных. Наконец, тест конкретной поисковой функции ищет её обязательные и рекомендуемые свойства, но не подтверждает будущий показ. Прохождение одного уровня не отменяет остальные.

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

На странице компании другая задача: Organization помогает связать название, адрес и контактные данные. У статьи — Article, когда на экране есть сам материал, заголовок и дата. Один URL не обязан одновременно быть товаром, организацией, FAQ и мероприятием. Выберите главную сущность страницы, а вложенность используйте только там, где она объясняет реальную связь данных.

Для команды это ещё и вопрос выпуска. Изменился шаблон карточки — проверьте выборку товаров с наличием, без наличия, с вариантом и без цены. Изменилась CMS — убедитесь, что блок JSON-LD не выводит пустые свойства. Такая проверка предметнее, чем отчёт «добавили микроразметку на сайт».

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

Разметку также не стоит ставить первой в очереди, когда важные URL возвращают ошибки, дублируются или не связаны навигацией. В таком случае полезнее устранить препятствие на маршруте, а к Schema.org вернуться после стабилизации. Техническая последовательность часто выглядит скромнее, чем обещание rich results, зато её можно проверить.

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

Редактор отвечает за достоверность текста и даты, владелец каталога — за товарные данные, разработчик — за вывод схемы, SEO-специалист — за соответствие поисковому сценарию и выборку после публикации. В маленькой команде эти роли может выполнять один человек, но сами вопросы не исчезают. Без них разметка превращается в блок кода, который никто не решается менять.

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

Полезный результат такой работы измеряется не количеством полей в JSON-LD, а отсутствием противоречий: человек, CMS, шаблон и поисковая система видят одну и ту же сущность. Если при обновлении товара меняется только одна из этих версий, задача ещё не решена.

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

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

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

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

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