Вы добавили JSON-LD, заполнили обязательные поля и получили зеленый статус. Но у товара нет цены в выдаче, у компании - звезд, а у статьи - заметного оформления. Возникает логичный вопрос: если микроразметка правильная, почему поисковик ее не показывает?
Основной разбор ниже относится к Google: здесь есть инструмент Rich Results Test и отдельные отчеты Search Console. Особенности Яндекса рассмотрим отдельно, поскольку результаты проверки одной поисковой системы нельзя автоматически переносить на другую.
Что на самом деле проверяет валидатор
Фраза «микроразметка прошла проверку» неполная. Важно уточнить, каким инструментом ее проверяли, передавали ли ему URL или только фрагмент кода и какой именно объект оказался корректным.
| Инструмент | Что можно выяснить | Чего результат не доказывает |
|---|---|---|
| Schema.org Markup Validator | Какие сущности и свойства извлечены; есть ли синтаксические ошибки. | Что Google поддерживает для этих данных отдельный поисковый формат. |
| Google Rich Results Test | Какие поддерживаемые инструментом типы найдены и какие проблемы обнаружены. | Что Google уже обработал эту версию в индексе и покажет расширение по конкретному запросу. |
| Проверка URL в Search Console | Что известно об индексированной странице; отдельно - что доступно при live-проверке. | Что текущая live-версия уже заменила индексированную. |
| Отчет об улучшениях | Какие элементы разметки обнаружены и какова их валидность. | Что каждый корректный элемент получил показ в выдаче. |
Например, проверка может найти корректный BreadcrumbList, но это ничего не говорит о готовности Product. Раскройте найденные объекты и проверьте именно тот, от которого ожидаете цену, рейтинг или другой элемент оформления.
Второе различие - проверка кода и проверка опубликованного адреса. Скопированный JSON-LD может работать идеально, хотя на реальной странице осталась старая версия или скрипт вообще не загружается. Для диагностики внедрения нужен тест конечного URL.
Поддерживается ли нужный формат расширенного результата
Schema.org - словарь сущностей и свойств. Наличие типа в этом словаре не означает, что Google создал для него самостоятельный расширенный результат. Сначала определите, какой визуальный элемент вам нужен, затем найдите его в актуальной галерее поисковых функций Google.
- Для цены и наличия товара изучают правила товарных результатов.
- Для рейтинга - правила отзывов и допустимых объектов оценки.
- Для статьи - возможности Article и BlogPosting.
- Для навигационной цепочки - требования BreadcrumbList.
Обратная логика часто приводит к лишней работе: разработчик добавляет максимально подробный объект, а затем команда пытается получить визуальный формат, которого для этой задачи нет. Например, Service сам по себе не включает универсальный сниппет услуги с ценой и звездами.
Проверяйте также региональную доступность и ограничения конкретной функции. Скриншот из зарубежной выдачи или старой инструкции не является техническим заданием на воспроизводимый результат.
Почему не появляются FAQ и звезды компании
FAQ: старые рекомендации больше не работают
Сам раздел вопросов и ответов может оставаться полезным: он объясняет условия услуги, снимает сомнения и помогает читателю. Сохранить такой контент разумно. Но оценивать его успех по появлению раскрывающихся FAQ в Google теперь бессмысленно. Валидность FAQPage по Schema.org и существование поисковой функции - разные вещи.
Отзывы о компании на ее собственном сайте
Для LocalBusiness и Organization Google ограничивает так называемые self-serving reviews. Если организация размещает отзывы о себе на собственном сайте, такая разметка не дает права на звезды отзывов. Встроенный виджет сторонней площадки не обходит ограничение.
Предположим, агентство выводит рейтинг из карт и размечает его как AggregateRating у своей организации. Исправление JSON, увеличение числа отзывов или смена SEO-плагина не устранят ограничение формата. При этом отзывы на странице могут помогать посетителю выбрать исполнителя.
Не переносите этот вывод автоматически на все отзывы интернет-магазина: оценки конкретных товаров рассматриваются по соответствующим правилам. И не меняйте тип организации на товар только ради обхода ограничений - сущность должна соответствовать действительному содержимому.
Google видит другой URL или прежнюю версию страницы
Разметку проверяют на одном адресе, а в выдаче участвует другой. Например, правильный код опубликован на URL с параметром, тогда как Google выбрал основной адрес без параметра. Или исправили новую страницу, но в индексе еще находится ее прежняя версия.
В проверке URL сравните дату последнего сканирования, каноническую страницу, указанную сайтом, и каноническую страницу, выбранную Google. Выбор Google доступен в данных индексированной версии; live-проверка не предсказывает итоговую канонизацию.
Если адреса отличаются, полезно сначала разобраться, почему Google выбрал другой canonical. Проверяйте разметку на выбранной основной странице и согласованность дублей, прежде чем многократно менять код на второстепенном URL.
Когда URL вообще не индексируется, задача шире микроразметки. Изучите причину исключения: недоступность, запрет индексирования, дублирование или другое состояние. Отдельный пример - ошибка Soft 404, при которой успешный HTTP-ответ не означает, что поисковик признал страницу полноценной.
JavaScript, кэш и конфликтующие шаблоны
Google способен обрабатывать структурированные данные, добавленные JavaScript. Проблема возникает, когда нужный объект отсутствует в том DOM, который получается при обработке страницы поисковой системой. Проверка исходного HTML и проверка отрисованного документа решают разные задачи.
Примеры возможных причин для проверки: тег запускается только после действия пользователя; запрос к API завершается ошибкой; система согласий не разрешает запуск; CDN отдает старую версию. Это диагностические гипотезы - подтвердите их в коде проверенной страницы, а не по одному скриншоту браузера.
Если данные меняются быстро, особенно важна синхронизация. Google отдельно предупреждает о меньшей надежности и частоте Shopping-обхода при динамически создаваемой Product-разметке. Для товарных данных рекомендует включать разметку в исходный HTML.
Несколько источников разметки - повод проверить согласованность
CMS, тема, SEO-плагин и ручная вставка могут одновременно описывать один объект. Само наличие нескольких блоков JSON-LD не является ошибкой. Практическая проблема - когда они содержат противоречащие друг другу цену, наличие, название или рейтинг.
Условный пример: карточка показывает 12 900 ₽, тема генерирует Offer с 11 900 ₽, а дополнительный модуль - еще один Offer со старой акцией. Каждый фрагмент может быть синтаксически корректным. Исправлять нужно источник данных и правила генерации, а не только оформление JSON.
Для разработчика полезно зафиксировать, какой модуль отвечает за каждую сущность и откуда получает значения. Это упрощает проверку после обновления CMS или смены шаблона.
Разметка не соответствует контенту или правилам качества
Автоматическая проверка не заменяет оценку достоверности. Скрытый рейтинг, несуществующий отзыв, устаревшая цена или объект, не соответствующий главному содержимому страницы, могут оставаться синтаксически правильными.
Сверяйте данные с тем, что доступно посетителю: название объекта, условия предложения, оценку, количество отзывов, даты и изображения. Размечайте факты, которые действительно представлены на странице, и поддерживайте их актуальность.
В Search Console отдельно проверьте раздел «Меры, принятые вручную». Мера именно за нарушение правил структурированных данных лишает страницу права на расширенное оформление; сама по себе она не означает снижение позиций обычного веб-результата. Если мера обнаружена, исправляйте указанное нарушение и следуйте процедуре пересмотра.
При этом отсутствие звезд не является доказательством санкции. Без сообщения о ручной мере и других подтверждений нельзя объявлять сайт наказанным.
Отдельные проверки для товаров и статей
Карточка товара: какой результат вы проверяете?
У Google есть пересекающиеся, но разные возможности: product snippets и merchant listings. Первые относятся к товарным сниппетам, вторые - к предложениям продавцов на страницах, где можно купить товар. У них отличаются требования и отчеты; успешная проверка одного набора данных не закрывает все вопросы по другому.
Товарные расширения рассчитаны на страницы конкретного товара или вариантов одного товара. Категория «Все диваны» не становится карточкой товара после добавления Product. Начинайте с правильного типа страницы.
Для товарного сниппета обязательны название и хотя бы одно из свойств offers, review или aggregateRating. Поэтому корректный Product с предложением может не содержать рейтинга вообще. Отсутствующие реальные отзывы нельзя компенсировать вымышленной оценкой.
- Сверьте цену, валюту и наличие с выбранным вариантом товара.
- Убедитесь, что рейтинг относится к этому товару, а не ко всему магазину.
- Проверьте доступность изображения и соответствие реальному объекту.
- Отдельно изучите требования merchant listings, если рассчитываете на возможности для продавцов.
Если одинаковые расхождения встречаются по всему каталогу, включайте исправление шаблонов и товарных данных в продвижение интернет-магазина. Ручная корректировка нескольких карточек не устранит общий источник ошибок.
Статья: Article не обещает отдельную большую карточку
Article и BlogPosting помогают сообщить поисковику сведения о публикации: заголовок, автора, изображения и даты. Но сама разметка не гарантирует крупную иллюстрацию или особое место в выдаче. Проверять нужно достоверность данных статьи и требования к ее изображениям, а ожидания соотносить с доступными поисковыми форматами.
Не смешивайте расширенные результаты с цитированием в AI Overviews и AI Mode. Google не требует специальной schema.org-разметки для этих функций. Если цель - видимость в ИИ-поиске, это отдельная задача, которую мы рассматриваем в статье как попасть в ответы ИИ Google.
Порядок диагностики в Search Console
Начинайте с одного конкретного URL и одного ожидаемого элемента. Формулировка «на сайте не работает микроразметка» слишком широкая. Удобнее: «у карточки модели X нет цены в обычном результате Google по таким-то запросам».
Зафиксируйте исходные данные
Сохраните адрес, тип страницы, ожидаемый формат, дату публикации изменений и результат теста. Если проблема затрагивает шаблон, возьмите несколько характерных URL: новый, давно опубликованный и страницу с отличающимся состоянием, например товаром без наличия.
Проверьте опубликованный URL
В Rich Results Test раскройте нужный объект. Выпишите ошибки, предупреждения и фактически извлеченные значения. Не ограничивайтесь зеленой строкой: убедитесь, что проверяется нужная сущность. Посмотрите HTML после отрисовки, особенно если разметку создает JavaScript.
Разделите индексированные и текущие данные
В Search Console сначала посмотрите сохраненные сведения о URL, затем запустите проверку опубликованной страницы. Если исправление присутствует только в текущей версии, еще нельзя считать, что оно уже учтено поиском. Не смешивайте результаты этих двух проверок в одном выводе.
Изучите отчет нужного типа
Откройте соответствующий отчет улучшений или раздел товарных результатов. В нем учитываются элементы разметки, а не обязательно уникальные страницы. Список примеров не является полным перечнем всех найденных объектов. Отсутствующий в списке URL проверяйте отдельно.
Критическая ошибка и некритическое предупреждение имеют разный приоритет. Если элемент допустим, предупреждение не обязательно блокирует показ. Устраняйте его, когда можете добавить достоверные сведения; не заполняйте необязательное поле случайными значениями ради идеального отчета.
Проверьте масштаб и подтвердите исправление
Если сбой повторяется только в одном шаблоне, ищите причину в его генераторе данных. Если после одного обновления пострадали разные разделы, проверьте общие компоненты. После исправления повторите проверку URL и используйте подтверждение исправления в отчете, если такая функция доступна для проблемы.
Ошибка или обычное поведение поиска: как различить
| Наблюдение | Что это может означать | Что делать |
|---|---|---|
| Schema.org ошибок не показывает, Rich Results Test не находит нужного объекта. | Тип не поддерживается тестом либо нужная разметка не извлечена. | Сверить галерею Google и отрисованный HTML. |
| Корректны только хлебные крошки, а ожидаются звезды. | Проверен другой объект. | Проверить рейтинг, тип оцениваемой сущности и ограничения. |
| Текущая версия исправна, данные в индексе старые. | Изменения еще не отражены в индексированной версии. | Проверить дату обхода и запросить обработку важных URL. |
| URL исключен из индекса или выбран другой canonical. | Проблема связана с участием страницы в поиске. | Сначала разобраться с индексированием и основной версией. |
| В отчете есть корректные элементы, показов расширения мало. | Валидность не равна частоте показа. | Сравнить запросы, устройства и доступные данные о виде результата. |
| Ожидается FAQ в Google после мая 2026 года. | Этот формат больше не показывается. | Пересмотреть цель внедрения FAQPage. |
Такая таблица помогает отделить исправимые дефекты от ожиданий. У дефекта должно быть проверяемое проявление: неправильное значение, отсутствующий объект, недоступный ресурс или конкретное нарушение. Если все подтверждено, но поисковик выбирает обычный результат, бесконечная замена плагинов не становится обоснованным решением.
Когда ждать изменений и как оценивать результат
Google указывает, что повторное сканирование может занимать от нескольких дней до нескольких недель. Это ориентир для обхода, а не срок появления расширенного сниппета. Запрос индексирования не гарантирует немедленное включение страницы в поиск, а повторные запросы для одного адреса не ускоряют процесс.
После внедрения фиксируйте дату изменения и наблюдайте за обработкой URL. Для небольшого числа важных страниц используйте запрос индексирования, для большого объема поддерживайте актуальный sitemap. Ежедневно переписывать корректную разметку только из-за отсутствия расширения не нужно.
В отчете «Эффективность» сравнивайте показы, клики, CTR и позицию по нужным страницам. Используйте разрезы запросов, стран, устройств и вида в поиске, когда соответствующая категория доступна. Один ручной поиск не отражает все показы сайта: выдача зависит от условий поиска.
Для оценки эффекта выберите сопоставимые периоды, например по 28 дней при достаточном объеме данных. Это рабочий способ анализа, а не требование Google. Отдельно отметьте изменения цен, сезонность, акции, позиции и переработку контента: они тоже влияют на кликабельность.
Не считайте рост CTR доказательством влияния одной микроразметки. Полезнее сформулировать осторожный вывод: «После внедрения появились показы нужного типа; по выбранной группе страниц изменилась кликабельность». Причинную связь нужно проверять отдельно.
Что учитывать, если расширенного сниппета нет в Яндексе
Для Яндекса используйте его собственный валидатор и документацию конкретного формата. Инструмент проверяет распознавание метаданных и требования сервисов Яндекса; корректность для Google не заменяет эту проверку.
В справке по товарной разметке Яндекс прямо указывает, что полученная информация не обязательно появится в поиске. Поэтому и здесь нужно разделять проверку данных, переобход и решение об оформлении результата. При этом ограничения Google для FAQ или self-serving reviews нельзя автоматически объявлять правилами Яндекса.
Частые вопросы
Зеленый статус означает, что все сделано правильно?
Он означает, что проверяемый объект прошел конкретные проверки инструмента. Дополнительно нужны проверка содержимого страницы, правил формата и данных в индексе.
Нужно ли устранить абсолютно все предупреждения?
Сначала исправляют критические ошибки. Предупреждения оценивают по их смыслу: рекомендуемые поля полезно заполнять реальными данными, но их отсутствие не всегда делает объект недопустимым.
Почему у конкурента звезды есть, а у нас нет?
Сравните тип результата, объект оценки, страницу, запрос, устройство и страну. Одинаковая тематика сайтов еще не означает одинаковые условия показа. Чужой сниппет не доказывает, что нужно копировать чужой код.
Нужно ли удалить микроразметку, если визуально ничего не изменилось?
Сначала выясните ее назначение и качество. Отсутствие заметного изменения не является достаточным основанием для удаления корректных данных. Ошибочную или вводящую в заблуждение разметку нужно исправить либо убрать.
Можно ли просто перейти на JSON-LD?
JSON-LD удобен для сопровождения, однако сам переход между поддерживаемыми форматами не решает проблему неподходящей сущности, закрытой страницы или недостоверных данных.
Может ли проблема быть в SEO-плагине?
Да, если он выводит неверные значения, конфликтует с другим источником или не публикует нужный объект. Это проверяют по фактическому HTML. Название плагина само по себе ничего не доказывает.
Какой первый шаг самый полезный?
Назвать конкретный ожидаемый формат и проверить, поддерживает ли его Google для такого содержимого. После этого последовательно сравнить опубликованный URL, нужный объект и индексированную версию.
