Невозможно предварительно просмотреть расширенные результаты поиска Google в инструменте тестирования丨Как исправить ошибки расширенных результатов поиска

Проще говоря: вы используете официальный инструмент тестирования Google, и он показывает «Расширенные результаты не обнаружены»;

но при проверке в Search Console (Панель управления поиском) появляется уведомление «Отсутствует поле offer» (например, цена товара или информация о наличии указаны неверно).

Это происходит потому, что при сканировании Google полностью выполняет JavaScript менее чем на 40% страниц. Многие разметки товаров (Product), генерируемые динамически с помощью JS, просто не попадают в поле зрения поискового робота.

Например, на одном интернет-магазине продуктов питания в разметке рецептов (Recipe) не были добавлены подпункты «пищевая ценность» (nutrition) (такие как калории, содержание белка). В результате количество отображаемых «карточек рецептов с информацией о пищевой ценности» сократилось более чем наполовину (показатель показов упал на 62%), что привело к потере тысяч кликов ежедневно.

У другого новостного сайта был неверно указан формат «даты публикации» (datePublished) в разметке статей (Article) (например, «2023/12/31» вместо стандартного «2023-12-31»). Из-за этого горячие новости не попадали в «избранные сниппеты» (заметные карточки в верхней части страницы результатов поиска), что лишило сайт значительного охвата.

Этапы диагностики

Судя по данным, распределение проблем довольно четкое: около 65% неудач при предварительном просмотре вызваны ошибками в коде JSON-LD или отсутствием обязательных свойств (например, поле не заполнено или формат неверен);

20% связано с тем, что на странице используется динамическая загрузка контента через JavaScript, которую Google не отрендерил при сканировании;

оставшиеся 15% приходятся на слишком медленную загрузку страницы или необходимость входа в систему, из-за чего робот просто не дошел до разметки.

Инструмент тестирования по умолчанию может использовать кэшированные старые данные, из-за чего 48% новых проблем не обнаруживаются. Даже при проверке «в режиме реального времени» охватывается только 35% контента, созданного через JS, и многие динамические разметки остаются непроверенными.

Если на сайте не включен HTTPS, 18% структурированной разметки будут просто проигнорированы. Если страница загружается дольше 5 секунд, 22% роботов Google досрочно прекратят сканирование и, естественно, не увидят вашу разметку.

Проверка синтаксиса и свойств структурированных данных

Проверка структурированных данных должна быть сосредоточена на точности синтаксиса JSON-LD (ошибки в скобках/кавычках/запятых составляют 42%-31% проблем с синтаксисом), полноте обязательных свойств (отсутствие offers в Product — 38%, отсутствие datePublished в Article — 29%) и правильности вложенности типов (например, отсутствие вложенности NutritionInformation в Recipe увеличивает частоту ошибок парсинга на 57%).

Ошибки синтаксиса JSON-LD

Несоответствие скобок и кавычек (42% ошибок синтаксиса):

Пример ошибочного кода:

{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “Беспроводные наушники”,
“image”: “https://example.com/headphones.jpg”,
} // Отсутствует закрывающая фигурная скобка “}”

Способ исправления: используйте функцию «сопоставления скобок» в редакторе кода (например, плагин Bracket Pair Colorizer в VS Code), чтобы построчно проверить симметричность {}, [], "".

Лишние запятые (31% ошибок синтаксиса):

Пример ошибочного кода:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Здесь лишняя запятая в конце
“priceCurrency”: “USD”
},

Способ исправления: стандарт JSON не допускает запятую после последнего свойства объекта или массива. Её необходимо удалить вручную или через онлайн-инструменты форматирования (например, JSONLint).

Ошибки типов данных (27% ошибок синтаксиса):

Например, формат даты не соответствует стандарту ISO 8601 (должно быть "2023-10-05T08:00:00+08:00" вместо "2023/10/05"), или цена указана не в виде строки ("price": 99.99 следует заменить на "price": "99.99").

Schema.org четко требует, чтобы числовые свойства соответствовали формату соответствующего типа, иначе они будут признаны «недопустимыми значениями».

Полнота обязательных свойств

Разные типы Schema имеют четкие требования к «обязательным свойствам». Отсутствие любого из них приведет к невозможности создания расширенного результата.

Согласно «Руководству по расширенным результатам» Google (2024), ниже приведены обязательные свойства для часто используемых разметок и последствия их отсутствия:

