Стек №1 для сложных React-приложений: SSR, App Router, Server Components. Силён в SEO, но требует точной настройки — одна ошибка с динамическим рендерингом обнуляет всю работу. Next.js даёт максимальную гибкость SSR/SSG/ISR, но именно эта гибкость — главный риск. На Next.js одинаково легко сделать сайт с идеальным SEO или сайт, который Google не видит вообще.
Для каждой страницы — что лучше: SSG, ISR, SSR, dynamic. Без правильного выбора Google не индексирует.
Динамическая генерация мета-тегов в App Router, унификация через layout, корректные canonical.
Корректная разделение — RSC для контента, client-components только для интерактива. Минимум JS на странице.
Настройка revalidate-стратегий — каждые N минут или on-demand. Google любит свежий контент.
Динамическая генерация через app/sitemap.ts с правильными приоритетами и lastmod.
next/image и next/font — критично для LCP. Настройка раздельных размеров под мобильные и десктоп.
Один лишний флаг force-dynamic на главной — Google перестаёт кэшировать и индексировать страницу.
Когда разработчики ставят 'use client' в каждом компоненте — JS бандл раздувается до 2-3 МБ, LCP падает в 3 раза.
На страницах /blog/[slug] без generateStaticParams — каждый запрос идёт через сервер, медленно.
Миграция в App Router половинчатая — дубли страниц, конфликт мета-тегов, теряются canonical.
Middleware запускается на КАЖДОМ запросе — даже если он добавляет 50мс, TTFB страдает.
fetch без правильной настройки cache — каждый раз новый запрос. Edge-cache не работает.
Какая страница как рендерится, где SSG, где SSR, где dynamic. Карта стратегий.
Замеры на Vercel Analytics + PageSpeed. Идентификация bottleneck'ов.
Унификация через layout, generateMetadata для динамических, JSON-LD.
Динамические app/sitemap.ts, robots.ts, корректные альтернейты.
Оптимизация client-bundle, dynamic imports, font/image оптимизация.
Google Indexing API для свежего контента, Search Console, отчёт раз в месяц.
Это главный вопрос на любом современном фреймворке. Всё остальное — мета-теги, разметка, скорость — решается после него.
| Режим | Что видит поисковик | Когда подходит |
|---|---|---|
| Статическая генерация | Готовый HTML со всем содержимым — лучший вариант для индексации | Контент меняется нечасто: услуги, статьи, каталог без частых обновлений цен |
| Серверный рендеринг | Готовый HTML, собранный на каждый запрос | Данные меняются часто: наличие, цены, персонализация |
| Клиентский рендеринг | Пустую страницу, содержимое появляется после выполнения скриптов | Личные кабинеты и внутренние интерфейсы — то, что и не должно индексироваться |
| Смешанный режим | Зависит от того, какая часть страницы отдаётся сразу | Каталог со статичными карточками и динамическими блоками |
Частая ошибка — клиентский рендеринг на страницах, которые должны приводить людей из поиска. Проверяется просто: откройте исходный код страницы и поищите в нём свой текст. Если его там нет, поисковик тоже может его не увидеть.
На современных стеках любая SEO-стратегия начинается с правильного рендеринга и индексации. Без этого остальное не работает.
LCP, INP, CLS — три метрики, по которым Google оценивает реальный UX. На SSG/SSR стеках их легко вытянуть в зелёную зону.
Работаем напрямую с вашими разработчиками — фиксим то что нельзя сделать через инструменты SEO.
Не «настроили и забыли» — следим за индексацией, скоростью и позициями постоянно, отчёт присылаем раз в месяц.
Сопровождение — от 100 000 ₽ в месяц, как и на любой другой платформе: цена зависит от объёма работ, а не от стека. Точную сумму называем после бесплатного разбора за 1–2 дня. Работаем от 6 месяцев, гарантий позиций не даём. Отдельная оговорка для этих стеков: часть правок внедряет ваш разработчик, и его время в нашу стоимость не входит — на разборе сразу говорим, какой объём работы ляжет на команду разработки.
30 минут со старшим стратегом. Посмотрим кодовую базу, индексацию и Core Web Vitals, дадим реалистичный план работ.