JavaScript давно перестал быть украшением страницы — на нём строятся каталоги, фильтры и целые интерфейсы. Но поисковый бот видит страницу не так, как пользователь: сначала он получает голый HTML, и только потом, в отдельной очереди, исполняет скрипты. Если ключевой контент появляется лишь после выполнения JS, он может попасть в индекс с задержкой или не попасть вовсе. Этот материал — практический разбор: как Яндекс и Google обрабатывают JavaScript, где ломается индексация и какие схемы рендеринга выбирать.
Как поисковый бот обрабатывает JavaScript
Индексация JS-страницы идёт в два этапа. Сначала краулер скачивает исходный HTML (то, что отдаёт сервер) и парсит ссылки. Затем страница ставится в очередь на рендеринг: бот запускает headless-браузер, исполняет скрипты, дожидается отрисовки DOM и лишь тогда видит финальный контент.
Google рендерит на движке Chromium и обрабатывает JS зрело. Яндекс тоже умеет исполнять JavaScript, но исторически делает это осторожнее и с большей задержкой. Вывод для рынка РФ: нельзя рассчитывать, что весь JS-контент будет одинаково хорошо разобран обоими поисковиками. Чем важнее текст и ссылки для ранжирования, тем меньше их стоит прятать за клиентским исполнением.
Три схемы рендеринга: CSR, SSR и пререндеринг
Стратегия рендеринга определяет, что бот получит в исходном HTML.
| Схема | Где формируется HTML | Виден ли контент боту сразу | Когда применять |
|---|---|---|---|
| CSR (клиентский) | В браузере после исполнения JS | Нет, только после рендеринга | Закрытые кабинеты, админки — то, что не индексируется |
| SSR (серверный) | На сервере при каждом запросе | Да, полный HTML в ответе | Коммерческие каталоги, карточки товаров, листинги |
| SSG / пререндеринг | Заранее в статические файлы | Да, готовый HTML | Блоги, статьи, стабильные лендинги |
CSR (Client-Side Rendering) — самый рискованный для SEO: сервер отдаёт почти пустой <div id="root">, контент дорисовывает браузер. SSR (Server-Side Rendering) решает проблему в корне — бот сразу получает полноценный HTML. SSG (Static Site Generation) и пререндеринг подходят, когда контент меняется редко. Рабочий минимум под Яндекс для коммерции — SSR или гибридные режимы Next.js / Nuxt.
Где ломается индексация: типичные сбои
- Контент только в JS. Если тексты, цены и
<title>появляются лишь после исполнения скриптов, бот может проиндексировать страницу без них. Для коммерческих запросов в Яндексе отсутствие цены и описания — прямой удар по ранжированию. - Навигация на onclick вместо
<a href>. Бот ходит по ссылкам, а не по JS-обработчикам: меню и пагинация наonclickне передают вес и могут оставить разделы вне индекса. - Блокировка JS и CSS в robots.txt. Если каталоги со скриптами и стилями закрыты, бот не отрендерит страницу корректно. Файлы рендеринга должны быть открыты.
- Таймауты и тяжёлые бандлы. Если скрипты висят на запросах к API, рендеринг может оборваться до появления контента — бот не ждёт бесконечно.
- Soft 404 на SPA. Несуществующие URL отдают код 200 с пустой оболочкой вместо честного 404/410 — в индекс попадают «пустышки».
Прогрессивное улучшение как базовый принцип
Здоровая архитектура строится по принципу progressive enhancement: сначала рабочий HTML, потом — улучшения через JS. Главный текст, заголовки, цены и внутренние ссылки должны присутствовать в исходном ответе сервера. JavaScript добавляет интерактив (фильтры, подгрузку, анимации), но не должен быть единственным носителем смысла.
Проверить просто: откройте «Просмотр кода страницы» (исходный HTML, не DOM) и поищите ключевой текст и ссылки. Если их нет — для бота их тоже нет до рендеринга. Принцип связан с приоритетом мобильной версии — см. mobile-first индексацию.
Скорость рендеринга и Core Web Vitals
Тяжёлый JavaScript бьёт не только по индексации, но и по поведению: большие бандлы блокируют главный поток, откладывают отрисовку и портят Core Web Vitals — фактор ранжирования в Google и косвенно в поведенческих сигналах Яндекса. Целевые нормативы: LCP < 2,5 с, INP < 200 мс, CLS < 0,1. Чтобы удержать их: разбивайте бандл на части (code splitting), применяйте defer/async для некритичных скриптов, откладывайте сторонние виджеты (чаты, аналитику, карты), резервируйте место под динамические блоки против скачков layout, сжимайте (gzip/brotli) JS и CSS. Детали — в материале про скорость загрузки сайта.
Как проверить рендеринг
Диагностика строится на сравнении исходного HTML и отрендеренного DOM:
- Исходный код страницы (Ctrl+U) — что отдаёт сервер; чего здесь нет, то зависит от JS.
- Инспектор DOM — что видно после скриптов. Разница и есть JS-зависимый слой.
- Яндекс.Вебмастер и Google Search Console (проверка URL) — как бот видит страницу и какие ресурсы заблокированы.
- Логи сервера — какие коды (200/301/404) видят краулеры на JS-маршрутах.
⚠️ РИСК: динамический рендеринг и клоакинг
Раньше частым решением был динамический рендеринг — отдавать ботам пререндеренный HTML, а людям клиентскую версию. Опасность в том, что если боту и пользователю показывают существенно разный контент, это переходит в клоакинг — запрещённую технику, за которую можно получить санкции в обоих поисковиках.
Безопасное правило: контент для бота и человека должен совпадать. Отдавать боту тот же HTML быстрее (через SSR) можно, подменять другим — нельзя. Динамический рендеринг — серая мера на переходный период, целевое решение — SSR или SSG.
Мини-кейс
Региональный интернет-магазин на React работал в режиме CSR: сервер отдавал пустую оболочку, а карточки товаров с ценами дорисовывались скриптами. В исходном HTML не было ни <title>, ни текстов, ни цен — для бота карточки были пустыми. Вдобавок в robots.txt был закрыт каталог со скриптами.
Что сделали: открыли JS/CSS в robots.txt, перевели каталог и карточки на SSR через Next.js, добавили в исходный HTML заголовки, описания и цены, заменили фильтры-onclick на ссылки с реальными URL. После переобхода в Яндекс.Вебмастере страницы стали индексироваться с полным содержимым. Конкретные цифры по позициям и трафику не приводим — они зависят от ниши, конкуренции и сезонности.
FAQ
Индексирует ли Яндекс JavaScript-контент?
Да, но с задержкой и осторожнее, чем Google. Критичный контент (цены и описания для коммерческих запросов) надёжнее отдавать в исходном HTML через SSR.
Чем SSR отличается от пререндеринга (SSG)?
SSR формирует HTML на сервере при каждом запросе — для часто меняющегося контента (каталоги, листинги). SSG собирает статику заранее — для блогов, статей и стабильных лендингов.
Можно ли оставить SPA на чистом CSR и не потерять SEO?
Для индексируемых страниц рискованно. CSR допустим для закрытых разделов (кабинеты, админки); для продвигаемых — SSR.
Нужно ли открывать JS и CSS в robots.txt?
Да. Если ресурсы для рендеринга закрыты, бот не отрисует страницу корректно. Закрывать стоит служебные разделы, а не файлы отображения.
Динамический рендеринг — безопасно?
Это временная серая мера. Бот и пользователь должны получать один и тот же контент, иначе это клоакинг и риск санкций.
Материал подготовлен экспертами Chrome Media — по техническому SEO и продвижению JavaScript-сайтов в Яндексе и Google.
Добавить комментарий