Schema.org / JSON-LD —
связный граф под шаблоны, без конфликтов типов
Проектирую единый JSON-LD @graph: Organization → WebSite → WebPage → контентный тип (Article, Product, FAQ и др.). Поля совпадают с видимым HTML, прогон через Rich Results Test и отчёты enhancements в GSC — чтобы rich results не ломались после релизов.
Почему разметка есть, а rich results нет или сыпятся ошибки?
1
Разрозненные блоки JSON-LD
Каждый плагин или разработчик добавляет свой кусок разметки. В итоге конфликты @type, дубли сущностей и потеря связности.
2
Несоответствие видимому контенту
Разметка обещает одно (цена, рейтинг, дата), а на странице — другое. Google отклонит сниппет или выдаст ручную санкцию.
3
Пропущенные Rich Results
Конкуренты получают аккордеоны FAQ, звёзды, хлебные крошки, а вы — простой сниппет. Разметка не «гарантирует» расширенный результат, но без неё его точно не будет.
4
Никто не проверяет после релиза
Обновили тему/плагин — разметка сломалась. Никто не прогоняет Rich Results Test, пока не заметят падение CTR.
Что входит в Schema.org и микроразметку
Проектирую единый JSON-LD @graph: Organization → WebSite → WebPage → контентный тип (Article, Product, FAQ и др.). Поля совпадают с видимым HTML, прогон через Rich Results Test и отчёты enhancements в GSC — чтобы rich results не ломались после релизов.
Аудит текущей разметки
Сканирование JSON-LD и микроразметки: дубли, пустые поля, конфликт типов, расхождение с контентом. Фиксирую, что ломает Rich Results Test и отчёты в GSC.
- Выборка URL по шаблонам и приоритетным типам
- Сводка критичных и некритичных замечаний
- Связь находок с видимым контентом на странице
Проектирование @graph
Единый связный граф: Organization → WebSite → WebPage → контентный тип. Сквозные @id, без дублей сущностей и «висящих» ссылок.
- Схема сущностей и обязательные поля по типам
- Правила для listing vs detail страниц
- Согласование с брендом и юридическими блоками на сайте
JSON-LD под типы страниц
Article, Product, FAQ, LocalBusiness, HowTo, Service — набор полей под каждый шаблон CMS. В приоритете то, что реально даёт rich result в вашей нише.
- Маппинг полей из CMS/API в Schema
- Ограничения Google по типам (eligible/ineligible)
- Исключение разметки «ради галочки» без видимого эффекта
Интеграция в CMS / код
Генерация из кода или слоя данных, без ручного копипаста на сотнях URL. При мультирегиональности — согласование с hreflang и карточками организации.
- ТЗ для разработки и критерии приёмки
- Кэширование и пересборка при обновлении контента
- Фичефлаги для поэтапного выката
Валидация и регрессии
Rich Results Test, мониторинг enhancements в GSC. Чеклист после обновлений темы, плагинов и массовых правок в шаблонах.
- Набор эталонных URL для смоук-теста
- Алерты на рост ошибок в отчётах
- Документация для поддержки
CTR и эффект в выдаче
Сравнение кликов и CTR до/после по кластерам URL. Связка с гипотезами по title/description — разметка и сниппет работают вместе.
- Срезы по типам страниц и рынкам
- Короткие отчёты для стейкхолдеров
- Очередь доработок по приоритету CTR
Инженерная микроразметка: @graph и типизация
Я не добавляю готовый код из генераторов. Проектирую единый граф сущностей: Organization → WebSite → WebPage → контентный тип. Для каждого шаблона CMS — свой набор полей с обязательной валидацией. Мониторинг CTR до/после и защита от поломок при обновлениях.
Единый @graph — Связываю все сущности через @id и @graph. Googlebot видит контекст, а не разрозненные куски, снижается риск конфликтов.
Типизация под шаблоны страниц — Article/BlogPosting, Product (цена, offers, availability), FAQPage, HowTo, LocalBusiness, Service. Размечаем только то, что даёт видимый Rich Result.
Валидация и соответствие контенту — Каждая страница проходит Rich Results Test. Разметка должна строго совпадать с видимым текстом — иначе риск мануалов.
Контроль эффекта — Сравнение CTR и кликов в GSC до/после внедрения. Связка с гипотезами по Title/Description — разметка и сниппет работают в паре.
Как строится работа с микроразметкой
От инвентаризации текущей разметки — к целевому @graph по типам страниц и устойчивому качеству в тестах.
Шаг 1
Аудит
Сканирую существующий JSON-LD и микроразметку: дубли, пустые поля, конфликты @type, расхождение с видимым HTML. Фиксирую, что реально ломает Rich Results Test. Результат: Отчёт с критическими и некритическими проблемами разметки.
Шаг 2
Разработка спецификации
Спецификация полей по шаблонам CMS, единые @id, генерация из кода или слоя данных. Для мультирегиональности — согласование с hreflang и карточками организации. Результат: Техническое задание на внедрение JSON-LD для всех типов страниц.
Шаг 3
Валидация и мониторинг
Прогон через Rich Results Test, контроль выдачи через GSC, регрессия при обновлениях темы. При необходимости — отдельные правила для Яндекса поверх базовой Schema. Результат: Стабильная разметка, проходящая валидацию, с измеримым приростом CTR.
Примеры результатов
Post-Roy
Сайт по оказанию строительных услуг: промышленные полы и стяжка. Проект начался с нуля: без сайта, домена и цифровой репутации.
lengidroprom.ru
OpenCart-каталог насосного оборудования: переработка шаблонов, защита от ботов, Silo-структура, доверие и унификация 3000+ товарных карточек.
Лично
Эксперт, который ведёт проект
Не прячусь за отделом продаж: приоритеты, разборы и ответы по сути — от стратегии до отчётности.
SEO-стратег
Павел Борушко
Head of SEO @ Texode · Минск / гибрид
SEO-стратег с инженерным мышлением. Веду проекты от запуска с нуля до масштабирования высоконагруженных платформ: JS/SPA, поддомены, мультиязычность и мультирегиональность. Техаудит, стратегии индексации, семантика и структурированные данные — в зоне моей ответственности.
Частые вопросы
Готовы получить расширенные сниппеты и обойти конкурентов в выдаче?
Закажите разбор разметки — покажу, что теряете, и построю план внедрения.
Бесплатная первичная консультация