Тип разметки	Обязательные свойства	Частота отсутствия	Пример последствия
Product	name, image, offers	38%	Не отображаются цена и ссылка на покупку
Article	headline, datePublished, author	29%	Не активируется «избранный сниппет»
LocalBusiness	name, address, telephone	35%	Карточка на карте не привязана к местоположению
Recipe	name, description, recipeIngredient	41%	Не отображаются список ингредиентов и этапы

Пример: Один кулинарный сайт потерял показы расширенных результатов (снижение с 12% до 5%) из-за отсутствия свойства recipeIngredient (обязательное свойство) в разметке Recipe.

После добавления списка ингредиентов (например, "recipeIngredient": ["Мука 200г", "2 яйца"]), в течение 3 дней показатель показов восстановился до 10%.

Нормы вложенности типов

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

Данные Schema.org за 2023 год показывают, что ошибки вложенности составляют 49% неудач валидации свойств. Типичные сценарии включают:

Пищевая ценность рецепта (Recipe): должна быть вложена в тип NutritionInformation, а не указываться напрямую как свойство Recipe:

// ОШИБКА (без вложенности)
“calories”: “350 kcal”

// ПРАВИЛЬНО (с вложенностью в NutritionInformation)
“nutrition”: {
“@type”: “NutritionInformation”,
“calories”: “350 kcal”,
“fatContent”: “12g”
}

Информация о месте проведения мероприятия (Event): необходимо вложить тип Place, содержащий адрес, географические координаты и другие подпункты:

“location”: {
“@type”: “Place”,
“name”: “Конференц-центр”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “San Francisco”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7749”,
“longitude”: “-122.4194”
}
}

Метод проверки: Используйте вкладку «Nested Entities» валидатора Schema.org, чтобы проверить соответствие уровней вложенности стандартам (например, NutritionInformation должен быть прямым дочерним типом Recipe).

Двойная проверка Google и Schema.org

Инструмент тестирования структурированных данных Google: ориентирован на «совместимость с расширенными результатами», сообщает, если «эта разметка не может создать расширенный результат», и указывает конкретную причину (например, «отсутствует поле offers»). Валидатор Schema.org: ориентирован на «семантическую корректность», проверяет соответствие значений свойств определениям Schema (например, является ли priceCurrency кодом валюты ISO 4217).

Ограничения инструментов тестирования

Инструменты тестирования Google подвержены влиянию механизмов кэширования (48% остаточных старых данных) и ограниченного охвата тестирования в реальном времени (35%-50% динамического контента). Данные показывают, что полагаясь только на инструменты тестирования, можно упустить 22% реальных проблем.

Механизм кэширования

Инструмент тестирования структурированных данных Google по умолчанию кэширует разметку страницы, и 48% результатов тестов показывают данные 48-часовой давности (Справочный центр Search Console, 2023).

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

Пример: После обновления разметки Course с информацией о курсах на одном образовательном сайте инструмент по-прежнему выдавал «отсутствует поле description». После очистки кэша результаты пришли в норму.

Как с этим бороться:

• Перед каждым тестом вручную нажимайте «Очистить кэш» (иконка корзины) в правом верхнем углу инструмента, чтобы избежать влияния исторических данных.
• Для часто обновляемых страниц (например, карточек товаров) рекомендуется добавлять временную метку к URL при тестировании (например, ?v=20240315), чтобы заставить инструмент загрузить последнюю версию.

Тестирование в реальном времени

Функция тестирования в реальном времени (вкладка «Проверить страницу на сайте») имитирует сканирование Googlebot и выполнение JavaScript, но её возможности ограничены: она захватывает лишь 35%-50% динамически генерируемой разметки (Блог инженеров Google, 2024).

Причины недополучения данных включают:

• Задержка выполнения JS: Разметка создается асинхронными запросами (например, fetch), и инструменту не хватает времени ожидания (тайм-аут по умолчанию 3 секунды).
• Совместимость фреймворков: Процесс гидратации в SPA-фреймворках (React/Vue) может быть имитирован не полностью, из-за чего разметка не впрыскивается в DOM.

На одном новостном сайте разметка Article создавалась через React. Тест в реальном времени показывал «нет расширенных результатов», хотя при фактическом рендеринге страницы разметка присутствовала — выполнение JS занимало 4,2 секунды, что превышало лимит инструмента.

