Редакция Romanov Lab · Опубликовано
Наличие JavaScript не делает сайт автоматически проблемным для SEO. Риск возникает, когда важные данные появляются только после удачного выполнения длинной цепочки запросов, выбора региона, нажатия кнопки или восстановления состояния браузера. Человек с уже сохранёнными настройками видит полноценную страницу, а новый посетитель или робот получает пустой каркас. Поэтому проверять нужно доставку конкретного содержания, а не название фреймворка.
Главные вопросы просты: что сервер отдаёт при прямом открытии адреса, что появляется после выполнения скриптов, какие действия для этого требуются и что происходит при отказе зависимостей. Ни один общий балл производительности не заменяет ответы на эти вопросы.
Различайте исходный ответ и DOM после отрисовки
Исходный HTML — документ, который сервер прислал в ответ на запрос. DOM в инструментах разработчика отражает текущее состояние страницы, уже изменённое скриптами. Текст может отсутствовать в первом и присутствовать во втором. Это не обязательно ошибка, но такая архитектура требует отдельного тестирования.
В руководстве Google по JavaScript SEO описаны получение, отрисовка и последующая обработка страниц. Поддержка JavaScript не означает, что любой пользовательский сценарий будет выполнен. Кнопки, прокрутка, авторизация и локальные настройки не должны становиться обязательным условием появления основного содержания публичной страницы.
Для разговора с разработчиком достаточно трёх терминов. Серверная отрисовка формирует содержимое на сервере при запросе. Статическая генерация готовит документы заранее. Клиентская отрисовка собирает страницу в браузере. Проект может сочетать эти подходы. Выбор оценивают по реальным данным, скорости обновления, стоимости поддержки и устойчивости, а не по обещанию «идеального SEO».
Выберите страницы и контрольные элементы
Проверять только главную недостаточно: она часто устроена иначе, чем каталог и карточки. Возьмите несколько шаблонов и сложных состояний: товар без наличия, длинную категорию, статью, страницу услуги, неизвестный адрес и URL с параметрами. Для каждого определите, что обязано быть доступно независимо от предыдущих действий.
- Основной заголовок и текст, объясняющий назначение страницы.
- Название товара, существенные характеристики, цена и наличие, если они публикуются.
- Ссылки на категории, карточки, соседние материалы и следующие страницы списка.
- Title, описание, canonical и правила индексирования.
- Осмысленное состояние ошибки для несуществующего материала.
Записывайте точные фрагменты, которые будете искать. «Контент присутствует» — слишком расплывчатый критерий. «В ответе или проверенной отрисованной версии присутствует название модели А и ссылка на её инструкцию» — уже воспроизводимый тест. Не включайте в критерий персональную скидку или закрытые сведения, которые не должны быть общедоступными.
Первый проход: прямое открытие
Откройте адрес в новом приватном окне без входа в аккаунт. Не переходите на него через внутреннюю навигацию: SPA может корректно менять экран после клика, но не обслуживать прямой запрос по тому же пути. Проверьте обновление страницы и отправку адреса другому браузеру.
Сохраните серверный статус и исходный HTML. Найдите контрольные фрагменты, метаданные и основные ссылки. Если ответ состоит из пустого контейнера и подключённых скриптов, отметьте зависимость от клиентской отрисовки. Это отправная точка расследования, а не автоматическое требование переписать весь сайт.
Затем временно отключите JavaScript и посмотрите, остаётся ли полезная информация. Этот тест не имитирует Googlebot буквально: он показывает, какие части страницы полностью зависят от скриптов. Разработчик должен понимать его назначение, иначе результат легко превратить в неверное утверждение «поисковик ничего не видит».
Второй проход: загрузка данных и ресурсов
Включите JavaScript и откройте вкладки Network и Console. Найдите запросы, от которых зависят контрольные элементы. Проверьте ошибки доступа, тайм-ауты, неуспешные ответы, блокировки ресурсов и ссылки на старые версии файлов. Отдельно посмотрите, не требует ли API cookie, который появляется только после ручного согласия или выбора города.
Повторите загрузку без кэша и при замедленной сети. Если заголовок появляется быстро, а описание иногда остаётся пустым, сравните порядок событий. Бывает, что код скрывает состояние загрузки раньше завершения запроса или перезаписывает полученные данные устаревшим ответом. Такие дефекты влияют и на обычных посетителей.
Не исправляйте ошибки снятием всех ограничений безопасности. Сначала установите, какой ресурс действительно должен быть публичным и откуда он запрашивается. Для закрытых данных нужен корректный интерфейс доступа, а не публикация API ради сканера. Любое изменение прав согласуют с ответственным за систему.
Третий проход: независимая поисковая проверка
Используйте проверку URL в Search Console и изучите доступные сведения об отрисованной странице. Сравните их с контрольным набором, а не только со скриншотом. Визуально знакомый каркас может скрывать отсутствие ссылок, характеристик или нужных метаданных. Разделяйте проверку текущей доступной версии и сведения о ранее обработанной поиском странице.
Google отдельно описывает диагностику ошибок JavaScript. Среди важных проверок — доступность ресурсов и поведение страницы при индексирующих ограничениях. Например, рассчитывать на то, что скрипт снимет исходный noindex после загрузки, ненадёжно: поисковая обработка может не дойти до такого исправления.
Если результаты расходятся, сохраните время проверки, URL, исходный ответ, отрисованный текст и сведения об ошибках. Не ограничивайтесь фразой «у меня работает». Разница может быть связана с кэшем, регионом, экспериментом, версией релиза или разной доступностью внешнего сервиса.
Учебный пример: пустая категория оборудования
В вымышленном каталоге страница насосов получает название и товары только после выбора склада. Сотрудник проверяет её из своего браузера, где склад уже сохранён, и видит полноценный список. В новом окне отображается заголовок «Каталог» и предложение выбрать город. Это учебная ситуация, не описание выполненного проекта.
Команда выделяет общедоступную часть: название категории, её назначение, характеристики отбора и общий список моделей. Эти данные не зависят от склада и могут быть доступны сразу. Локальное наличие и сроки показываются отдельным слоем после выбора региона. Если регион неизвестен, интерфейс прямо сообщает, какие сведения ещё требуют уточнения.
Приёмка включает прямое открытие без cookies, смену города, отказ сервиса наличия и повторную загрузку ссылки. Категория должна оставаться понятной, а локальные сведения не должны выдавать выдуманный остаток. Такой подход одновременно снижает техническую зависимость и делает поведение честнее для посетителя.
Ссылки и адреса важнее красивого перехода
Основная навигация должна иметь настоящие адреса назначения. Элемент, который только обрабатывает событие клика и меняет состояние приложения, сложнее проверить и использовать вне привычного сценария. Для карточек, категорий и пагинации проверяйте обычные ссылки с корректными href, доступность адреса напрямую и согласованность истории браузера.
Убедитесь, что кнопка «Назад» возвращает ожидаемое состояние, а обновление не уводит на главную. Если категория имеет собственный URL, он должен открываться как категория на сервере, а не зависеть от того, какую страницу человек посетил ранее. Для бесконечной прокрутки спроектируйте проверяемый способ доступа к последующим частям списка.
Этот слой тесно связан с внутренней перелинковкой. Ссылка полезна, когда её назначение понятно, адрес устойчив и конечная страница работает сама по себе. Анимация перехода не должна скрывать нарушение этих базовых свойств.
Проверьте статусы, метаданные и гидратацию
Неизвестный URL не должен выглядеть для сервера как обычная успешная страница только потому, что интерфейс нарисовал сообщение об ошибке. Проверьте фактический HTTP-ответ. Также сравните canonical и заголовки до и после выполнения скриптов: конфликтующие значения усложняют диагностику и могут появляться из-за двух независимых генераторов метаданных.
Если используется серверная отрисовка с последующей гидратацией, убедитесь, что клиент не стирает уже полученный текст и не заменяет его пустым состоянием. Проверьте различия времени, локали и данных на сервере и в браузере. Пользователь не должен наблюдать скачок от доступной цены к пустому блоку без объяснения.
Как поставить задачу на исправление
Опишите сценарий, среду, ожидаемый результат и фактическое поведение. Приложите минимальный URL, контрольный текст и сетевой запрос, на котором ломается цепочка. Затем выберите уровень исправления: убрать ненужную зависимость от действий, обеспечить публичную доставку данных, исправить маршрутизацию или изменить способ отрисовки конкретного шаблона.
Не назначайте полную миграцию фреймворка, пока не проверены локальные причины. Иногда достаточно исправить серверный маршрут и кеширование, а иногда устойчивое решение действительно требует серверной генерации основного содержания. Решение должно учитывать стоимость и частоту проблем, а не только единичный скриншот.
Регрессия после каждого существенного релиза
Сохраните небольшой набор адресов и автоматизируйте проверку статусов, контрольных элементов, ссылок и метаданных. Дополняйте её ручными сценариями без cookies и при отказе API. После изменения фронтенда повторяйте поисковую проверку важных шаблонов и следите за новыми ошибками в отчётах.
Критерий завершения — не «сайт использует SSR», а воспроизводимая доставка нужного содержания по публичному адресу. Если команда умеет показать, что получает новый посетитель, откуда приходят данные и как система ведёт себя при сбое, JavaScript перестаёт быть загадочной SEO-проблемой и становится обычной проверяемой частью архитектуры.
Официальные источники
Нужен план для вашего проекта? Напишите нам в Telegram или по электронной почте. Обсудим разработку, продвижение или поддержку сайта.
