Коротко. Самые частые ошибки микроразметки — это сломанный синтаксис JSON-LD (страница теряет расширенный сниппет полностью), несовпадение разметки с видимым контентом (риск ручной санкции на весь тип разметки по сайту) и дублирование объектов от старого и нового плагина одновременно. Первая ошибка стоит сниппета на одной странице, вторая — на всём сайте по этому типу данных, и различать их важно, потому что цена исправления отличается в разы.
Почему не все ошибки одинаково опасны
Прежде чем разбирать конкретные ошибки, стоит развести два разных исхода. Первый — разметка просто не читается или неполна, и тогда сайт теряет только потенциальный сниппет, ничего не теряя из того, что уже было. Второй — разметка читается, но противоречит правилам или видимому контенту, и здесь под угрозой не упущенная возможность, а действующий результат: ручная санкция снимает уже работающий расширенный сниппет по всему типу разметки на сайте, а не на одной странице. Ошибки ниже расположены примерно по возрастанию цены исправления и риска.
Ошибка 1: синтаксис JSON-LD не парсится
Лишняя запятая перед закрывающей скобкой, незакрытая кавычка, дублирующийся ключ в объекте — любая из этих опечаток приводит к тому, что парсер отбрасывает весь блок целиком, а не только повреждённое поле. Для стороннего наблюдателя (и для владельца сайта, который просто открывает страницу в браузере) это незаметно — блок <script type="application/ld+json"> в исходном коде виден, но фактически не работает. Чем грозит: полное отсутствие расширенного сниппета там, где он мог бы быть, без единого предупреждения в интерфейсе сайта — заметить проблему можно только через валидатор. Если разметка формируется шаблоном автоматически, ошибка обычно системная и повторяется на всех страницах этого шаблона одновременно.
Ошибка 2: не хватает обязательного поля для конкретного типа
У каждого типа schema.org свой минимальный набор полей, без которого объект не считается пригодным для расширенного результата — например, для Product это имя и хотя бы один из блоков offers, review или aggregateRating. Разница с предыдущей ошибкой: разметка синтаксически валидна и читается, просто неполна. Чем грозит: сниппет не появляется именно для этого объекта, при этом остальная часть страницы и остальные типы разметки не страдают — ошибка локальна. Встречается чаще всего после смены шаблона карточки товара или услуги, когда часть полей осталась не перенесённой из старой версии.
Ошибка 3: разметка не совпадает с видимым контентом
Самая рискованная категория. Цена в разметке отличается от цены на странице, рейтинг в aggregateRating не подтверждён видимыми отзывами, FAQ-разметка описывает вопросы, которых нет в тексте, — всё это нарушение требования поисковых систем к соответствию структурированных данных содержимому страницы. Чем грозит: не просто отказ в показе сниппета, а ручная санкция, после которой расширенные результаты этого типа пропадают по всему сайту, а не на одной странице. Возврат требует не только исправления причины, но и подачи запроса на пересмотр — то есть недели, а не часы. Частый источник этой ошибки — рассинхронизация: цену на странице обновили через админку, а в разметке она осталась зашита в шаблоне со старым значением, потому что источники данных не связаны между собой технически.
Ошибка 4: дублирование и конфликт объектов одного типа
Возникает почти всегда после смены инструмента разметки: старый плагин или ручной блок в шаблоне не удалили, когда подключили новый — на странице одновременно оказываются два объекта Organization с разными телефонами или два Product с разными ценами. Формально каждый блок может быть валиден по отдельности, но парсер поисковика получает противоречивые данные об одном и том же объекте. Чем грозит: непредсказуемое поведение — иногда система берёт один источник, иногда другой, а иногда отказывается показывать сниппет вообще, потому что не может разрешить конфликт. Обнаружить проще всего по количеству найденных объектов одного типа в отчёте валидатора — если их больше, чем должно быть логически, источник почти всегда старая неудалённая разметка.
Ошибка 5: устаревшие или неподдерживаемые для сниппета типы
Отдельная категория — не техническая ошибка, а несоответствие политике конкретного поисковика. С 2023 года Google ограничил показ FAQPage и HowTo преимущественно авторитетными сайтами независимо от валидности разметки; self-serving Review-разметка (отзывы о собственных товарах без независимого источника) не даёт звёзд рейтинга по правилам Google с 2019 года. Чем грозит: разметка технически безупречна, валидатор не покажет ни одной ошибки, но сниппета не будет — и никакая правка кода это не изменит, потому что причина не в качестве данных, а в правилах поисковика для этого типа. Такие ограничения стоит учитывать при планировании SEO-продвижения заранее, а не тратить время на бесплодные правки уже корректного кода.
Сводная таблица: ошибка → последствие → приоритет исправления
| Ошибка | Что теряет сайт | Масштаб | Приоритет |
|---|---|---|---|
| Синтаксис JSON-LD не парсится | Сниппет полностью, без сигнала в интерфейсе | Обычно системный (весь шаблон) | Высокий |
| Не хватает обязательного поля | Сниппет для конкретного объекта | Локальный или системный | Средний |
| Разметка не совпадает с контентом | Риск ручной санкции по всему сайту для этого типа | Весь сайт по типу данных | Критический |
| Дублирование объектов | Непредсказуемое поведение сниппета | Локальный, но легко тиражируется | Средний |
| Ограниченный политикой тип (FAQPage, HowTo, self-serving Review) | Сниппет не появится независимо от качества разметки | Весь сайт для этого типа | Низкий — исправлять код бессмысленно |
Как не допускать повторения ошибок
Большинство перечисленных ошибок — не разовая случайность, а следствие того, что разметка формируется в нескольких несвязанных местах: контент правит редактор через админку, а разметка зашита в шаблоне разработчиком отдельно. Надёжного технического способа полностью исключить рассинхронизацию нет, но снизить риск можно: выводить значения разметки из тех же полей CMS, что и видимый контент, а не дублировать их вручную, и проверять ключевые типы страниц (карточка товара, страница услуги, главная) заново после любого обновления шаблона или плагина, а не только при первом внедрении. Регулярный контроль за этим обычно входит в задачи технической поддержки сайта. Системную проверку по всему сайту, а не по одной странице, разумно закладывать в рамки технического SEO-аудита — вручную отследить рассинхронизацию на каталоге из сотен карточек нереалистично.
Частые вопросы
Какая ошибка чаще всего встречается на практике?
Рассинхронизация цены или наличия товара между видимым контентом и разметкой — она возникает при каждом обновлении цены, если оба значения не связаны технически одним источником данных.
Можно ли получить санкцию за случайную ошибку в разметке, если не было умысла?
Да, поисковые системы не разбирают умысел — оценивается фактическое несоответствие разметки видимому контенту, вне зависимости от того, произошло это специально или из-за технической рассинхронизации.
Как быстро обнаружить, что разметка сломана после обновления сайта?
Прогнать несколько ключевых страниц через валидатор сразу после любого обновления шаблона, плагина или CMS — большинство ошибок этой категории появляются именно в момент технических изменений, а не сами по себе.
Стоит ли удалять разметку, если её сложно поддерживать в актуальном состоянии?
Отсутствие разметки — не ошибка и не наказывается, это упущенная возможность. Если ресурсов на поддержание актуальности нет, безопаснее не размечать тип данных вообще, чем держать разметку, которая регулярно расходится с контентом.
Как отличить временную задержку от реальной ошибки после исправления?
После правки нужно время на повторный обход страницы роботом — от нескольких дней до 3-4 недель в зависимости от частоты сканирования сайта. Если валидатор уже показывает «валидно», а сниппета всё ещё нет — это, скорее всего, ожидание, а не новая ошибка.
Найти ошибки микроразметки на всём сайте, а не на одной странице
Проверим ключевые шаблоны сайта на рассинхронизацию, дубли и синтаксические ошибки и покажем, что чинить в первую очередь.