Jedną z głównych decyzji SEO w Next.js jest sposób renderowania każdej trasy. Część crawlerów wykonuje JavaScript, a inne mogą polegać głównie na pierwotnej odpowiedzi HTML. Kluczowa treść w tej odpowiedzi ogranicza zależność od możliwości konkretnego crawlera.
Praktyczna zasada:
- Statyka (SSG) — strony marketingowe, dokumentacja, blog. Najszybsze, najtańsze, w pełni indeksowalne.
- ISR (Incremental Static Regeneration) — katalogi, listingi, wszystko co zmienia się co godzinę/dzień. Prędkość statyki z kontrolowaną świeżością.
- SSR (renderowanie dynamiczne) — strony personalizowane lub naprawdę real-time. Indeksowalne, ale wolniejszy TTFB.
- CSR (tylko klient) — dashboardy i wnętrze aplikacji. Nigdy dla treści, które mają być indeksowane.
// app/blog/[slug]/page.tsx — ISR: statyczny HTML, regeneracja co godzinę
export const revalidate = 3600;
export async function generateStaticParams() {
const posts = await getPosts();
return posts.map((post) => ({ slug: post.slug }));
}
Sprawdzaj, co dostaje crawler — a nie co pokazuje twoja przeglądarka:
curl -s https://example.com/twoja-strona | grep -i "kluczowa-fraza"
Jeśli kluczowej treści nie ma w tej odpowiedzi, crawlery, które nie renderują strony, mogą ją pominąć.
Uważaj na przypadkowe renderowanie dynamiczne. Użycie cookies(), headers() lub searchParams na stronie po cichu przełącza ją na SSR. To nie jest zabójcze dla SEO, ale kosztuje TTFB i obciążenie serwera. Te pułapki opisaliśmy szczegółowo w artykule Jak działa cache w Next.js z App Routerem.
Checklista:
- Każda indeksowalna trasa to SSG lub ISR; SSR tylko tam, gdzie wymaga tego personalizacja
-
curlpo surowym HTML potwierdza obecność głównej treści - Brak wywołań
cookies()/headers()na stronach, które powinny być statyczne - Komponenty klienckie służą interaktywności, nie treści