SSR в Nuxt: зачем он нужен сайту и как влияет на SEO

SSR (серверный рендеринг) в Nuxt нужен, чтобы сервер отдавал браузеру и поисковому роботу готовую HTML-страницу с текстом, а не пустой шаблон, который наполняется JavaScript. Для сайтов, которые должны находиться в поиске — каталогов, блогов, корпоративных сайтов, — это разница между проиндексированным контентом и страницей, которую робот видит пустой.

Разберём, как это устроено, где SSR действительно помогает и какие проблемы он приносит.

Что такое SSR и чем он отличается от SPA?

SSR — это режим, в котором HTML страницы собирается на сервере при каждом запросе, а в SPA сервер отдаёт пустой каркас и скрипт, который строит страницу уже в браузере. Для пользователя с быстрым интернетом разница может быть незаметна. Для робота и медленного телефона — огромна.

В Nuxt оба режима, а также промежуточные, включаются настройкой. По умолчанию Nuxt работает с SSR:

// nuxt.config.ts
export default defineNuxtConfig({
  ssr: true,
  routeRules: {
    '/': { prerender: true },
    '/blog/**': { swr: 600 },
    '/account/**': { ssr: false },
  },
});

Правила routeRules позволяют смешивать подходы: публичные страницы отдаются с сервера или заранее собираются при сборке, а личный кабинет, которому индексация не нужна, работает как SPA.

Как SSR влияет на SEO?

SSR влияет на SEO тем, что текст, заголовки, ссылки и метатеги есть в ответе сервера сразу. Поисковику не нужно выполнять JavaScript, чтобы понять, о чём страница, и перейти по ссылкам дальше.

Google умеет выполнять JavaScript, но делает это отложенно и не всегда полностью. Другие поисковые системы и боты, которые собирают ответы для AI-ассистентов, выполняют скрипты хуже или не выполняют вовсе. Страница, которая без JS пустая, для них пустая и есть.

Что проверить на своём сайте

1. Откройте страницу через curl или «Просмотр кода страницы» — виден ли в HTML основной текст?
2. Есть ли в ответе сервера title, description, canonical и hreflang?
3. Настоящие ли ссылки в меню и пагинации (<a href>), а не кнопки с обработчиком клика?
4. Отдаёт ли несуществующая страница код 404, а не 200 с надписью «не найдено»?

Когда SSR не нужен?

SSR не нужен там, где страницы не должны попадать в поиск: личные кабинеты, админки, внутренние инструменты. Серверный рендеринг в них только добавляет нагрузку на сервер и усложняет код без пользы.

Не нужен он и для полностью статичных страниц, которые не меняются между сборками. Для них выгоднее пререндеринг: HTML собирается один раз при сборке и отдаётся как обычный файл. Такие страницы можно раздавать прямо с CDN, и сервер приложения в их отдаче не участвует вовсе.

Тип страницы	Рекомендуемый режим в Nuxt
Главная, лендинг	Пререндеринг при сборке
Блог, каталог, карточки товаров	SSR, при необходимости с кешированием
Личный кабинет	Клиентский рендеринг (ssr: false)
Админ-панель	Клиентский рендеринг или отдельное приложение

Какие проблемы приносит SSR?

Главная проблема SSR — ошибки гидратации, когда HTML с сервера не совпадает с тем, что строит браузер. Обычно их вызывают значения, которые на сервере и в браузере разные: текущее время, случайные числа, данные из localStorage, размеры окна.

Типичные решения:

• всё, что зависит от браузера, показывать после монтирования компонента или внутри <ClientOnly>;
• данные загружать через useAsyncData, чтобы ответ приехал в браузер вместе со страницей и не запрашивался повторно;
• не использовать window и document в коде, который выполняется на сервере.

Нагрузка на сервер

При SSR каждая страница собирается сервером, и под трафиком это ощутимо. Кеширование ответов (swr, isr в routeRules) и CDN перед сервером обычно решают вопрос без переписывания кода.

Как SSR влияет на скорость загрузки?

SSR обычно ускоряет первую отрисовку: браузер показывает текст, как только получил HTML, не дожидаясь загрузки и выполнения скриптов. На медленных устройствах и мобильном интернете это заметно по метрикам LCP и FCP.

Но SSR не делает сайт быстрым автоматически. Тяжёлые скрипты, неоптимизированные картинки и лишние сторонние виджеты всё равно замедлят страницу — просто уже после того, как пользователь увидел текст.

Что ещё нужно для SEO, кроме SSR?

Кроме SSR, поисковику нужны понятная структура документа и технические сигналы, которые помогают правильно проиндексировать страницу. Серверный рендеринг лишь гарантирует, что всё это окажется в HTML, — наполнять его всё равно приходится вручную.

Минимальный набор, который мы проверяем на каждом Nuxt-проекте:

• один h1 на странице и логичная иерархия h2–h3 — по ним робот и читатель понимают структуру;
• уникальные title и description для каждой страницы, а не один на весь сайт;
• canonical, чтобы адреса с параметрами и дубли не спорили друг с другом;
• hreflang для языковых версий — и только на те переводы, которые действительно существуют;
• карта сайта со всеми публичными страницами и датами их обновления;
• структурированные данные (JSON-LD): статья, хлебные крошки, вопросы и ответы.

Модуль i18n и языковые версии

В двуязычном проекте на Nuxt за адреса, canonical и hreflang отвечает модуль @nuxtjs/i18n. Если у страниц разные слаги на разных языках — как у статей блога, — модулю нужно явно передать адреса переводов. Иначе переключатель языка и hreflang поведут на несуществующую страницу, и поисковик получит ссылку на 404.

Коротко

• SSR отдаёт готовый HTML: текст и ссылки видны роботу без выполнения JavaScript.
• Для публичных страниц, которые должны находиться в поиске, SSR или пререндеринг обязательны.
• Личным кабинетам и админкам SSR не нужен — в Nuxt это настраивается по маршрутам.
• Основные сложности — гидратация и нагрузка на сервер; обе решаются стандартными средствами Nuxt.