Как с этим бороться:

• Проверьте время выполнения JS на странице (через Lighthouse или вкладку Performance в Chrome DevTools), чтобы убедиться, что разметка загружается в течение 3 секунд.
• Для SPA-сайтов используйте технологии предварительного рендеринга (например, window.__INITIAL_STATE__) или вручную инициируйте выполнение JS в инструментах тестирования (например, нажатием на интерактивные кнопки).

Отчет об охвате

Отчет об «охвате» (в нижней части страницы результатов) показывает понимание страницы поисковиком Google, но предоставляет лишь поверхностные выводы (например, «соответствующая разметка не найдена»), не объясняя детально суть ошибки.

Типичные расплывчатые уведомления и их значения:

Пример: Сайт с рецептами при тестировании получал уведомление «Часть разметки проигнорирована». Валидатор Schema обнаружил, что поле nutrition типа Recipe не было правильно вложено в тип NutritionInformation. После исправления отчет об охвате обновился до «Вся разметка действительна».

Дополнительные сторонние инструменты

Если полагаться только на инструменты тестирования Google, можно упустить 22% реальных проблем (HTTP Archive, 2023), поэтому необходима перекрестная проверка с помощью других сервисов:

• Валидатор Schema.org: проверяет семантическую корректность (например, соответствует ли priceCurrency кодам ISO 4217). Один трансграничный интернет-магазин ошибочно использовал «US» вместо «USD» в priceCurrency; инструмент Google не выдал ошибки, но валидатор Schema обнаружил проблему. После исправления частота появления расширенных результатов выросла на 19%.
• Тестирование командой curl: имитация сканирования Googlebot с помощью curl -H "User-Agent: Googlebot" URL для проверки правильности вывода разметки в исходном HTML (особенно актуально для страниц с серверным рендерингом).

Доступность страницы и сканирование

Доступность страницы — это «фундамент» для создания расширенных результатов: если Googlebot не может просканировать или получить доступ к странице, разметка не будет распознана.

В «Руководстве по качеству поиска» Google за 2023 год указано, что 60% неудач при предварительном просмотре расширенных результатов напрямую связаны с проблемами доступности страницы.

Публичная доступность

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

Согласно статистике, 15% неудач при предварительном просмотре вызваны тем, что страница открыта только для определенных пользователей (Справочный центр Search Console, 2024).

Примеры:

• Один гастрономический сайт с системой членства установил для страниц с деталями Recipe статус «просмотр после регистрации», из-за чего Googlebot не смог просканировать обязательные поля, такие как recipeIngredient. Инструмент тестирования всегда показывал «нет результатов». После снятия ограничений на вход за 3 дня охват расширенных результатов восстановился с 0 до 8%.
• Один международный косметический бренд скрыл информацию о ценах для пользователей из Юго-Восточной Азии, из-за чего поле offers (включая цену) в разметке Product не могло быть просканировано. После исправления количество кликов по расширенным результатам в этом регионе выросло на 25%.

Методы проверки:

• Используйте режим инкогнито в Chrome (отключив Cookies и статус входа) для доступа к странице, чтобы убедиться, что контент полностью виден;
• Используйте AccessiBe для имитации IP-адресов разных регионов и проверки наличия региональных ограничений (например, «видимо только для пользователей из США»).

Скорость загрузки страницы

Отчет HTTP Archive за 2023 год показывает, что на страницах со временем загрузки более 5 секунд 22% поисковых роботов прекращают сканирование досрочно.

Конкретные последствия:

• Если разметка Product находится в нижней части страницы товара, тайм-аут загрузки приведет к тому, что Googlebot пропустит эту часть контента;
• Асинхронно загружаемая разметка Article (например, информация об авторе, генерируемая через AJAX) также будет проигнорирована, если процесс займет слишком много времени.

Проверка:

• Используйте PageSpeed Insights для тестирования показателя LCP (Отрисовка самого крупного контента) на мобильных и десктопных устройствах — он должен быть в пределах 2.5 секунд (требование Google к производительности);
• Действия по оптимизации:
  • Сжатие изображений: замена форматов JPG/PNG на WebP может уменьшить размер файлов на 50% (например, JPG размером 1 МБ после конвертации в WebP весит всего 400 КБ);
  • Ленивая загрузка некритичных ресурсов: настройте рекламу в футере, комментарии в сайдбаре и другие элементы на «загрузку при прокрутке в зону видимости»;
  • Включение сжатия Gzip: уменьшение объема файлов HTML/CSS через конфигурацию сервера (например, gzip on; в Nginx).

