Самое важное SEO-решение в Next.js — как рендерится каждый роут. Google умеет исполнять JavaScript, но рендеринг ставится в очередь, откладывается и не гарантирован — а большинство остальных краулеров (Bing частично, и почти все AI-краулеры) индексируют только исходный HTML-ответ.
Базовое правило:
- Статика (SSG) — маркетинговые страницы, документация, блог. Быстрее и дешевле всего, полностью индексируется.
- ISR (Incremental Static Regeneration) — каталоги, списки, всё, что меняется раз в час/день. Скорость статики с контролируемой свежестью.
- SSR (динамический рендеринг) — персонализированные и по-настоящему realtime-страницы. Индексируется, но TTFB медленнее.
- CSR (только клиент) — дашборды и внутренности приложения. Никогда — для контента, который должен индексироваться.
// app/blog/[slug]/page.tsx — ISR: статический HTML, перегенерация раз в час
export const revalidate = 3600;
export async function generateStaticParams() {
const posts = await getPosts();
return posts.map((post) => ({ slug: post.slug }));
}
Проверяйте, что получает краулер, а не что показывает ваш браузер:
curl -s https://example.com/your-page | grep -i "ключевая-фраза"
Если ключевого контента нет в этом ответе — для большинства краулеров его не существует.
Остерегайтесь случайного динамического рендеринга. Вызов cookies(), headers() или searchParams на странице молча переключает её в SSR. Для SEO это не фатально, но стоит вам TTFB и нагрузки на сервер. Эти ловушки мы подробно разобрали в статье Как работает кеширование в Next.js с App Router.
Чеклист:
- Каждый индексируемый роут — SSG или ISR; SSR только там, где нужна персонализация
-
curlпо «сырому» HTML подтверждает наличие основного контента - Нет вызовов
cookies()/headers()на страницах, которые должны быть статическими - Клиентские компоненты — для интерактива, а не для контента