JavaScript SEO проверяет, может ли поисковая система получить, отрисовать и понять важное содержимое страницы. Начните со сравнения трёх состояний: исходного HTML от сервера, DOM после выполнения скриптов и страницы в инструменте поисковой системы. Если заголовок, текст, ссылки, canonical или структурированные данные появляются только после длинной цепочки запросов, результат становится менее предсказуемым. Убирать JavaScript не нужно. Нужно сделать так, чтобы критичная информация загружалась стабильно и не зависела от клика, авторизации или случайно успешного ответа API.
Проверка особенно важна для интернет-магазинов, каталогов, SPA и сайтов после смены фронтенда. Порядок работы: выбрать контрольные URL, сравнить состояния страницы, найти сбой, исправить его и повторить тест.
Что проверяют в JavaScript SEO
У страницы есть как минимум три состояния. Первое — ответ сервера: HTTP-статус, заголовки и HTML без выполнения клиентского кода. Второе — DOM, который браузер собрал после запуска JavaScript. Третье — версия, обработанная поисковой системой. Она зависит от того, удалось ли скачать ресурсы, выполнить код и получить данные.
Сервер может вернуть пустой контейнер, а карточки, текст и навигацию добавить после запроса к API. В браузере всё выглядит исправно, но при ошибке скрипта, медленном ответе или закрытом ресурсе часть страницы пропадает. Поэтому внешний вид ещё не доказывает, что страница пригодна для поиска.
Проверять нужно элементы, которые объясняют назначение URL:
- уникальные title, description и H1;
- основной текст, характеристики, цена или условия услуги;
- ссылки на категории, карточки, статьи и следующие уровни сайта;
- canonical, robots и языковые указания, если они используются;
- изображения с рабочими адресами и понятными alt;
- структурированные данные, совпадающие с видимым содержимым;
- корректный ответ для удалённого или несуществующего URL.
Как понять, что проблема именно в рендеринге
Страница может выпасть из поиска не из-за JavaScript. Возможны запрет индексации, ошибочный canonical, дубли, слабое содержание, отсутствие внутренних ссылок или нестабильный сервер. Сначала пройдите базовую проверку технического SEO, затем отдельно исследуйте фронтенд.
На рендеринг указывают такие признаки:
- в исходном HTML нет H1, основного текста и ссылок, хотя в браузере они видны;
- важный блок появляется только после прокрутки, клика или другого действия;
- при задержке API остаётся пустой экран или бесконечная загрузка;
- после релиза поисковый инструмент видит старый шаблон или неполный DOM;
- JS, CSS либо запросы к API возвращают 403, 404 или 5xx;
- навигация работает через обработчики событий, но не содержит ссылок с href;
- существующий и ошибочный маршруты получают одинаковую оболочку с кодом 200;
- общие метатеги меняются на уникальные только поздним клиентским кодом.
Какие URL взять для теста
Не ограничивайтесь главной: она часто устроена иначе, чем глубокие разделы. Возьмите по одному представителю каждого шаблона: главную, категорию, карточку товара или услуги, статью, пагинацию, фильтр, недавно созданную страницу и заведомо несуществующий адрес.
Для каждого URL запишите ожидаемые статус, canonical, индексируемость, H1, основной блок и ключевые ссылки. Тогда тест даст понятный результат. На большом сайте сравнение можно автоматизировать, но сначала разберите вручную каждый тип страницы.
Как проверить рендеринг: семь шагов
1. Посмотрите ответ сервера
Получите статус, заголовки и исходный HTML без JavaScript. Рабочий URL должен отвечать ожидаемым кодом, перенесённый — редиректом, удалённый — кодом ошибки. Проверьте title, description, canonical, H1, основной текст и ссылки.
Панель Elements показывает уже изменённый DOM. Исходный ответ смотрите в коде страницы, сетевом запросе или краулере без рендеринга. Сохраните его для повторного теста.
2. Сравните его с DOM после загрузки
Откройте страницу в чистом профиле браузера и проверьте те же элементы после обычной загрузки. Повторите тест при ограниченной скорости сети и процессора. Если смысловой блок появляется очень поздно или исчезает после одного неудачного запроса, проблема затрагивает и робота, и пользователя.
Сравнивайте смысл, а не технические классы. Заголовок, текст, ссылки и метаданные должны соответствовать конкретному URL, а приложение не должно заменять их общими значениями.
3. Проверьте сеть и ошибки JavaScript
Откройте Console и Network. Ищите ошибки JavaScript, заблокированные файлы, ответы API с 4xx или 5xx, долгие запросы и ресурсы, требующие пользовательскую сессию. Код 200 у HTML-оболочки не означает, что API вернул содержимое.
Откройте адреса JS- и CSS-файлов: они не должны блокироваться сервером или зависеть от авторизации. Если страницу собирают несколько сервисов, определите, отказ какого из них убирает H1, текст, ссылки или метатеги.
4. Сверьте результат с инструментами поисковых систем
Проверьте URL в кабинетах поисковых систем и сопоставьте обработанную версию с ожидаемой. Один удачный запуск не подтверждает стабильность шаблона. Если результат меняется, изучите время ответа, кэш и ошибки ресурсов.
Команда site: годится для быстрой разведки, но не заменяет данные кабинета и диагностику. Подробности есть в материале о проверке индексации в Яндексе и Google.
5. Проверьте обнаружение ссылок
Поисковой системе важно не только прочитать текущую страницу, но и перейти дальше. Навигация должна содержать обычные ссылки с адресами. Элемент без href, который реагирует на click и меняет состояние приложения, — ненадёжный путь обнаружения URL.
Запустите два обхода: без JavaScript и с рендерингом. Сравните найденные URL, глубину важных страниц и исходящие ссылки. Заметный разрыв покажет разделы, зависящие от клиентского кода. Затем проверьте логику внутренней перелинковки: каждая ссылка должна помогать читателю и вести на доступный канонический адрес.
6. Сверьте метатеги и структурированные данные
Title, description, canonical и robots должны соответствовать URL в надёжном состоянии страницы. Рискованная схема — сначала отдать canonical на главную, а затем заменить его скриптом. При сбое останется неверный сигнал.
Структурированные данные должны описывать видимый текст и не зависеть от действия пользователя. Валидатор проверяет синтаксис, а соответствие содержимому оценивают отдельно. Для статьи сверяют заголовок, дату, автора и изображение, для услуги — представленную услугу. Примеры есть в разборе schema.org.
7. Проверьте изображения и отложенную загрузку
У основного изображения должны быть рабочий адрес и понятный alt. Отложенная загрузка допустима, но не должна зависеть от сложного жеста. Проверьте адрес в DOM и все варианты srcset. Временные ссылки не должны истекать до повторного обхода.
Как выбрать способ рендеринга
- Серверный рендеринг. Сервер отдаёт готовый HTML. Нужен контроль кэша, нагрузки и согласованности серверного и клиентского состояния.
- Статическая генерация. HTML создаётся при сборке. Подходит статьям и стабильным посадочным; при изменении данных нужна схема обновления.
- Инкрементальная генерация. Страницы обновляются по правилам или запросам. Готовый HTML сочетается с более сложным управлением кэшем.
- Клиентский рендеринг. Браузер собирает содержимое из оболочки. Подход уместен в закрытых интерфейсах, а открытые страницы требуют контроля.
- Гибридный подход. Критичный контент приходит в HTML, интерактивные функции — на клиенте. Для сайта услуг или каталога это практичный компромисс.
Готовый HTML не исправит медленный сервер, дубли или ошибочный canonical, а само наличие JavaScript не мешает странице участвовать в поиске. Цель — сократить зависимости, из-за которых пропадают важные элементы.
Практический сценарий: услуга после перехода на SPA
Сайт услуг перенесли на новый фронтенд. В браузере страница выглядит полной, но сервер отдаёт общий title, пустой контейнер и подключение скрипта. Данные приходят из API, H1 появляется после запроса, переходы на смежные услуги сделаны кнопками.
Команда описывает ожидаемые элементы и сравнивает исходный HTML с DOM. Выясняется, что при задержке API текст появляется поздно, canonical остаётся общим, а краулер без рендеринга не находит соседние услуги. Исправление: отдавать уникальные метаданные, H1, краткое описание и обычные ссылки в HTML, а калькулятор и интерактивные блоки оставить клиентскими.
После релиза команда повторяет оба обхода, проверяет URL в поисковых кабинетах и смотрит логи. Критерии приёмки: элементы есть в ответе, ссылки обнаруживаются, ресурсы работают, canonical совпадает с адресом, ошибочные маршруты возвращают верный статус. Сам тест не гарантирует ускорения индексации.
Частые ошибки
- Проверять только глазами. Обычный браузер не показывает разницу между исходным и отрисованным состоянием.
- Тестировать только главную. Сбои часто находятся в карточках, фильтрах и новых шаблонах.
- Принимать скриншот за доказательство индексации. Он подтверждает один запуск рендеринга, а не включение URL в поиск.
- Закрывать JS и CSS от обхода. Без нужных ресурсов страница может собраться не полностью.
- Делать навигацию без href. Кнопка может быть удобна в интерфейсе, но не заменяет ссылку.
- Возвращать 200 для любого маршрута. Такие мягкие ошибки создают пустые URL и мешают диагностике.
- Оставлять динамический рендеринг постоянным костылём. Отдельная версия для робота сложнее в поддержке и может разойтись с пользовательской.
- Менять архитектуру без замеров до релиза. Без контрольных результатов нельзя точно понять, что исправилось.
Чек-лист перед выпуском
- для каждого важного шаблона выбран контрольный URL;
- сервер возвращает ожидаемый статус и не маскирует ошибки кодом 200;
- у страницы есть уникальные title, description, H1 и canonical;
- основное содержание доступно без клика, прокрутки и авторизации;
- навигация содержит обычные ссылки на канонические URL;
- JS, CSS, API и изображения доступны без системных ошибок;
- отрисованный DOM по смыслу совпадает с ожидаемой страницей;
- структурированные данные валидны и подтверждаются видимым текстом;
- обходы с JavaScript и без него сравнены по URL и ссылкам;
- проверены медленная сеть, ошибка API и несуществующий маршрут;
- после релиза тесты повторены, результаты сохранены;
- индексация оценивается отдельно от обхода и рендеринга.
Когда нужен разработчик
Исправление обычно выполняет разработчик. В задаче укажите URL, шаги воспроизведения, исходный HTML, DOM, сетевую ошибку, ожидаемый статус и критерий приёмки. Фраза «поисковик не любит JavaScript» не объясняет, что исправлять.
Чтобы быстрее собрать тест-кейсы и оформить задачу, можно использовать нейросеть XelaGroup. Её выводы о доступности страницы всё равно нужно подтверждать запросами и инструментами поисковых систем. Если нужна помощь с аудитом шаблонов и приоритетами исправлений, напишите в Telegram.
FAQ
Индексируют ли поисковые системы сайты на JavaScript?
Могут, если получают ресурсы, выполняют код и находят содержание. Чем больше зависимостей, тем выше риск неполного результата.
Обязательно ли переносить весь сайт на серверный рендеринг?
Нет. Сначала найдите проблемные шаблоны и элементы. Иногда достаточно отдавать с сервера метаданные, основной текст и ссылки, сохранив клиентскую интерактивность.
Что важнее: исходный HTML или отрисованный DOM?
Проверяйте оба. Исходный HTML показывает базовое состояние, DOM — итог выполнения кода. Для критичных элементов желательно, чтобы уже база была содержательной.
Можно ли проверить всё SEO-краулером?
Краулер удобен для массового сравнения обходов с рендерингом и без него. Но он не заменяет консоль браузера, сетевую диагностику и проверку URL в кабинетах поисковых систем.
Почему страница видна в проверке URL, но не находится в поиске?
Успешный рендеринг — только один этап. На индексацию также влияют доступность, canonical, дубли, содержание, внутренние ссылки и решение поисковой системы. Эти причины нужно проверять отдельно.
Когда повторять тест?
После изменений шаблона, фреймворка, API, маршрутизации, CDN или кэша, а также при расхождениях в индексации. Контрольные проверки стоит включить в приёмку релиза.