SSR vs CSR vs SSG для SEO: что выбрать в 2026 году

«Google давно умеет рендерить JavaScript, можно не париться» — пожалуй, самое опасное упрощение в современном фронтенд-SEO. Googlebot действительно рендерит JS, но не мгновенно, не бесплатно с точки зрения краулингового бюджета и не всегда полностью. Разберём, как реально работает индексация при разных стратегиях рендеринга и какую выбрать для конкретной страницы.

Четыре стратегии и что видит робот

CSR (Client-Side Rendering)

Сервер отдаёт почти пустой HTML с тегом <div id="root"> и пачкой JS-бандлов. Весь контент собирается в браузере после загрузки и выполнения скриптов.

Что видит робот: сначала — пустую страницу. Чтобы получить финальный контент, Google должен поставить страницу в очередь на рендеринг (это отдельный, более медленный конвейер, чем обычное сканирование HTML), дождаться очереди, выполнить JS и только тогда проиндексировать результат. На практике это означает задержку в индексации — от часов до нескольких дней — и риск, что часть контента (особенно если он подгружается по дополнительным запросам после первого рендера) робот вообще не дождётся.

SSR (Server-Side Rendering)

Сервер на каждый запрос рендерит полный HTML с контентом и отдаёт его сразу. Робот получает готовую разметку без необходимости выполнять JS для базовой индексации.

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

SSG (Static Site Generation)

HTML генерируется один раз при сборке проекта и раздаётся как статика — самый быстрый вариант и для пользователя, и для робота: сервер просто отдаёт готовый файл, без вычислений на лету.

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

ISR (Incremental Static Regeneration)

Гибрид: страница генерируется статически, но переодически перегенерируется в фоне (по таймеру или по запросу), не требуя полной пересборки всего сайта. Хороший компромисс для каталогов с тысячами страниц, где полная статическая пересборка при каждом изменении слишком дорога.

Что на практике ломает индексацию

Контент, который подгружается по клику или скроллу. Если основной текст появляется только после взаимодействия пользователя (вкладки, «показать ещё», бесконечный скролл без серверной пагинации), робот может его просто не увидеть — он не кликает и не скроллит как человек.

Критичные мета-теги, генерируемые на клиенте. Title и description, которые ставятся через JS после монтирования компонента, иногда успевают попасть в индекс, а иногда — нет, в зависимости от того, в какой момент Google «сфотографировал» состояние страницы. Надёжный вариант — выставлять метаданные на сервере.

Гидратация, ломающая контент до полной загрузки. Если на CSR-странице сервер успел отдать что-то (например, через предварительный рендер), а потом клиентский JS полностью переписывает DOM, есть риск рассинхронизации между тем, что увидел робот, и тем, что видит пользователь — это может восприниматься как cloaking, даже если это случайность, а не злой умысел.

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

Личный пример: как легко получить случайный CSR

У нас на reChecker есть страницы публичных отчётов (/report/[домен]). Технический аудит показывает результат через клиентский компонент ('use client') — потому что там нужна интерактивность: вкладки, раскрывающиеся блоки, состояние. Формально это клиентский рендеринг.

Но критичной проблемой для индексации это не стало — потому что Next.js App Router рендерит клиентские компоненты на сервере при первом запросе (так называемый server-side render клиентского компонента), и в HTML, который получает робот, уже есть весь контент. Гидратация на клиенте происходит поверх готовой разметки, не перезаписывая её с нуля.

Мораль: «use client» в современных фреймворках — не приговор для SEO сам по себе, важно, что именно происходит при первом запросе к серверу. Прежде чем делать выводы, стоит реально посмотреть на HTML, который получает робот, а не гадать по архитектуре компонента.

Как проверить, что видит робот именно ваш сайт

Самый надёжный способ — не гадать, а посмотреть на сырой HTML-ответ сервера до выполнения JS:

curl -s https://example.com/page | grep -o '<title>[^<]*</title>'

Если в первом ответе сервера уже есть заголовок, описание и основной текстовый контент — индексация, скорее всего, не пострадает даже при сложном клиентском взаимодействии поверх. Если страница приходит почти пустой («<div id="root"></div>» и ничего больше) — стоит разобраться, действительно ли критичный для SEO контент рендерится на сервере.

Дополнительно полезно прогнать страницу через технический аудит — он показывает мета-теги и часть структурных данных так, как их видит автоматический парсер, а не браузер с включённым JS, что близко к тому, как страницу читает поисковый робот при первичном сканировании.

Что выбрать на практике

• Контентные страницы (блог, документация, лендинги, карточки товаров) — SSG или ISR. Максимальная скорость, минимальная нагрузка на сервер, надёжная индексация.
• Персонализированные/часто меняющиеся данные, важные для SEO (например, результаты поиска по сайту, которые тоже должны индексироваться) — SSR.
• Внутренние интерфейсы, личные кабинеты, дашборды, всё, что не должно индексироваться — чистый CSR вполне допустим, индексация здесь не нужна и не должна быть целью (такие разделы стоит дополнительно закрыть через robots.txt или meta robots).
• Гибридные страницы (как наши отчёты) — серверный рендеринг базового контента + клиентская интерактивность поверх. Это не отдельная «четвёртая» стратегия, а правильное использование SSR/SSG с прогрессивным улучшением через JS.

Чек-лист

• Проверен сырой HTML-ответ сервера (curl или «просмотр кода страницы») на наличие title, description и основного контента;
• Критичные для SEO мета-теги выставляются на сервере, а не через document.title в клиентском JS;
• Контент, важный для индексации, не спрятан за обязательным кликом/скроллом;
• Для страниц с большим объёмом и редко меняющимся контентом рассмотрена статическая генерация или ISR вместо постоянного SSR;
• Разделы, не предназначенные для индексации (личные кабинеты, админки), не тратят краулинговый бюджет — закрыты через robots.txt.

Заключение

Выбор стратегии рендеринга — это не религиозный спор «SSR хорош, CSR плох». Это инженерный компромисс между скоростью разработки, нагрузкой на сервер и тем, что реально получает робот при первом запросе. Главное правило простое: для всего, что должно ранжироваться, контент должен быть в HTML-ответе сервера — будь то через SSR, SSG или ISR. Всё остальное — детали реализации.

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