Een van de belangrijkste SEO-beslissingen in Next.js is hoe je elke route rendert. Sommige crawlers voeren JavaScript uit, andere leunen vooral op het eerste HTML-antwoord. Staat de kerncontent in dat antwoord, dan ben je minder afhankelijk van wat een bepaalde crawler kan.
De praktische vuistregel:
- Statisch (SSG): marketingpagina's, documentatie, blog. Het snelst, het goedkoopst, volledig indexeerbaar.
- ISR (Incremental Static Regeneration): catalogi, overzichten, alles wat elk uur of elke dag verandert. De snelheid van statisch met gecontroleerde versheid.
- SSR (dynamisch renderen): gepersonaliseerde of echt realtime pagina's. Indexeerbaar, maar met een tragere TTFB.
- CSR (alleen client): dashboards en het binnenste van een app. Nooit voor content die geïndexeerd moet worden.
// app/blog/[slug]/page.tsx — ISR: statische HTML, elk uur opnieuw gegenereerd
export const revalidate = 3600;
export async function generateStaticParams() {
const posts = await getPosts();
return posts.map((post) => ({ slug: post.slug }));
}
Controleer wat de crawler krijgt, niet wat je browser toont:
curl -s https://example.com/jouw-pagina | grep -i "kernzin"
Staat de kerncontent niet in dat antwoord, dan kunnen crawlers die de pagina niet renderen haar overslaan.
Pas op voor onbedoeld dynamisch renderen. Het gebruik van cookies(), headers() of searchParams op een pagina schakelt die stilletjes over naar SSR. Dat is niet dodelijk voor SEO, maar het kost TTFB en serverbelasting. Deze valkuilen hebben we uitgebreid beschreven in het artikel Hoe de cache in Next.js met de App Router werkt.
Checklist:
- Elke indexeerbare route is SSG of ISR; SSR alleen waar personalisatie dat vereist
-
curlop de ruwe HTML bevestigt dat de hoofdcontent aanwezig is - Geen aanroepen van
cookies()/headers()op pagina's die statisch moeten zijn - Clientcomponenten dienen voor interactiviteit, niet voor content