JavaScript-SEO: как продвигать сайты на React, Vue и SPA

Сайты на React, Vue и Angular выглядят современно и быстро работают для пользователя, но для поискового робота они нередко превращаются в пустую страницу без текста и ссылок. Если контент собирается в браузере с помощью JavaScript, его можно вообще не увидеть в индексе — а значит, не получить ни позиций, ни трафика. В этой статье разбираем, как устроена индексация JS-сайтов и как настроить рендеринг так, чтобы SEO-продвижение приносило результат даже на самом «тяжёлом» фронтенде.

Почему сайты на JavaScript сложны для индексации

Классический сайт отдаёт серверу готовый HTML: робот скачивает страницу и сразу видит заголовки, текст, ссылки и микроразметку. Сайт на JS-фреймворке устроен иначе. Сервер отдаёт почти пустую оболочку — обычно это один div с id="root" или id="app" и подключённый бандл скриптов. Весь контент — тексты, карточки товаров, меню, ссылки — генерируется уже в браузере, когда JavaScript отработает. Для пользователя это незаметно: страница собирается за доли секунды. Для робота это означает, что в момент первого запроса смысловой нагрузки на странице нет.

Поисковая система обязана решить: исполнять этот JavaScript или нет. Исполнение скриптов — дорогая операция. Робот должен запустить полноценный браузерный движок, дождаться загрузки всех ресурсов, выполнить код, дождаться ответов от API. Это в десятки раз затратнее, чем просто скачать текстовый HTML. Поэтому поисковики не рендерят каждую страницу сразу — они откладывают рендеринг в отдельную очередь, и эта очередь может растягиваться от нескольких дней до нескольких недель.

Отсюда главный риск JS-SEO: если важный контент появляется только после исполнения скриптов, между сканированием страницы и попаданием контента в индекс возникает разрыв. Для нового сайта или часто обновляемого каталога это критично — товары, статьи и услуги попадают в поиск с большим опозданием либо не попадают вовсе, если на этапе рендеринга что-то пошло не так.

Что видит робот: исходный HTML против отрендеренного DOM

Ключевое различие, которое нужно усвоить владельцу JS-сайта, — это разница между двумя состояниями страницы. Исходный HTML — то, что сервер отдаёт в ответ на запрос, до исполнения скриптов. Именно его вы видите в браузере по команде «Просмотр исходного кода страницы» (Ctrl+U). Отрендеренный DOM — то, во что превращается страница после того, как JavaScript отработал; его видно в инструментах разработчика во вкладке Elements.

Проверьте свой сайт прямо сейчас: откройте товар или статью, нажмите Ctrl+U и поищите в исходном коде основной текст страницы или заголовок H1. Если по Ctrl+U контента нет, а в инструментах разработчика (F12, вкладка Elements) он есть — значит, ваш сайт рендерится на клиенте, и весь контент существует только в отрендеренном DOM. Поисковик увидит его лишь после исполнения JavaScript, которое, как мы выяснили, происходит не всегда и не сразу.

Это та самая точка, где теряется трафик. Робот при первом проходе индексирует исходный HTML. Если там пусто, страница в индексе будет либо без контента, либо с заглушкой «Loading…». Все ваши тексты, тщательно собранное семантическое ядро и проработанные метатеги окажутся бесполезны, пока робот не доберётся до второй волны — до рендеринга.

Если основной контент страницы не виден в исходном HTML по Ctrl+U — для поисковика этой страницы пока не существует. Всё остальное в JS-SEO вторично.

Двухволновая индексация Google и особенности Яндекса

Google официально описывает индексацию JS-сайтов как двухволновую (two-wave indexing). В первой волне робот скачивает и обрабатывает исходный HTML — то, что пришло с сервера. Он находит ссылки, ставит страницу в очередь, индексирует тот текст, что есть. Во второй волне страница попадает в очередь рендеринга (Web Rendering Service), где Googlebot запускает headless-браузер на движке Chromium, исполняет JavaScript, формирует финальный DOM и уже его передаёт в индекс. Между волнами проходит время — от часов до недель, в зависимости от приоритета сайта и нагрузки.

