TL;DR: JavaScript-frameworks breken standaard je SEO. Client-side rendering betekent dat zoekmachines een lege schil zien — en AI-crawlers voeren helemaal geen JavaScript uit. Next.js (met Server Components en de Metadata API) is op dit moment de beste optie voor SEO. Nuxt komt op een goede tweede plek voor Vue-teams. Gewone React SPA's mag je nooit gebruiken voor pagina's die je geïndexeerd wilt hebben. Deze gids bevat de exacte code, de exacte fouten en de exacte oplossingen. Geen vaag gepraat.
De regel: Als een URL moet ranken in zoekresultaten of geciteerd moet worden door AI, moet de volledige HTML al in de initiële response staan. Dat is het. "Maar Google kan JavaScript renderen" — ja, uiteindelijk, onbetrouwbaar, na een wachtrij die dagen kan duren, op infrastructuur die Google tegen enorme kosten draait, specifiek omdat zoveel developers lege HTML-schillen verschepen en verwachten dat de zoekmachine het renderwerk voor ze doet. En AI-crawlers proberen het niet eens.
ISR is... even een stapje terug. Ik dacht altijd dat ISR in de meeste gevallen een duidelijke winnaar was ten opzichte van SSR. Nadat ik revalidation-bugs heb gezien die wekenlang verouderde content lieten staan op een paar klantsites, ben ik minder zeker. Op de e-commerce site van één klant serveerden ISR-pagina's 6 uur lang verouderde prijzen omdat de revalidation stilletjes faalde — geen fout in de logs, geen alert, gewoon verkeerde prijzen aan klanten én crawlers getoond. ISR is uitstekend als het werkt. Als het niet werkt, is het debuggen van verouderde cache-problemen echt pijnlijk. SSR is voorspelbaarder, ook al is het langzamer.
Next.js krijgt het langste deel omdat het dat verdient. Het is het populairste React-framework, en sinds de App Router de standaard werd in Next.js 13+ is het het beste JavaScript-framework voor SEO geworden. Niet een beetje — aanzienlijk beter dan de alternatieven.
Als je in 2026 een nieuw project bouwt en SEO belangrijk is, gebruik Next.js met de App Router. Dat is de aanbeveling. De rest van dit deel legt uit waarom.
Next.js heeft twee routingsystemen. De App Router (geïntroduceerd in Next.js 13, stabiel in 14+) en de oudere Pages Router. Beide kunnen goede SEO-resultaten opleveren, maar de App Router is op vrijwel alle punten die ertoe doen voor zoekmachines beter:
'use client' toevoegt. Minder JavaScript verstuurd betekent snellere pagina's en volledige HTML voor crawlers.De Pages Router werkt nog prima. Als je een grote bestaande codebase erop draait, hoef je niet in paniek te migreren.
Maar voor nieuwe projecten? App Router, zonder twijfel.
Vóór de App Router betekende Next.js SEO dat je next-seo installeerde en handmatig meta tags aan elkaar knoopte. De Metadata API — die ik eigenlijk een van de beste dingen van de App Router vind, ondanks mijn klachten over de migratiepijn — regelt dit als eersteklas framework-feature.
Statische metadata voor een pagina:
// app/about/page.tsx
import { Metadata } from 'next'
export const metadata: Metadata = {
title: 'About Us | Your Company',
description: 'We build tools that make SEO automatic.',
openGraph: {
title: 'About Us',
description: 'We build tools that make SEO automatic.',
type: 'website',
},
alternates: {
canonical: 'https://example.com/about',
},
robots: {
index: true,
follow: true,
},
}Dynamische metadata voor pagina's met parameters (blogposts, producten, etc.):
// app/blog/[slug]/page.tsx
import { Metadata } from 'next'
type Props = { params: { slug: string } }
export async function generateMetadata({ params }: Props): Promise<Metadata> {
const post = await getPost(params.slug)
return {
title: `${post.title} | Your Blog`,
description: post.excerpt,
openGraph: {
title: post.title,
description: post.excerpt,
type: 'article',
publishedTime: post.publishedAt,
authors: [post.author.name],
images: [{ url: post.ogImage, width: 1200, height: 630 }],
},
alternates: {
canonical: `https://example.com/blog/${params.slug}`,
},
}
}
export default async function BlogPost({ params }: Props) {
const post = await getPost(params.slug)
return (
<article>
<h1>{post.title}</h1>
<p>{post.content}</p>
</article>
)
}Dit is een Server Component. Geen 'use client'-directive. Het draait volledig op de server. De HTML die Googlebot bereikt bevat de volledige artikelinhoud en alle meta tags. Nul JavaScript-rendering nodig.
Veelgemaakte fout die ik constant tegenkom: developers stoppen hun data fetching in een 'use client'-component, waardoor de content via JavaScript laadt nadat de initiële HTML is verstuurd. Googlebot krijgt een lege pagina. Serieus. Verplaats je data fetching naar Server Components of generateMetadata. En als je niet zeker weet of een component server of client is, check op de 'use client'-directive bovenaan het bestand — als die er staat, zit niets in die component-tree in de initiële HTML-response.
De Next.js App Router heeft native sitemap-ondersteuning. Maak app/sitemap.ts aan en het genereert automatisch op /sitemap.xml:
// app/sitemap.ts
import { MetadataRoute } from 'next'
export default async function sitemap(): MetadataRoute.Sitemap {
const posts = await getAllPosts()
const products = await getAllProducts()
const postEntries = posts.map((post) => ({
url: `https://example.com/blog/${post.slug}`,
lastModified: new Date(post.updatedAt),
changeFrequency: 'weekly' as const,
priority: 0.7,
}))
const productEntries = products.map((product) => ({
url: `https://example.com/products/${product.slug}`,
lastModified: new Date(product.updatedAt),
changeFrequency: 'daily' as const,
priority: 0.8,
}))
return [
{
url: 'https://example.com',
lastModified: new Date(),
changeFrequency: 'daily',
priority: 1,
},
...postEntries,
...productEntries,
]
}Voor sites met meer dan 50.000 URL's gebruik je generateSitemaps() om meerdere sitemap-bestanden te maken. Google's limiet is 50.000 URL's per sitemap-bestand.
Zelfde patroon. Maak app/robots.ts aan:
// app/robots.ts
import { MetadataRoute } from 'next'
export default function robots(): MetadataRoute.Robots {
return {
rules: [
{
userAgent: '*',
allow: '/',
disallow: ['/api/', '/dashboard/', '/admin/'],
},
],
sitemap: 'https://example.com/sitemap.xml',
}
}Next.js kan Open Graph-afbeeldingen on-the-fly genereren met next/og (gebouwd op Vercel's Satori-bibliotheek). Dit is handig — in plaats van handmatig OG-afbeeldingen te maken voor elke blogpost, definieer je een template en het rendert bij elke request:
// app/blog/[slug]/opengraph-image.tsx
import { ImageResponse } from 'next/og'
export const size = { width: 1200, height: 630 }
export const contentType = 'image/png'
export default async function Image({
params,
}: {
params: { slug: string }
}) {
const post = await getPost(params.slug)
return new ImageResponse(
(
<div style={{
display: 'flex',
flexDirection: 'column',
justifyContent: 'center',
padding: '60px',
background: 'white',
width: '100%',
height: '100%',
}}>
<h1 style={{ fontSize: 48, fontWeight: 700 }}>
{post.title}
</h1>
<p style={{ fontSize: 24, color: '#666' }}>
{post.excerpt}
</p>
</div>
),
{ ...size }
)
}Next.js zet automatisch de og:image meta tag op deze gegenereerde afbeelding. Geen handmatig bedradingswerk nodig.
Het next/image-component regelt lazy loading, automatische WebP/AVIF-conversie, responsieve formaten en voorkomt layout shift (CLS). Dit alles heeft directe invloed op Core Web Vitals, die Google als ranking-signaal gebruikt.
import Image from 'next/image'
// Dit doet automatisch:
// - Genereert WebP/AVIF-varianten
// - Lazy loading voor afbeeldingen buiten het zichtbare scherm
// - Stelt width/height in om CLS te voorkomen
// - Serveert responsieve formaten
<Image
src="/hero.jpg"
alt="Product screenshot showing the dashboard"
width={1200}
height={630}
priority // Above-the-fold: schakel lazy loading uit
/>Twee dingen die developers consequent fout doen: ze vergeten priority op de LCP-afbeelding (je grootste above-the-fold afbeelding), en ze gebruiken gewone <img>-tags in plaats van next/image. Beide schaden je Core Web Vitals.
Voeg JSON-LD structured data rechtstreeks toe in je Server Components. Geen third-party package nodig:
// app/blog/[slug]/page.tsx
export default async function BlogPost({ params }) {
const post = await getPost(params.slug)
const jsonLd = {
'@context': 'https://schema.org',
'@type': 'Article',
headline: post.title,
description: post.excerpt,
datePublished: post.publishedAt,
dateModified: post.updatedAt,
author: {
'@type': 'Person',
name: post.author.name,
},
image: post.ogImage,
}
return (
<>
<script
type="application/ld+json"
// In Next.js Server Components is dit veilig —
// de JSON wordt server-side gegenereerd vanuit je eigen database
{...{ children: JSON.stringify(jsonLd) }}
/>
<article>
<h1>{post.title}</h1>
<p>{post.content}</p>
</article>
</>
)
}Ik zie deze op bijna elke Next.js-site die ik audit. Stuk voor stuk kosten ze je rankings.
'use client'-componenten — Je content laadt pas nadat JavaScript draait. Googlebot ziet een lege laadspinner. Verplaats data fetching naar Server Components./blog/my-post en /blog/my-post?ref=twitter allebei geïndexeerd hebt, verdeel je autoriteit. Stel alternates.canonical in bij je metadata.metadata-export. Dynamische pagina's hebben generateMetadata nodig. Ik heb sites gezien met perfecte metadata op de homepage en <title>undefined</title> op elke productpagina.loading.tsx gebruiken voor kritieke content — Het loading-bestand toont een skeleton terwijl content binnenstroomt. Googlebot kan het skeleton indexeren in plaats van de daadwerkelijke content. Gebruik loading.tsx voor niet-kritieke UI, niet voor de hoofdinhoud van de pagina.router.push() gebruiken voor redirects. Zoekmachines voeren JavaScript-redirects niet betrouwbaar uit. Gebruik next.config.js-redirects of middleware voor server-side 301/302's.Het irriteert me dat ik dit deel moet schrijven. Het is 2026. (Als je in 2026 nog steeds Create React App gebruikt voor een publieke site, moeten we even praten.) Maar de e-mails blijven binnenkomen, dus hier zijn we.
Gebruik geen gewone React SPA voor pagina's die je geïndexeerd wilt hebben. Dat is de hele boodschap. Een gewone React SPA — Create React App, Vite met React, wat dan ook — stuurt een lege HTML-schil naar elke crawler die langskomt. Google rendert het misschien uiteindelijk. AI-crawlers doen het nooit. Gebruik het voor dashboards, adminpanelen, alles achter een login. Gebruik het niet voor content die je in zoekresultaten wilt zien.
Als je vastzit met een React SPA en niet kunt migreren naar Next.js (ik snap het — het overkomt iedereen), hier is de duct tape-aanpak:
// Met react-helmet-async voor meta tags
import { Helmet } from 'react-helmet-async'
function ProductPage({ product }) {
return (
<>
<Helmet>
<title>{product.name} | Your Store</title>
<meta name="description" content={product.description} />
<link rel="canonical"
href={`https://example.com/products/${product.slug}`} />
</Helmet>
<h1>{product.name}</h1>
</>
)
}React Helmet beheert je <head>-tags. Maar — en dit is cruciaal — het draait nog steeds client-side. Googlebot moet nog steeds JavaScript renderen om deze tags te zien. Je hebt een prerendering-service nodig (Prerender.io, Rendertron, of je eigen Puppeteer-setup) om voorgerenderde HTML aan crawlers te serveren.
Dit werkt. Ik heb het zien werken. Maar het is fragiel, voegt latency toe aan crawler-requests, kost geld, en je vecht tegen het framework in plaats van ermee samen te werken.
Als je SPA meer dan 50 pagina's heeft die geïndexeerd moeten worden — en die pagina's dynamische content hebben die wekelijks verandert, wat betekent dat de prerendering-cache constant geïnvalideerd moet worden, wat betekent dat iemand in je team nu crawler-infrastructuur onderhoudt in plaats van productfeatures te bouwen — dan overstijgen de kosten van een prerendering-setup de kosten van migratie naar Next.js. Ik heb die berekeningen gemaakt voor klanten.
Zoals Addy Osmani en Jason Miller documenteerden op web.dev: prerendering voegt doorgaans merkbare server-side latency toe per pagina voor crawler-requests, en edge cases met dynamische content of geauthenticeerde states produceren regelmatig verouderde of incorrecte snapshots. Het is een valide overbruggingsstrategie, geen permanente oplossing (web.dev: Rendering on the Web).
Als je team in het Vue-ecosysteem zit, is Nuxt voor Vue wat Next.js is voor React. Zelfde idee: neem een client-side framework, voeg server rendering, metadata-beheer en file-based routing toe. (Eerlijk gezegd: ik heb veel minder tijd doorgebracht met Nuxt dan met Next.js, dus neem mijn mening hier met een extra korrel zout.) Het SEO-verhaal is sterk — niet helemaal zo gepolijst als Next.js op een paar punten, maar dicht genoeg in de buurt dat het niet de doorslaggevende factor zou moeten zijn bij de keuze tussen de twee ecosystemen.
Nuxt gebruikt universal rendering standaard. Elke pagina wordt server-gerenderd bij de eerste load, daarna gehydrateerd voor client-side navigatie. Je hoeft er niet voor te kiezen. Je moet er juist voor kiezen om het uit te zetten. Dat is de juiste standaard voor SEO.
Nuxt's composable-systeem voor metadata is clean. Twee opties, afhankelijk van hoeveel controle je nodig hebt:
<!-- pages/blog/[slug].vue -->
<script setup>
const route = useRoute()
const { data: post } = await useFetch(`/api/posts/${route.params.slug}`)
// Optie 1: useSeoMeta — type-safe, dekt de gangbare gevallen
useSeoMeta({
title: () => post.value?.title,
description: () => post.value?.excerpt,
ogTitle: () => post.value?.title,
ogDescription: () => post.value?.excerpt,
ogType: 'article',
ogImage: () => post.value?.ogImage,
twitterCard: 'summary_large_image',
})
// Optie 2: useHead — volledige controle over <head>-tags
useHead({
link: [
{
rel: 'canonical',
href: `https://example.com/blog/${route.params.slug}`,
}
],
script: [
{
type: 'application/ld+json',
innerHTML: JSON.stringify({
'@context': 'https://schema.org',
'@type': 'Article',
headline: post.value?.title,
datePublished: post.value?.publishedAt,
}),
},
],
})
</script>
<template>
<article>
<h1>{{ post?.title }}</h1>
<p>{{ post?.content }}</p>
</article>
</template>Ik vind useSeoMeta() echt goed. Het is meer opinionated dan de Metadata API van Next.js, maar dekt 90% van wat je nodig hebt met minder boilerplate. De type safety betekent dat je IDE typo's in meta tag-namen opvangt — iets dat echte bugs heeft veroorzaakt in projecten waar ik aan werkte.
Nuxt's routeRules laten je rendering-strategieën per route mixen. Dit is een gebied waar Nuxt aantoonbaar voorloopt op Next.js qua developer experience:
// nuxt.config.ts
export default defineNuxtConfig({
routeRules: {
'/': { prerender: true }, // SSG — homepage
'/blog/**': { isr: 3600 }, // ISR — elk uur revalideren
'/products/**': { ssr: true }, // SSR — altijd vers
'/dashboard/**': { ssr: false }, // CSR — geauthenticeerde pagina's
'/docs/**': { prerender: true }, // SSG — documentatie
}
})Eén config-object, vijf verschillende rendering-strategieën. Met Next.js zou je export const dynamic = 'force-static' of export const revalidate = 3600 op elk individueel paginabestand moeten zetten. (Eigenlijk is dat niet helemaal eerlijk — Next.js middleware kan dit gedeeltelijk ook centraal afhandelen. Maar Nuxt's aanpak is er explicieter over.) (Dit doet me denken aan het debuggen van Gatsby's GraphQL-laag om 2 uur 's nachts — sommige frameworks optimaliseren voor developer experience ten koste van developer sanity.) Nuxt's aanpak schaalt beter als je duidelijke patronen per route hebt.
Nuxt heeft geen ingebouwde sitemap-generatie zoals Next.js. Je hebt de @nuxtjs/sitemap-module nodig (die officieel onderhouden en goed ondersteund wordt):
// nuxt.config.ts
export default defineNuxtConfig({
modules: ['@nuxtjs/sitemap'],
sitemap: {
sources: ['/api/__sitemap__/urls'],
exclude: ['/dashboard/**', '/admin/**'],
},
site: {
url: 'https://example.com',
},
})De module ontdekt automatisch je statische pagina's via de file-based routing. Voor dynamische pagina's (blogposts, producten) geef je een API-endpoint op dat de URL-lijst retourneert. Sitemap-indexbestanden worden automatisch gegenereerd als je meer dan 50.000 URL's hebt.
Als je een blog of documentatiesite bouwt met Nuxt, is de @nuxt/content-module het kennen waard. Het leest Markdown/MDX-bestanden uit een content/-directory, genereert pagina's met volledige SSG-ondersteuning en heeft ingebouwde zoekfunctionaliteit. Voor SEO is het kernvoordeel dat elke contentpagina als statische HTML wordt voorgerenderd — de snelst mogelijke levering aan zoekmachines.
Oplossing: Render je kritieke content server-side. Als je laadstates moet gebruiken, zorg dan dat ze alleen verschijnen voor niet-kritieke UI-elementen. Controleer: schakel JavaScript uit in Chrome DevTools (Instellingen > Debugger > JavaScript uitschakelen), herlaad de pagina. Wat je ziet is wat de meeste crawlers zien. Als je een spinner ziet, ziet Google die ook.
JSON-LD structured data helpt zoekmachines te begrijpen waar je pagina over gaat. Productpagina's zonder Product-schema. Blogposts zonder Article-schema. FAQ-pagina's zonder FAQPage-schema. Elk ontbrekend schematype is een gemiste kans op rich results.
Oplossing: Voeg JSON-LD toe aan elk paginatype. Controleer: draai Google's Rich Results Test op elk paginatype. Zowel Next.js als Nuxt maken dit eenvoudig — zie de codevoorbeelden hierboven. Of laat SEOJuice het automatisch afhandelen.
JavaScript gebruiken (window.location.href, router.push(), navigateTo()) voor redirects in plaats van server-side 301/302's. Zoekmachines volgen JavaScript-redirects niet betrouwbaar. Link equity wordt niet overgedragen. Pagina's die samengevoegd moeten worden, blijven opgesplitst.
Oplossing: Gebruik server-side redirects. In Next.js configureer je ze in next.config.js of gebruik middleware. In Nuxt gebruik je routeRules-redirects. Controleer: curl -I https://your-site.com/old-url — je zou een 301- of 302-statuscode moeten zien met een Location-header. Als je 200 OK ziet, is de redirect alleen client-side.
Dit is de nieuwe. Zelfs als je SSR-setup perfect is voor Googlebot, check of je robots.txt AI-crawlers blokkeert. Sommige CDN-providers (vooral Cloudflare met zijn "AI Bot"-toggle) blokkeren GPTBot en soortgelijke crawlers standaard. Als je zichtbaarheid in AI-zoekmachines wilt, zorg dan dat ze bij je content kunnen. Controleer: curl https://your-site.com/robots.txt en zoek naar GPTBot, ClaudeBot, PerplexityBot. Als ze geblokkeerd zijn en jij hebt dat niet ingesteld, dan heeft je CDN het gedaan.
En één laatste check die alles hierboven afdekt: klik rechts op een willekeurige pagina, Paginabron bekijken. Als je content in de ruwe HTML staat, werkt server rendering. Als je een lege <div id="root"></div> ziet, werkt het niet. Draai ook de Lighthouse SEO-audit — mik op 100, het is haalbaar met server rendering. Zoals Jason Miller en Addy Osmani schreven op web.dev: rendering-strategieën hebben echte trade-offs, en je kunt het je niet veroorloven om aan te nemen dat je JavaScript correct wordt uitgevoerd door elke crawler (web.dev: Rendering on the Web).
JavaScript-frameworks en SEO hebben een ingewikkelde geschiedenis. Jarenlang was het advies "gebruik gewoon server-side rendering" en dat was het zo'n beetje. Nu is het beeld genuanceerder, maar ook beter oplosbaar.
Next.js met de App Router is de beste optie voor de meeste teams in 2026. Server Components zorgen ervoor dat je pagina's standaard server-gerenderd worden, de Metadata API is type-safe en uitgebreid, en het ecosysteem is volwassen. Als je in het Vue-ecosysteem zit, geeft Nuxt je dezelfde kernvoordelen met een net iets andere API.
Gewone React SPA's horen niet op publieke pagina's. Ik ben het zat om React SPA's op marketingsites te zien. Het is 2026. We zouden het beter moeten weten. En dit gaat niet veranderen — als er iets verandert, maakt de opkomst van AI-crawlers die geen JavaScript uitvoeren het juist moeilijker, niet makkelijker.
Eén ding waar ik oprecht onzeker over ben: de langetermijnkoers van Remix versus Next.js voor SEO. Remix' filosofie van "alleen SSR, geen caching-laag" is aantrekkelijk in zijn eenvoud. Naarmate edge computing goedkoper wordt, verzwakt het argument voor ISR (Next.js' middenweg). Ik zou niet tegen Remix wedden in 2027. Maar vandaag heeft Next.js meer ingebouwde SEO-features, een groter ecosysteem en betere documentatie. Gebruik wat nu je probleem oplost.
Als dit allemaal klinkt als heel veel configuratie om goed te krijgen — dat is het ook. Daarom bestaat SEOJuice: jij kiest de rendering-strategie, wij automatiseren de rest.
Ja, maar met kanttekeningen. Google gebruikt de Web Rendering Service (een evergreen Chromium) om JavaScript uit te voeren. De rendering vindt plaats in een tweede ronde — na de initiële crawl — en kan variëren van seconden tot dagen. Voor gevestigde sites met een hoog crawl budget is het meestal snel. Voor nieuwe sites of sites met weinig autoriteit kan de vertraging aanzienlijk zijn. En cruciaal: Google's rendering is niet gegarandeerd. Pagina's die afhankelijk zijn van complexe JavaScript-interacties, authenticatie vereisen, of rendering-fouten bevatten, worden mogelijk nooit volledig gerenderd. De veiligste aanpak is altijd om volledige HTML te serveren in de initiële response.
Kies op basis van of je team Vue of React schrijft, niet op basis van SEO-verschillen.
De snelste route: voeg Prerender.io of een vergelijkbare prerendering-service toe als middleware. Dit onderschept crawler-requests en serveert voorgerenderde HTML. Het opzetten kost ongeveer een uur en maakt je content direct zichtbaar voor zoekmachines. Plan daarna een geleidelijke migratie naar Next.js — de App Router kan naast bestaande pagina's bestaan, dus je kunt route voor route migreren in plaats van een big-bang herschrijving. Begin met je pagina's met het meeste verkeer.
no credit card required
No related articles found.