-
Код
Сущности и поля
-
Страница
Видимые сведения и доступ
-
Требования
Поддерживаемый формат
-
Наблюдение
Обход и фактический показ
Успешная проверка микроразметки подтверждает не всё, что нужно для расширенного результата. Google отдельно оценивает доступность страницы, поддержку типа, соответствие содержимому и правилам поиска. Даже исправная разметка не гарантирует специальное оформление. Начните с конкретного URL, типа результата и даты последнего изменения.
Разделите три разных проверки
| Уровень | На какой вопрос отвечает | Чего не доказывает |
|---|---|---|
| Синтаксис | Можно ли разобрать JSON-LD и свойства | Поддержку этого типа в Google |
| Пригодность | Выполнены ли условия конкретного результата | Выбор формата для каждого показа |
| Отображение | Что фактически показано по запросу | Постоянство такого оформления |
Общие ограничения изложены в правилах Google для структурированных данных. Проверка произвольной сущности Schema.org и проверка кандидата на поддерживаемый расширенный результат — не одно и то же.
Учебный пример: товар с устаревшим предложением
На учебной карточке видна цена 12 500 ₽ и отсутствие товара. В JSON-LD остались 11 900 ₽ и наличие. Синтаксический анализатор может прочитать такой документ без ошибки формата, но сведения противоречат странице. Исправлять нужно источник цены и наличия, а не добавлять ещё один блок разметки поверх старого.
Сравните выбранный вариант товара, видимый текст и конечный URL. Для магазина проверьте также обновление каталога и фида. Подробности товарных сущностей — в статье о несовпадении цены и наличия; не путайте отклонение в Merchant Center с оформлением обычного результата поиска.
Порядок диагностики одного URL
- Зафиксируйте ожидаемый тип результата и проверьте его актуальную документацию.
- Откройте конечный адрес без входа и убедитесь в доступности основного содержания.
- Сопоставьте canonical, индексируемый адрес и проверяемую страницу.
- Запустите проверку расширенных результатов по URL, а не только по вставленному коду.
- Сравните поля с видимой страницей и источником данных.
- В Search Console проверьте известную Google версию и соответствующие сообщения.
Инструкция Google по диагностике помогает отделить проблему внедрения от отсутствия показа. Без доступа к Search Console внешний анализ не подтверждает, какую версию страницы уже обработал Google.
Несколько сущностей и несколько источников
На одной странице могут находиться Organization, BreadcrumbList и Product — само количество сущностей не является ошибкой. Проблема возникает, когда разные модули публикуют противоречащие предложения или одну организацию описывают как разных несвязанных участников.
Запишите, какой шаблон, модуль или система создаёт каждый блок. После исправления страницы проверьте исходный HTML и доступный роботу результат отрисовки. Удаление всех сущностей ради одного зелёного сообщения может повредить корректную информацию, не решив исходную причину.
Как принять исправление
Выберите несколько страниц одного шаблона: доступный товар, отсутствующий товар и вариант с изменённой ценой. Для каждой зафиксируйте URL, тип сущности, поля до и после, результат проверки и дату. Числа в учебном примере не являются требуемым набором цен или нормативом выборки.
После публикации повторите тест по публичному адресу. Отслеживайте сообщения соответствующего отчёта и фактические показы, если они доступны. Не заменяйте проверку отчётом «добавили JSON-LD». Для первичного разбора можно использовать проверку страницы, но она не знает решения поисковой системы.
Как оформить проверку и передать исправление
Проверьте данные для выбранного варианта
В учебной карточке одного изделия есть разные объёмы упаковки. Пользователь выбрал большую, но URL и JSON-LD остались от маленькой. До исправления выясните, как магазин описывает варианты, какие адреса считает самостоятельными и что именно получает проверяющий инструмент без пользовательского нажатия.
Не подменяйте все предложения одним случайным значением, чтобы убрать предупреждение. Правильная модель должна соответствовать товару, доступному выбору и видимым условиям. При сложном каталоге сначала согласуйте структуру с разработчиком и владельцем данных, затем проверяйте её на доступном, отсутствующем и изменённом варианте.
Разведите ошибки и предупреждения
Отсутствующее обязательное поле, необязательная рекомендация и нарушение требований содержания требуют разного решения. Записывайте точный тип сообщения и сущность. Список предупреждений без этого быстро превращается в набор бессмысленных задач: добавить любую информацию только ради полностью зелёного отчёта.
Если нужных сведений нет, не придумывайте их. Например, срок доставки должен опираться на реальные условия магазина, а рейтинг — на допустимый источник. Полезнее оставить неприменимое необязательное поле отсутствующим, чем заполнить его вымышленным значением. Окончательный выбор сверяют с текущими требованиями конкретного формата.
Что считать результатом внедрения
Технический результат — согласованные поля на публичных страницах, отсутствие выявленных ошибок и понятный источник обновления. Наблюдение в поиске — отдельный этап с датой, запросом и доступными отчётами. Сохраняйте различие, даже если заказчику хочется получить одну отметку «готово».
После изменения шаблона проверьте соседние разделы: модуль может формировать разметку не только для товаров, но и для категорий или служебных страниц. В журнале укажите область правки и контрольную выборку. Если специальное оформление уже появилось, не обещайте его постоянство для всех запросов и устройств. Это наблюдение помогает оценке, но не превращается в гарантию.
К отчёту приложите проверенные адреса и точные сообщения инструментов, чтобы следующий специалист смог повторить диагностику.
Ошибки, которые не помогают
- Добавлять вымышленные рейтинги ради звёзд.
- Обещать расширенный результат сразу после изменения кода.
- Проверять только фрагмент, отличный от публичной страницы.
- Игнорировать устаревший тип результата или требования к его применению.
- Считать отсутствие специального оформления доказательством санкции.
Частые вопросы
Есть ли срок появления?
Универсального срока нет. Нужно отделять повторную обработку страницы от решения о конкретном показе; обещать дату нельзя.
Нужно ли удалять корректную разметку, если оформление не появилось?
Не только по этой причине. Сначала проверьте назначение, соответствие странице и актуальные требования.
Что передать на аудит?
Несколько URL, ожидаемый тип результата, последние изменения и доступные сообщения Search Console. Определение Rich Results поможет сформулировать задачу; следующий шаг — обсуждение SEO-проверки.
