JavaScript SEO — Next.js, RSC, Streaming SSR

TL;DR

Современные JS-фреймворки (Next.js, Nuxt, Astro, Remix) рендерятся Googlebot, но есть нюансы: «второй проход» рендеринга ненадёжен для низкоавторитетных доменов и больших сайтов, Яндекс хуже Google с JS, AI-краулеры часто не рендерят вообще. Безопасный путь — SSR/SSG + streaming, отдавать готовый HTML на первом ответе.

Этап 1. Диагностика — что видит Google

Что видит Googlebot

0 из 6 (0%)

GSC → URL Inspection → View tested page → Screenshot
GSC → URL Inspection → View tested page → HTML — есть ли весь контент
View source (Cmd+U в браузере) — что в исходном HTML
Сравнить view source vs DevTools Elements — что добавляет JS
Если в view source нет H1, контента, ссылок — Googlebot увидит то же
Mobile-friendly test показывает, что Google рендерит

Сначала опровергни тех-гипотезу

Прежде чем платить за миграцию рендеринга, докажи, что проблема в рендере. Если в HTML, который видит бот, уже есть <title>, <h1>, цена и текст; страницы коммерческого раздела в индексе; а в панели вебмастера фатальных ошибок нет (статусы ABSENT) — рендер исправен, и причина слабого ранжирования контентная, а не техническая: нет Schema, обрывочный meta description, нет коммерческих посадочных и перелинковки. Дорогая миграция на SSR здесь денег не вернёт — бюджет идёт в контент, разметку и перелинковку. Не лечи рендер, если рендер не болен.

Этап 2. Что видят AI-краулеры

В 2026 большинство AI-краулеров не рендерят JS или делают это плохо.

AI crawlers

0 из 4 (0%)

Тест через curl: curl -A "GPTBot" https://yoursite.com — что отдаётся
Те же тесты для ClaudeBot, PerplexityBot
Если контент только в JS — AI его не видит
Server-side rendering обязателен для AI-видимости

Этап 3. Стратегия рендеринга

SSG (Static Site Generation)

Лучше всего для SEO. HTML генерируется на этапе сборки.

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

Next.js: generateStaticParams + Server Components без dynamic = 'force-dynamic'.

SSR (Server-Side Rendering)

HTML рендерится на сервере при каждом запросе. Контент свежий, SEO работает.

Когда подходит: e-commerce с динамическими данными, персонализированные страницы.

Next.js: Server Components без cache, либо dynamic = 'force-dynamic'.

ISR (Incremental Static Regeneration)

Гибрид SSG + SSR — пересборка отдельных страниц по требованию.

Когда подходит: большие e-commerce каталоги, новостные сайты.

Next.js: revalidate в Server Components.

CSR (Client-Side Rendering)

HTML почти пустой, JS добавляет контент. Худшее для SEO.

Когда подходит: dashboard’ы за авторизацией, личный кабинет. НЕ для публичных страниц.

Выбор стратегии

0 из 5 (0%)

Каждая публичная страница использует SSG или SSR
CSR только для авторизованных секций
Server Components используются по умолчанию (Next.js 13+)
Client Components только когда нужна интерактивность (use client)
Streaming SSR для длинных страниц (Suspense boundaries)

Этап 4. React Server Components (RSC) специфика

Next.js 13+ с App Router. Большая часть кода выполняется на сервере, клиент получает готовый HTML.

RSC best practices

0 из 7 (0%)

По умолчанию все Components — Server (без use client)
use client только для интерактивности (onClick, useState)
fetch в Server Components — данные прямо в HTML
generateMetadata для динамических meta-тегов
Метаданные (title/description/openGraph) указаны явно
JSON-LD schema через <script type="application/ld+json"> в layout/page
Static params для известных путей через generateStaticParams

Этап 5. Streaming SSR

Длинная страница рендерится по частям — пользователь видит начало пока остальное грузится. Лучше для UX, нейтрально для SEO.

Streaming

0 из 5 (0%)

Suspense boundaries вокруг slow data fetches
loading.tsx для page-level fallback
Critical content (above-the-fold) рендерится первым
TTFB остаётся низким даже при slow data
Google рендерит финальный HTML, не initial chunk

Этап 6. Изоморфные ссылки

Все navigation должно быть real <a href> тегами, не onClick={navigate}.

Navigation

0 из 5 (0%)

Все ссылки — через <Link href="..."> (Next.js) или <a>
Нет JS-only navigation (onClick без href)
View source показывает все важные ссылки
Хлебные крошки рендерятся серверно
Pagination — реальные ссылки

Этап 7. Перформанс (CWV для JS-сайтов)

JS-фреймворки обычно проседают в INP из-за hydration.

CWV для JS

0 из 7 (0%)

Bundle size минимизирован (Webpack Bundle Analyzer)
Code splitting по routes
React.lazy для тяжёлых компонентов below-the-fold
startTransition/useDeferredValue для non-urgent updates
Third-party скрипты загружаются через next/script с strategy="lazyOnload"
Hydration не блокирует main thread (Partial Hydration / Islands)
Метрики INP проверены реально (не только PageSpeed Lab)

См. Core Web Vitals 2026.

Этап 8. Яндекс specifics

Яндекс исторически хуже Google рендерит JS. В 2024-2026 ситуация улучшилась, но всё ещё SSR/SSG предпочтительнее.

Yandex JS

0 из 4 (0%)

Я.Вебмастер → Инструменты → Проверка ответа сервера
Все важные страницы возвращают полный HTML
YandexBot user-agent проверен (curl -A "YandexBot")
Если контент в JS — добавлять SSR для Яндекса в приоритете

Этап 9. Конкретные фреймворки

Фреймворк	Рекомендуемая стратегия
Next.js 13+	App Router + Server Components, ISR для каталогов
Nuxt 3	universal mode + nitro
Astro	По умолчанию SSG, opt-in на client islands
Remix	SSR по умолчанию — отлично для SEO
SvelteKit	SSR/SSG смешанно
Gatsby	SSG, но fading из-за конкуренции

Анти-паттерны

❌ CSR для маркетинговых страниц — Googlebot увидит пустой HTML.
❌ Все компоненты use client — теряем серверный рендеринг.
❌ Hydration mismatch — Google видит контент, потом он меняется при hydration → нестабильность.
❌ Бесконечный скролл без pagination — Googlebot не видит контент ниже первого экрана.
❌ Modal popups для контента — поисковики не видят, что в модалке.
❌ Lazy-load critical content — H1 и важный текст должны быть в initial HTML.

Дальше

Технический аудит 2026 — общий чек-лист
Core Web Vitals 2026 — оптимизация скорости
Schema.org JSON-LD — структурированная разметка