Сайт открывается, но Google не видит товары: проверяем JavaScript и рендеринг

Если магазин открывается в браузере, а Google не видит товары, сравните три версии страницы: исходный HTML, результат выполнения JavaScript и HTML из проверки Google. Разница между ними покажет, на каком этапе исчезают названия, цены или ссылки. Сам факт использования JavaScript не объясняет проблему и не означает, что весь сайт нужно переписывать.

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

Как Google получает содержимое JavaScript-сайта

Google описывает обработку таких страниц через получение ответа, выполнение JavaScript и дальнейшее индексирование содержимого. Эти действия нужно различать: успешный запрос сервера ещё не показывает, что все данные появились после отрисовки. Основной порядок изложен в руководстве по JavaScript SEO.

На проекте составьте карту зависимостей страницы. Откуда приходят товары: из первоначального HTML, API магазина или стороннего поиска? Нужен ли регион, сохранённый в cookies? Требуется ли авторизация? Необходимо ли нажать «Показать ещё»? Эти вопросы помогают найти конкретный сценарий вместо общего диагноза «поисковик не любит наш фреймворк».

Проверьте одинаковый URL в новом окне браузера. Сотрудник магазина может не замечать проблему, потому что его сессия уже содержит город, согласие и нужный токен. Для нового посетителя та же страница иногда оказывается пустым каркасом. Зафиксируйте различия до обсуждения способа рендеринга.

Первый тест: что находится в исходном HTML

Откройте исходный код страницы и найдите точное название товара, его артикул и ссылку на карточку. Не ограничивайтесь вкладкой Elements: она показывает уже изменённое браузером дерево документа. Сохраните исходный ответ отдельным файлом, чтобы после исправления сравнить содержимое тем же способом.

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

Посмотрите, нет ли начального noindex, который скрипт собирается удалить. Не используйте такую схему для страницы, предназначенной для поиска. Директивы, канонический адрес и содержимое должны быть согласованы, а не переключаться между взаимоисключающими состояниями по мере запуска приложения.

Второй тест: что загрузилось после JavaScript

В инструментах разработчика откройте Network и перезагрузите страницу без сохранённого кеша. Найдите запрос, который получает список товаров. Проверьте статус, ответ и условия отправки. Ошибка API, истёкшая подпись или защита от частых обращений могут оставить страницу без данных, хотя основной HTML отвечает 200.

Затем посмотрите ошибки Console. Отдельная ошибка счётчика и исключение, остановившее отрисовку каталога, имеют разный приоритет. Для разработчика сохраните URL, последовательность действий и сообщение ошибки. Если проблема появляется только на части устройств, добавьте версию браузера и размер экрана.

Проверьте медленное соединение и повторное открытие прямой ссылки на товар. Иногда навигация внутри приложения работает, а прямой вход по тому же URL приводит к пустому экрану. Для поиска важен самостоятельный доступ к каждой странице, а не только успешный переход после загрузки главной.

Третий тест: что получает Google

В Search Console используйте проверку URL и просмотр доступного результата тестирования. Сравните полученный HTML с ожидаемым названием, ценой, ссылками и метаданными. Скриншот помогает заметить пустой экран, но не заменяет проверку текста и ссылок. Руководство Google по поисковым проблемам JavaScript описывает этот диагностический подход.

Разделяйте проверку опубликованной версии сейчас и сведения о последнем индексировании. После выпуска изменения новый тест может показывать исправленную страницу, пока данные индекса относятся к прежнему обходу. Запишите обе даты. Иначе команда рискует несколько раз исправлять уже устранённую ошибку, сравнивая разные версии сайта.

Если локальная проверка проходит, а внешний тест нет, изучите ограничения CDN и сетевые обращения. Не отключайте защиту на всём сайте. Разработчику нужен конкретный заблокированный ресурс, время запроса и правило, которое сработало. Обращения поисковых роботов можно дополнительно разобрать через серверные логи.

Ссылки на товары и кнопка «Показать ещё»

Переходы по каталогу должны существовать как доступные ссылки. Google рекомендует элементы a с href, а не только обработчики нажатий. Сравните свой шаблон с требованиями к ссылкам для обхода. Кнопка может улучшать интерфейс, но не должна быть единственным способом обнаружить следующие товары.

<a href="/catalog/luma-42/">Настольная лампа Luma 42</a>
<a href="/catalog/lamps/?page=2">Следующая страница</a>

Проверьте товары за пределами первого экрана и первой порции загрузки. Выгрузите адреса из каталога и сравните их с обходом по ссылкам. Расхождение покажет, где карточки есть в базе, но недоступны из навигации. Подробный разбор такого сценария есть в статье о пагинации и «Показать ещё».

Когда выбирать SSR, CSR или смешанную схему

При SSR сервер формирует HTML до отправки браузеру. При CSR значимая часть содержимого появляется после выполнения клиентского JavaScript. На практике можно отдавать основные сведения о товаре с сервера, а интерактивные элементы обновлять в браузере. Решение выбирают по тому, какие данные должны быть доступны сразу и как часто они меняются.

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

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

Как принять исправление

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

Добавьте эти сценарии в проверку релизов. Например, автоматический тест может искать название и ссылку в серверном ответе там, где проект выбрал SSR. Проверка в браузере дополнительно подтвердит работу фильтра и корзины. Это разные уровни контроля; один не заменяет другой.

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

Термины по теме

• Рендеринг
• SSR и CSR
• Краулинговая ловушка

Документация

• Google: основы JavaScript SEO
• Google: исправление проблем JavaScript
• Google: ссылки для обхода