Najważniejsza decyzja SEO w Next.js to sposób renderowania każdej trasy. Google potrafi wykonywać JavaScript, ale renderowanie trafia do kolejki, bywa opóźnione i nie jest gwarantowane — a większość pozostałych crawlerów (Bing częściowo, i niemal wszystkie crawlery AI) indeksuje wyłącznie pierwotną odpowiedź HTML.
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, dla większości crawlerów ona nie istnieje.
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