Кейс: Время начальной загрузки страницы интернет-магазина электроники составляло 6.2 секунды, LCP — 3.8 секунды. После оптимизации время загрузки сократилось до 3.5 секунд, LCP < 2 секунд, вероятность успешного сканирования Googlebot выросла с 75% до 92%, а показы расширенных результатов Product увеличились на 19%.

HTTPS-шифрование

Все URL-адреса, связанные со структурированными данными (изображения, ссылки на страницы деталей, offers.url), должны использовать протокол HTTPS.

Google четко требует использования HTTPS, так как ресурсы без HTTPS могут быть признаны «небезопасными», что приводит к 18% неудач предварительного просмотра (Документация для разработчиков Google, 2023).

Распространенные ошибки:

• Использование ссылок на изображения по HTTP (например, http://example.com/headphones.jpg), что делает недействительным поле image в Product;
• Свойство url в Article указывает на HTTP-версию (например, http://blog.example.com/post-123), что игнорируется Google.

Проверка:

• Вручную проверьте все URL-адреса в разметке, чтобы убедиться, что они начинаются с «https://»;
• Протестируйте SSL-сертификат сайта с помощью SSL Labs — убедитесь в отсутствии истекших сроков и ошибок конфигурации (например, включен ли TLS 1.2 и выше).

Исправление: После того как один модный сайт исправил все HTTP-ссылки на изображения, охват расширенных результатов Product вырос с 12% до 30%, а ошибки «недопустимый ресурс разметки» в Search Console полностью исчезли.

Исправление распространенных типов ошибок

Исправление ошибок должно быть направлено на четыре основные категории проблем:

• Синтаксические ошибки JSON-LD (38%)
• Отсутствие обязательных свойств (29%)
• Нарушение стандартов вложенности (22%)
• Незахваченный динамический контент (11%)

Данные показывают, что после поэтапного исправления вероятность успеха предварительного просмотра расширенных результатов может вырасти с 45% до 82% (кейс Google 2024).

Синтаксические ошибки JSON-LD

Ошибки синтаксиса JSON-LD составляют 38% проблем со структурированными данными. В основном это несоответствие скобок (42%), лишние запятые (31%) и ошибки в типах данных (27%). После исправления точность распознавания разметки может превысить 95% (данные Google 2024).

Согласно «Отчету об ошибках структурированных данных» Google за 2024 год, 38% неудач предварительного просмотра расширенных результатов вызвано синтаксическими ошибками JSON-LD.

Несоответствие скобок и кавычек

Несогласованность фигурных скобок ({}) и кавычек ("") — самая частая синтаксическая проблема, составляющая 42% всех ошибок JSON-LD (данные валидации Schema.org 2023).

Эти ошибки обычно возникают из-за невнимательности при кодировании, например, пропуска закрывающего символа или непарных кавычек.

Конкретный пример: Разметка Course на одной платформе онлайн-образования содержала ошибку в виде пропущенной закрывающей фигурной скобки, из-за чего инструмент тестирования Google выдавал «Invalid JSON»:

{
“@context”: “https://schema.org”,
“@type”: “Course”,
“name”: “Основы цифрового маркетинга”,
“description”: “Изучение техник SEO и SEM” // Пропущена финальная скобка “}”

Методы исправления:

• Используйте функцию «сопоставления символов» в редакторе кода (например, плагин Bracket Pair Colorizer для VS Code) — разноцветные скобки наглядно покажут незакрытые позиции;
• Используйте онлайн-инструменты (например, JSONLint) — вставьте код JSON, и инструмент укажет место ошибки (например, «Expected ‘}’, got ‘EOF’»).

Результат исправления: После корректировки разметка Course была успешно распознана, частота появления расширенных результатов восстановилась с 0 до 7%, а уведомление «недопустимые структурированные данные» в Search Console исчезло.

Лишние запятые

Лишние запятые ставятся после последнего свойства в объекте ({}) или массиве ([]), что составляет 31% синтаксических ошибок (Документация для разработчиков Google, 2024).

Типичный сценарий: В разметке Offer одного интернет-магазина после поля price стояла лишняя запятая:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Лишняя запятая в конце
“priceCurrency”: “USD”
}

Когда парсер встречает эту запятую, он ожидает следующее свойство, но его нет, поэтому весь объект offers признается недействительным.

Методы исправления:

• Используйте такие инструменты, как JSONLint, для автоматического форматирования кода — они удалят лишние запятые;
• Ручная проверка: после последнего свойства в объекте или массиве категорически нельзя ставить запятую (строгое требование стандарта JSON).

У одного ритейлера одежды из-за лишних запятых 30% разметки товаров были недействительны. После исправления доля валидной разметки выросла до 95%, а показы расширенных результатов Product увеличились на 22%.

Ошибки типов данных

JSON-LD требует, чтобы значения свойств строго соответствовали типам данных, определенным Schema.org. Такие ошибки составляют 27% от всех синтаксических ошибок (Schema.org, 2023).

Распространенные ошибки включают:

• Неверный формат даты: не используется стандарт ISO 8601 (должно быть "2023-10-05T08:00:00+08:00" вместо "2023/10/05" или "October 5, 2023");
• Неверный тип числовых данных: использование чисел вместо строк для таких свойств, как цена или рейтинг (например, "price": 99.99 следует заменить на "price": "99.99", а "ratingValue": 4.5 необходимо указывать в формате строки).

Пример: В разметке Article одного кулинарного блога дата datePublished была указана верно ("2023-10-05"), однако значение reviewRating.ratingValue было ошибочно записано как число 4.5 вместо строки "4.5".

Инструмент тестирования Google выдал предупреждение «Недопустимое значение рейтинга», из-за чего расширенный сниппет не был сформирован.

После исправления значения рейтинга на строку показатель показов расширенных сниппетов вырос с 10% до 28%.

Основание для проверки: Schema.org четко определяет, что ratingValue должен иметь тип «Text» (строка). Даже если содержимое является числом, оно должно быть заключено в кавычки — это деталь, которую многие разработчики часто упускают из виду.

Отсутствие обязательных свойств

Отсутствие обязательных свойств составляет 29% ошибок структурированных данных. Частота отсутствия варьируется в зависимости от типа разметки (отсутствие offers в Product — 38%, отсутствие datePublished в Article — 29%). После исправления и дополнения полей согласно спецификациям Schema более 80% расширенных результатов восстанавливают свои показы (кейс Google 2024).

Product

Product — самая популярная разметка в электронной коммерции. Ее обязательными свойствами являются name, image и offers (согласно определению Schema.org).

При этом offers (предложение товара) является ключевым элементом — оно должно содержать такие дочерние свойства, как price (цена), priceCurrency (валюта), availability (наличие) и т.д. Частота их отсутствия достигает 38% (данные Google Search Console 2023).

Последствия отсутствия: В разметке Product одного магазина одежды долгое время отсутствовал блок offers, что привело к:

• Инструмент тестирования показывал «Расширенные результаты отсутствуют»;
• В результатах поиска отображались только заголовок и описание, без цены и кнопки покупки;
• CTR (кликабельность) был на 40% ниже, чем у конкурентов, которые использовали полные карточки товаров.

Действие по исправлению: Добавление поля offers с указанием цены и наличия:

“offers”: {
“@type”: “Offer”,
“price”: “89.99”,
“priceCurrency”: “USD”,
“availability”: “https://schema.org/InStock”
}
В течение 3 дней охват расширенных результатов восстановился с 0 до 15%, кликабельность в поиске выросла на 22%, а объем конверсий увеличился на 18%.

Article

Обязательными свойствами для Article (статья/блог) являются headline (заголовок), datePublished (дата публикации) и author (автор).

При этом datePublished является ключевым фактором для Google при определении «свежести» контента — частота отсутствия этого поля составляет 29% (отчет Google об экосистеме контента 2024).

Последствия отсутствия: В разметке Article одного технологического блога не была указана дата datePublished, что привело к:

• Невозможности попадания в «избранные сниппеты» (Featured Snippets);
• Рейтинг статьи в поиске уступал конкурентам, опубликовавшим материалы в то же время (у конкурентов отображалась дата публикации);
• Снижению доверия пользователей — контент без даты воспринимается как «устаревший».

Действие по исправлению: Добавление даты публикации в формате ISO 8601:

“datePublished”: “2024-03-15T10:00:00+08:00”
Показатель показов в избранных сниппетах вырос с 10% до 35%, кликабельность статей увеличилась на 25%, а вероятность попадания в топ-3 поисковой выдачи выросла на 19%.

LocalBusiness

Обязательными свойствами для LocalBusiness (местный бизнес) являются name, address и telephone. При этом address (подробный адрес) является ядром для привязки Google к карточкам на картах — частота его отсутствия составляет 35% (данные Google My Business 2023).

Последствия отсутствия: В разметке LocalBusiness одной кофейни не был указан полный адрес (был указан только город), что привело к:

• Отсутствию карточки на карте в результатах поиска;
• Невозможности для пользователей проложить маршрут к заведению;
• Местному трафику на 50% ниже, чем у соседних конкурентов.

Действие по исправлению: Добавление подробного адреса типа PostalAddress:

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “Seattle”,
“addressRegion”: “WA”,
“postalCode”: “98101”
}
Карточка на карте появилась в течение 24 часов, локальный поисковый трафик вырос на 40%, а конверсия в посещения увеличилась на 28%.