Для Google это означает: технически он умеет индексировать JS-контент, но с задержкой и при условии, что вы не мешаете ему рендерить. Если страница часто меняется (новости, цены, остатки), задержка второй волны бьёт по актуальности. Если на сайте миллионы страниц, очередь рендеринга съедает краулинговый бюджет, и часть контента просто не доходит до индекса.

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

Виды рендеринга: CSR, SSR, SSG, динамический рендеринг и гидрация

Стратегия рендеринга — это то, где именно собирается HTML страницы: в браузере пользователя, на сервере при запросе или заранее на этапе сборки. От выбора напрямую зависит, увидит ли робот контент. Разберём основные подходы.

CSR (Client-Side Rendering, клиентский рендеринг) — классика чистого React или Vue. Сервер отдаёт пустую оболочку, весь HTML строится в браузере. Лучший вариант по интерактивности, худший по SEO. Подходит для закрытых разделов (личный кабинет, админка, дашборды), которым индексация не нужна.

SSR (Server-Side Rendering, серверный рендеринг) — сервер исполняет JavaScript и отдаёт роботу и пользователю готовый HTML с контентом. Робот сразу видит текст и ссылки в первой волне, рендеринг ему не нужен. Это золотой стандарт SEO для динамических сайтов. Реализуется через Next.js (React), Nuxt (Vue), Angular Universal. Минус — нагрузка на сервер и более сложная архитектура.

SSG (Static Site Generation, статическая генерация) — HTML всех страниц генерируется заранее, на этапе сборки проекта, и отдаётся как готовые статические файлы. Максимально быстро и максимально дружелюбно к поисковикам. Идеально для контента, который меняется не каждую секунду: блог, лендинги, документация, витрина услуг. Минус — при тысячах часто меняющихся страниц пересборка становится тяжёлой.

Динамический рендеринг и пререндеринг — компромисс: сайт определяет, кто пришёл. Пользователю отдаётся обычная CSR-версия, а поисковому роботу — заранее отрендеренный статический HTML (через сервис типа Prerender.io или собственный headless-браузер). Google относится к этому терпимо как к временному решению, но это «костыль»: вы поддерживаете две версии и рискуете рассинхроном. Для нового проекта лучше сразу заложить SSR или SSG.

Гидрация (hydration) — не отдельный вид рендеринга, а процесс «оживления». При SSR/SSG сервер отдаёт готовый HTML, а затем в браузере подгружается JavaScript и «привязывается» к этой разметке, делая её интерактивной. Для SEO важно: пока гидрация идёт, контент уже виден роботу из серверного HTML. Но если гидрация тяжёлая и долгая, страдают Core Web Vitals и пользовательский опыт.

Таблица: сравнение видов рендеринга по SEO

Почему чистый CSR опасен для SEO

Соблазн оставить чистый CSR понятен: он проще в разработке, дешевле в хостинге, фронтенд-команда привыкла к нему. Но для проекта, который должен приводить органический трафик, это ловушка. Перечислим, что именно ломается.

Во-первых, задержка индексации. Контент попадает в индекс только после второй волны рендеринга, а это дни и недели для Google и почти никогда для Яндекса. Во-вторых, потеря части контента: если при рендеринге случилась ошибка JavaScript, упал запрос к API или истёк таймаут, робот зафиксирует пустую страницу — и проиндексирует пустоту. В-третьих, метатеги. При CSR title и description часто проставляются скриптом после загрузки, и в исходном HTML стоят дефолтные значения — робот видит одинаковые заглушки на всех страницах.

В-четвёртых, страдает скорость. CSR требует скачать и исполнить большой бандл до того, как пользователь увидит контент, что бьёт по Core Web Vitals и по скорости загрузки сайта — а это прямые факторы ранжирования и в Google, и в Яндексе. Если вы только выбираете технологию для будущего проекта, обсудите стек на этапе создания сайта: правильно выбранный фреймворк с поддержкой SSR избавит от половины проблем заранее.

Типичные ошибки JS-SEO

