Что делать, если Google Schema Testing Tool не обнаруживает данные?

На странице уже добавлен код JSON-LD, но при открытии google schema testing tool отображается сообщение «структурированные данные не обнаружены». Не спешите полностью переписывать всю разметку. Такой результат обычно не означает, что Schema точно недействительна; чаще причина в том, что содержимое страницы, полученное инструментом проверки, отличается от того, что видно в браузере, либо имеются проблемы с размещением разметки, синтаксисом кода или доступностью страницы.

На практике к ошибочным выводам чаще всего приводят следующие ситуации: разработчики видят корректный код в тестовой среде, но после публикации инструмент не может его получить; либо в панели управления сайта уже сохранены поля товара, хлебных крошек, статьи и другие данные, но на публичной странице структурированные данные фактически не выводятся. Сначала следует убедиться, «есть ли разметка в HTML, полученном инструментом», затем проверить, можно ли её разобрать, и только после этого оценивать, соответствуют ли типы и свойства требованиям.

Сначала определите: данные не обнаружены или обнаружены, но не соответствуют требованиям к расширенным результатам

«Данные не обнаружены» и «данные обнаружены, но имеются предупреждения» — это два разных типа проблем. В первом случае инструмент не смог извлечь из текущей страницы распознаваемые Microdata, RDFa или JSON-LD; во втором разметка уже присутствует, но в ней отсутствуют некоторые рекомендуемые поля, что не обязательно влияет на базовое распознавание.

Первоначальный Google Structured Data Testing Tool больше не поддерживается. При текущей диагностике можно использовать инструмент проверки расширенных результатов, чтобы узнать, соответствует ли страница условиям отображения расширенных результатов, поддерживаемых Google, или Schema Markup Validator для проверки синтаксиса и иерархии Schema.org. Не делайте вывод, что все структурированные данные страницы недействительны, только потому, что один инструмент не показывает результат; разные инструменты по-разному поддерживают типы данных, JavaScript-рендеринг и правила проверки.

Шаг 1: убедитесь, что отправляете окончательную доступную страницу

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

• Проверьте, перенаправляется ли URL автоматически с http на https или с версии без www на версию с www; тестировать следует конечный адрес назначения.
• Убедитесь, что страница не является черновиком, ссылкой для предпросмотра, страницей редактирования в панели управления или тестовым адресом, видимым только во внутренней сети.
• Проверьте, не происходит ли несколько перенаправлений. Если цепочка перенаправлений слишком длинная либо ведёт на страницу выбора языка или страницу ошибки, инструмент проверяет не целевую страницу с содержимым.
• Проверьте, не возвращает ли сервер для поисковых роботов другое содержимое, например из-за защиты безопасности, ограничения частоты запросов, ответов 403, 503 или пустой страницы.

Некоторые сайты возвращают разные версии в зависимости от языка посетителя, IP или User-Agent. Нормальное отображение в браузере не означает, что инструмент сканирования получает корректный HTML. В этом случае следует проверить в серверных журналах, правилах защиты CDN или результатах сканирования страницы, не был ли запрос заблокирован.

Шаг 2: найдите структурированные данные в исходном коде страницы

Не ищите их только через функцию «Проверить элемент» в браузере. Инструменты разработчика показывают DOM после выполнения JavaScript на странице, тогда как инструмент проверки может не выполнять скрипты таким же образом. Следует использовать «Просмотр исходного кода страницы» и искать application/ld+json, schema.org, itemtype или itemscope.

Для JSON-LD обычно содержимое размещается внутри тега <script type="application/ld+json">. Если этого фрагмента нет в исходном коде и он появляется только в динамическом DOM, проблема, скорее всего, связана с асинхронной вставкой на фронтенде. В частности, в одностраничных приложениях, на страницах фильтрации и во всплывающих окнах с подробностями товара структурированные данные могут создаваться только после ответа API. Разное время сканирования в таком случае приводит к тому, что google schema testing tool не обнаруживает их.