Recipe

Обязательными свойствами для Recipe (рецепт) являются name, description и recipeIngredient (список ингредиентов).

При этом recipeIngredient — это «основное содержимое» рецепта. Частота отсутствия этого поля составляет 41% (опрос пользователей AllRecipes 2024).

Последствия отсутствия: В разметке Recipe одного кулинарного сайта не были перечислены ингредиенты, что привело к:

• Отсутствию списка ингредиентов и шагов приготовления в поиске;
• Невозможности для пользователя понять, подходит ли ему этот рецепт;
• Снижению количества сохранений в закладки на 60% по сравнению с конкурентами.

Действие по исправлению: Добавление структурированного списка ингредиентов:

“recipeIngredient”: [
“Мука 200г”,
“Яйца 2 шт.”,
“Молоко 150мл”,
“Сахар 50г”
]
Показатель отображения списка ингредиентов и шагов вырос с 8% до 25%, количество сохранений увеличилось на 32%, а вероятность выбора рецепта Google как «популярного» выросла на 21%.

Нарушение стандартов вложенности типов

«Вложенность типов» в структурированных данных — это логика Schema.org: родительский тип передает семантическую связь через включение дочерних типов. Например, Recipe должен включать дочерний тип NutritionInformation через поле nutrition, чтобы Google понял, что информация о калориях относится именно к этому блюду.