Даже на сайте с серверным рендерингом легко наделать ошибок, которые сводят на нет всю работу. Вот частые проблемы, которые мы находим на аудитах JS-проектов.

К этому добавим ещё несколько частых бед. Пустой первый HTML — когда даже при заявленном SSR на части страниц рендеринг не срабатывает и робот получает оболочку. Медленная гидрация — страница «дёргается», метрика INP проседает, поведенческие ухудшаются. Soft 404 — несуществующий товар отдаёт код 200 и пустую страницу вместо честного 404, и такие пустышки засоряют индекс. Каждая из этих ошибок по отдельности способна обрушить органику, а в сочетании они гарантированно держат сайт вне ТОПа. Подробнее про управление сканированием смотрите в материале про краулинговый бюджет и про настройку robots.txt.

Как проверить, индексируется ли JS-контент

Диагностика — первый шаг перед любыми переделками. Не нужно гадать: есть точные способы увидеть страницу глазами робота.

Хороший приём — забить уникальную фразу из текста страницы в поиск с оператором точного совпадения. Если страница находится по этой фразе, контент проиндексирован. Если нет — робот его не увидел, даже если визуально на сайте всё на месте. Эту проверку стоит сделать частью регулярного контроля индексации сайта.

Метатеги, title и роутинг в SPA

В одностраничном приложении (SPA) при переходе между «страницами» URL меняется, а полной перезагрузки нет — обновляется только часть DOM. Проблема в том, что по умолчанию title, description и canonical при таком переходе не меняются: робот, дошедший до внутренней страницы, видит метатеги главной. Результат — дубли title и description по всему сайту и каша в сниппетах.

Решение — управление метатегами на смену роута. В React это библиотеки вроде react-helmet или встроенные средства Next.js (метаданные на уровне страницы), во Vue — соответствующие плагины Nuxt. Каждый маршрут должен выставлять свои уникальные title и description, свой canonical, корректные Open Graph и при необходимости hreflang. Но критично: при SSR/SSG эти метатеги должны попадать в исходный HTML, а не проставляться скриптом постфактум — иначе для «слабого» робота они снова окажутся невидимы.

Отдельно проследите за каноническими адресами и дублями. SPA легко плодит технические дубли: со слешем и без, с параметрами фильтров, с разным регистром. Каждая такая вариация должна указывать canonical на основную версию. Подробно эта механика разобрана в материале про canonical и дубли.

Ленивая загрузка, краулинговый бюджет и стратегия

Ленивая загрузка (lazy load) — мощный инструмент скорости, но в SEO её нужно применять осторожно. Lazy load изображений ниже первого экрана — это хорошо и поддерживается нативно через атрибут loading="lazy". А вот ленивая загрузка основного текстового контента или товаров по событию скролла — плохо: робот не скроллит так, как человек, и может не догрузить контент. Правило простое: всё, что должно ранжироваться, должно присутствовать в DOM без пользовательских действий.

Краулинговый бюджет на JS-сайтах расходуется быстрее. Каждая страница, требующая рендеринга, нагружает очередь сильнее обычной. На крупном каталоге это приводит к тому, что часть страниц робот просто не успевает обработать. SSR и SSG снимают эту нагрузку: роботу достаётся готовый HTML, рендерить ничего не нужно, бюджет тратится эффективнее. Грамотная перелинковка и аккуратный sitemap дополнительно помогают роботу находить и приоритизировать важные страницы.

Как выбрать стратегию рендеринга на практике? Отталкивайтесь от типа контента. Контент меняется редко и его много — SSG. Контент динамический, важна актуальность, аудитория в рунете — SSR. Раздел не нужен в поиске — CSR. Часто оптимальна гибридная схема: витрина, каталог и блог на SSR/SSG ради SEO, а личный кабинет на CSR. Пока вы перестраиваете рендеринг и ждёте переиндексации, трафик можно подстраховать контекстной рекламой — она приводит посетителей сразу, не дожидаясь, пока поисковик разберётся с вашим JavaScript. Примеры того, как мы выводили JS-проекты в ТОП, собраны в портфолио.

Чек-лист JS-SEO перед запуском

Частые вопросы