SSR, SSG и гидратация

Решения проблемы CSR: отдаём боту готовый HTML через серверный рендеринг или предгенерацию.

SSR (Server-Side Rendering) — сервер рендерит страницу в готовый HTML на каждый запрос. SSG (Static Site Generation) — HTML генерируется заранее, на этапе сборки. И там, и там бот получает контент сразу.

SSR: рендер на сервере

При SSR сервер выполняет JS-приложение и отдаёт уже готовый HTML с контентом и мета-тегами. Бот в первой же волне получает всё, что нужно для индексации. Цена — нагрузка на сервер: рендер делается на каждый запрос.

Подходит для динамических страниц, которые часто меняются (лента, каталог с ценами, персонализация).

SSG: предгенерация при сборке

При SSG страницы рендерятся один раз во время билда и кладутся как статические HTML-файлы. Это быстро (отдаётся готовый файл с CDN) и идеально для SEO. Минус — контент «застывает» до следующей сборки.

Подходит для редко меняющегося контента: блог, документация, лендинги. Учебники codechick.io по сути такого класса — стабильный контент, который выгодно отдавать готовым HTML.

Стратегия	Когда рендерится	Хорошо для
CSR	в браузере, после JS	приватные дашборды (SEO не нужен)
SSR	на сервере, на каждый запрос	динамика, персонализация
SSG	заранее, при сборке	блог, доки, лендинги

Гидратация

Гидратация (hydration) — процесс, когда отрендеренный сервером статический HTML «оживляется» в браузере: JS навешивает обработчики и делает страницу интерактивной. Так совмещаются плюсы обоих миров: бот и пользователь сразу видят контент (из SSR/SSG), а затем страница становится полноценным SPA.

SSR/SSG отдал HTML  -->  пользователь/бот видят контент сразу
        |
   браузер качает JS
        |
   гидратация: JS навешивает обработчики --> страница интерактивна

Почему Nuxt и Next хороши для SEO

Фреймворки Nuxt (Vue) и Next (React) из коробки дают выбор режима для каждой страницы: SSR, SSG или CSR. Они умеют рендерить мета-теги (title, OG, canonical) на сервере, генерировать статические страницы и автоматически гидратировать. Разработчику не нужно вручную городить серверный рендер — фреймворк решает главную SEO-проблему SPA.

Динамический рендеринг (legacy-обходной путь)

Исторический приём: отдавать ботам заранее отрендеренный HTML (через сервис вроде prerender), а людям — обычный SPA. Сейчас Google считает это временным костылём и рекомендует SSR/SSG. Знать стоит, но как первый выбор — не использовать.

Как работает под капотом: выбор стратегии

def choose_strategy(needs_seo, changes_often, personalized):
    if not needs_seo:
        return "CSR — SEO не важен (приватный дашборд)"
    if personalized or changes_often:
        return "SSR — нужен свежий HTML на каждый запрос"
    return "SSG — статика, лучший вариант для SEO и скорости"

print(choose_strategy(True,  False, False))  # блог
print(choose_strategy(True,  True,  True))   # каталог с ценами
print(choose_strategy(False, True,  True))   # личный кабинет

Вывод:

SSG — статика, лучший вариант для SEO и скорости
SSR — нужен свежий HTML на каждый запрос
CSR — SEO не важен (приватный дашборд)

Частые ошибки

SSR, но мета-теги всё равно на клиенте — половина проблемы остаётся; рендерите теги на сервере.
Расхождение серверного и клиентского рендера — ошибки гидратации, контент «мигает» или ломается.
SSG для часто меняющихся данных — пользователи видят устаревший контент до пересборки.
Динамический рендеринг как постоянное решение — лучше перейти на SSR/SSG.

Итог

SSR рендерит HTML на сервере на каждый запрос, SSG — заранее при сборке; оба отдают боту готовый контент.
Гидратация оживляет серверный HTML в браузере — контент виден сразу, потом появляется интерактив.
Nuxt и Next дают SSR/SSG/CSR из коробки и решают главную SEO-проблему SPA.