Суть ошибок вложенности

Система типов Schema.org представляет собой «древовидную иерархию»: родительский тип определяет основные свойства, а дочерние типы расширяют конкретные детали.

Например:

• Recipe (родительский тип) — это содержимое рецепта, которое через поле nutrition должно быть связано с NutritionInformation (дочерний тип) для передачи деталей о калориях, содержании жиров и т.д.;
• Event (родительский тип) — это информация о мероприятии, которая через поле location должна быть связана с Place (дочерний тип) для передачи адреса, координат и другого местоположения.

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

Например, если в разметке Recipe написать просто "calories": "350 kcal" вместо вложения в NutritionInformation, инструмент тестирования Google сообщит, что «поле калорий не распознано», и пищевая ценность не будет отображена в расширенных результатах.

4 распространенные ошибки вложенности

(1) Recipe: Информация о пищевой ценности не вложена в NutritionInformation

Ошибочный сценарий: В разметке Recipe одного блога калории и жиры указаны напрямую в родительском типе:

{
“@type”: “Recipe”,
“name”: “Яичница с помидорами”,
“nutrition”: { // Ошибка: nutrition — это свойство, требующее вложения типа
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
Проблема: Google не распознает свойства внутри nutrition как «пищевую ценность», поэтому они не отображаются в поиске.

Действие по исправлению: Вложите информацию в дочерний тип NutritionInformation:

{
“@type”: “Recipe”,
“name”: “Яичница с помидорами”,
“nutrition”: {
“@type”: “NutritionInformation”, // Добавлен дочерний тип
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
Результат: В расширенных результатах рецептов этого блога показатель отображения пищевой ценности вырос с 8% до 25%, а количество сохранений пользователями увеличилось на 32% (данные AllRecipes 2024).

(2) Event: Информация о месте не вложена в Place и PostalAddress

Ошибочный сценарий: На сайте конференций в разметке Event адрес указан простой строкой без иерархической вложенности:

{
“@type”: “Event”,
“name”: “Саммит по цифровому маркетингу”,
“location”: “Конференц-центр Сан-Франциско” // Ошибка: требуется вложение Place и PostalAddress
}
Проблема: Google не может разобрать структурированную информацию об адресе и не отображает карточку с картой.

Действие по исправлению: Вложите дочерние типы Place (место) и PostalAddress (почтовый адрес):

{
“@type”: “Event”,
“name”: “Саммит по цифровому маркетингу”,
“location”: {
“@type”: “Place”,
“name”: “Конференц-центр Сан-Франциско”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Mission St”,
“addressLocality”: “San Francisco”,
“addressRegion”: “CA”,
“postalCode”: “94105”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7890”,
“longitude”: “-122.4030”
}
}
}
Результат: После исправления в результатах поиска стала отображаться карточка с картой, кликабельность мероприятия выросла на 40%, а количество регистраций увеличилось на 28% (данные Google Events 2023).

(3) Product: Отзывы не вложены в Review или AggregateRating

Ошибочный сценарий: На маркетплейсе в разметке Product оценка указана напрямую, без вложения в дочерний тип AggregateRating (агрегированный рейтинг):

{
“@type”: “Product”,
“name”: “Беспроводные наушники”,
“reviewScore”: “4.5” // Ошибка: оценка должна быть внутри AggregateRating
}
Проблема: Google не понимает, что «4.5» — это совокупный рейтинг товара, и не отображает «звездочки» в поиске.

Действие по исправлению: Вложите дочерний тип AggregateRating:

{
“@type”: “Product”,
“name”: “Беспроводные наушники”,
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.5”,
“reviewCount”: “120”
}
}
Результат: В расширенных результатах товара частота отображения звездного рейтинга выросла с 15% до 50%, а объем конверсий увеличился на 19% (данные Shopify 2024).

(4) Article: Информация об авторе не вложена в Person

Ошибочный сценарий: В технологическом блоге в разметке Article имя автора указано просто текстом без вложения типа Person (личность):

{
“@type”: “Article”,
“name”: “Тренды SEO 2024”,
“author”: “Иван Иванов” // Ошибка: автор требует вложения типа Person
}
Проблема: Google не может идентифицировать личность автора и не отображает метку «автор».

Действие по исправлению: Вложите дочерний тип Person:

{
“@type”: “Article”,
“name”: “Тренды SEO 2024”,
“author”: {
“@type”: “Person”,
“name”: “Иван Иванов”,
“url”: “https://example.com/author/ivanov”
}
}
Результат: Частота отображения метки автора статьи выросла с 20% до 60%, а уровень доверия пользователей повысился на 25% (данные Google Authorship 2023).

Динамический контент не захвачен

Динамический контент — это данные, генерируемые в реальном времени с помощью JavaScript (JS), AJAX или одностраничных приложений (SPA), например, сайты на React/Vue, бесконечные списки статей или шаги рецепта, загружающиеся по клику.

Разметка такого контента (например, цена Product или комментарии Article) не присутствует в исходном HTML-коде, а динамически вставляется клиентским JS.

Механизм сканирования Googlebot работает по принципу «сначала захват HTML, затем выполнение JS». Если JS выполняется слишком медленно или контент полностью зависит от клиентского рендеринга, расширенные результаты могут не создаться.

В блоге инженеров Google (2024) отмечается, что 40% динамических страниц не содержат разметки, доступной для робота, из-за отсутствия пререндеринга.

Почему динамический контент не сканируется

Процесс сканирования Googlebot состоит из двух этапов:

1. Загрузка исходного HTML: получение базовой структуры страницы (без контента, созданного JS);
2. Выполнение JS: имитация работы браузера для запуска JS и получения динамического контента (требует ожидания завершения выполнения скриптов).

Но «терпение» робота ограничено:

• Если выполнение JS занимает более 3 секунд, Googlebot может прекратить процесс досрочно, и динамическая разметка не будет считана (данные Lighthouse 2023);
• Если контент зависит от «взаимодействия с пользователем» (например, нажатие кнопки «Загрузить еще»), робот пропустит эту часть данных.

Пример: Новостной сайт использует React (SPA), и блок комментариев Article загружается динамически через JS.

Инструмент тестирования показывает «нет расширенных результатов» — на самом деле разметка комментариев существует, но при сканировании Googlebot выполнение JS не успело завершиться, и комментарии не попали в первичный анализ.

3 критические проблемы

(1) SPA (одностраничные приложения): исходный HTML пуст, разметка отсутствует

SPA — это принцип «одна страница, динамическая подмена контента». Исходный HTML обычно содержит только пустой блок <div id="root"></div>, а всё содержимое вставляется JS.

Без пререндеринга Googlebot получает пустой HTML без структурированных данных, и разметка не распознается. Данные: На туристическом сайте разметка Tour создавалась на React, исходный HTML был пуст.

Search Console выдавала «соответствующая разметка не найдена», охват расширенных результатов был 0. После внедрения серверного рендеринга (SSR) исходный HTML стал сразу содержать полную разметку Tour, и охват вырос с 0 до 28%.

(2) Загрузка AJAX: асинхронное получение контента, робот не дождался завершения

AJAX используется для подгрузки контента (например, бесконечные списки товаров или отзывы), но робот не будет бесконечно ждать завершения AJAX-запроса. Если загрузка превышает «порог ожидания» робота (около 3 секунд), разметка будет упущена.

Пример: На маркетплейсе блок «Вам также может понравиться» загружается через AJAX, и разметка Product генерируется динамически.

Инструмент тестирования сообщает: «Часть разметки проигнорирована» — при сканировании Googlebot запрос AJAX не успел завершиться, и информация о товарах не попала в индекс.

После использования инструментов пререндеринга (например, Prerender.io) для создания HTML с полным списком товаров узнаваемость разметки выросла с 60% до 95%.

(3) Ленивая загрузка (Lazy Load): контент появляется по триггеру, превышая время ожидания

Ленивая загрузка оптимизирует скорость, подгружая шаги HowTo или ингредиенты Recipe только при прокрутке. Но если задержка слишком велика (например, более 2 секунд), робот может пропустить этот контент.

Данные: На сайте о дизайне интерьеров разметка HowTo (например, «как собрать полку») загружалась с задержкой в 2 секунды.

Инструмент Google выдавал «невозможно распознать поля шагов» — робот не дождался окончания загрузки.

После сокращения задержки до менее 1 секунды показатель отображения шагов вырос с 18% до 43%.

Три метода исправления

(1) Пререндеринг: сервер создает полный HTML, робот сразу его захватывает

Пререндеринг подразумевает запуск JS на стороне сервера для генерации HTML с полным динамическим контентом перед отправкой его поисковому роботу.

Инструменты вроде Prerender.io или модули Nginx для пререндеринга автоматически распознают запросы от роботов и отдают им готовую версию страницы.

Эффект: После внедрения Prerender.io на одном SPA-маркетплейсе успех сканирования разметки Product вырос с 75% до 92%, а охват расширенных результатов — с 5% до 28%.

(2) Серверный рендеринг (SSR): рендеринг JS-контента силами фреймворка

SSR — это использование фреймворков типа Next.js (React) или Nuxt.js (Vue) для преобразования JS-компонентов в строку HTML на сервере перед отправкой клиенту.

В этом случае исходный HTML сразу содержит полную разметку, и роботу не нужно ждать выполнения JS.

Пример: Новостной сайт перешел на Next.js, и блок комментариев Article стал генерироваться через SSR.

При сканировании Googlebot сразу получил разметку Comment, показы избранных сниппетов выросли с 10% до 50%, а взаимодействие с комментариями увеличилось на 35%.

(3) Оптимизация времени выполнения JS: загрузка разметки в течение 3 секунд

Если невозможно использовать пререндеринг или SSR, необходимо оптимизировать время выполнения JS, гарантируя загрузку динамической разметки в пределах 3 секунд.

Используйте Lighthouse или вкладку Performance в Chrome DevTools для проверки времени загрузки разметки:

• Сжатие JS-файлов: используйте Webpack или Rollup для уменьшения объема кода;
• Отложенная загрузка некритичного JS: установите атрибуты async или defer для скриптов, не влияющих на разметку (реклама, статистика);
• Кэширование ресурсов: используйте CDN для ускорения загрузки JS-файлов.

Данные: Медиа-сайт оптимизировал время выполнения JS с 4.2 до 2.5 секунд, успех сканирования Googlebot вырос с 68% до 90%, а охват расширенных результатов Article увеличился на 22%.

И напоследок: одна корректная строка JSON, стандартная вложенность и своевременный пререндеринг могут превратить «отсутствующие» расширенные результаты в ваше преимущество в поиске.