Более надёжный подход — выводить JSON-LD ключевых страниц вместе с исходным HTML либо использовать надёжный серверный рендеринг или предварительный рендеринг. Основная информация на страницах товаров, статей и категорий должна быть доступна уже в первоначальном ответе, а не полностью загружаться только после действий пользователя.

Шаг 3: проверьте синтаксис JSON-LD, а не только содержимое полей

При копировании кода легко добавить полноширинные кавычки, завершающие запятые, неэкранированные двойные кавычки или незакрытые скобки. Если JSON не разбирается, инструмент обычно полностью игнорирует весь блок данных. Код, внешне похожий на Schema, не означает, что это корректный JSON.

Также проверьте, что @context имеет значение https://schema.org, а @type написан правильно. Значения свойств должны соответствовать видимому содержимому страницы. Например, цены товара, наличие на складе, рейтинги, даты публикации и другие данные не должны длительное время сохраняться в разметке, если они устарели или отсутствуют на странице. Возможность разбора инструментом не означает, что поисковая система будет использовать эту информацию для отображения.

Проблемы, вызванные шаблонами, плагинами и кэшем, более скрыты

При использовании системы создания сайтов или CMS структурированные данные могут не обнаруживаться даже после включения опции «Включить структурированные данные» в панели управления. Часто причина не в неверно выбранном типе Schema, а в том, что шаблон не вызывает соответствующий компонент. Например, шаблон статьи выводит заголовок и основной текст, но не содержит модуль Schema для статьи; данные товара заполнены в товарной системе, но текущая страница подробностей использует пользовательский шаблон, в который соответствующие поля не передаются.

Ещё одна частая проблема — кэширование. После обновления страницы настройки в панели управления уже изменены, но CDN, кэш страницы или объектный кэш всё ещё возвращают старую версию HTML. Порядок проверки должен быть следующим: сохраните настройки и опубликуйте страницу, очистите кэш сайта и CDN, просмотрите исходный код по окончательному публичному URL, затем повторно отправьте страницу на проверку. То, что новый код виден только на странице предпросмотра в панели управления, не доказывает обновление онлайн-страницы.

Не выводите на одной странице повторяющиеся противоречивые данные

На некоторых сайтах одновременно активированы SEO-разметка темы, разметка плагина интернет-магазина и сторонний SEO-плагин. В результате на одной странице товара появляются два Product и два Offer, причём цены или остатки на складе могут различаться. Такие страницы не обязательно показывают сообщение «данные не обнаружены», но усложняют последующую диагностику и могут снизить достоверность разметки.

Рекомендуется сохранять основную сущность в соответствии с назначением страницы: для страницы подробностей статьи основной сущностью должны быть Article или BlogPosting, для страницы подробностей товара — Product, а в области навигации можно дополнительно использовать BreadcrumbList. Сначала удалите или отключите дублирующие источники, затем повторите тест. Для общесайтовых сущностей, таких как Organization и WebSite, также необходимо поддерживать единообразие названия, URL, Logo и других данных, не позволяя разным плагинам создавать разные версии.

Порядок проверки после исправления

1. Откройте исходный код публичной страницы и убедитесь, что структурированные данные действительно выведены.
2. Проверьте фрагмент кода JSON-LD отдельно, чтобы исключить ошибки в запятых, кавычках, скобках и кодировке.
3. С помощью инструмента валидации Schema убедитесь, что типы сущностей, иерархия свойств и отношения ссылок могут быть разобраны.
4. Затем используйте инструмент проверки расширенных результатов, чтобы проверить конкретные типы отображения, поддерживаемые Google, и отсутствующие поля.
5. После очистки кэша повторно проверьте URL; если страница уже проиндексирована, можно запросить повторное сканирование в Search Console.

Наконец, важно сохранить границу в оценке: успешная проверка структурированных данных означает лишь, что машина способна понять часть информации страницы, но не гарантирует получение расширенного результата; наоборот, если определённый тип Schema не отображается в инструменте проверки расширенных результатов, это не обязательно означает, что разметка бесполезна. При проблеме «данные не обнаружены» в первую очередь следует проверить доступность страницы, вывод исходного HTML, синтаксис JSON и версию кэша — обычно это эффективнее, чем многократно добавлять поля.