SPA-SEO in 2026: Een HTML-First veldgids voor Next.js, Nuxt, SvelteKit en Astro

TL;DR: Single-page-applicaties kunnen ranken, maar alleen als URL’s, status­codes, metadata en primaire content al in de eerste HTML-response aanwezig zijn. Google kan JavaScript pas later renderen; de meeste AI-crawlers renderen het helemaal niet. Kies per route een render­model, verstuur eerst het document en pas daarna de app-state, en laat JavaScript daarna hydrateren. Hieronder: een field-guide voor 2026 voor teams die met Next.js, Nuxt, SvelteKit en Astro werken.

Stop met vragen of Google “JavaScript ondersteunt”

De openings­vraag voor SPA-SEO is niet langer “kan Googlebot JavaScript renderen”. Ja, dat kan. Martin Splitt roept dat al jaren. Toch debuggen mensen nog steeds single-page-apps door naar view-source: te staren alsof dát de pagina is die Google indexeert.

“Veel mensen kijken nog steeds naar view source. Dat is niet wat wij gebruiken voor indexatie. Wij gebruiken de gerenderde HTML.”

Martin Splitt, Developer Advocate bij Google

Dat rekent af met één slechte gewoonte. Als je alleen de initiële bron van een React-, Vue-, Angular-, SvelteKit-, Nuxt-, Remix- of Next.js-app bekijkt, mis je wat Google uiteindelijk ziet. De gerenderde DOM telt.

Maar de vraag voor 2026 is niet of Google kan renderen. Het is of het document snel genoeg arriveert om nuttig te zijn voor Googlebot, social parsers en de AI-crawlers die steeds vaker het citaat­netwerk domineren.

De AI-crawler-kloof veranderde de rekensom

Jarenlang zag ik dit als een Google-probleem (ik had het jarenlang mis). Toen kwamen AI-crawlers met een andere houding.

“De resultaten laten consequent zien dat geen van de grote AI-crawlers momenteel JavaScript rendert.”

Vercel Engineering

GPTBot, ClaudeBot, PerplexityBot, de Gemini-training­fetch — ze halen allemaal ruwe HTML op. Als je belangrijkste content pas na hydratatie verschijnt, zien die crawlers een lege app-shell waar jouw prijstabel, productcopy, FAQ of vergelijkings­content hoort te staan. Draai onze AI Crawler Inspector op een paar SPA-pagina’s en je ziet wat zij zien.

Classificeer routes voordat je het render-probleem classificeert

De meeste teams slaan deze stap over en vragen of de hele SPA SSR nodig heeft. Die vraagstelling verspilt engineer­ing­tijd.

Een echte SPA mixt twee dingen: crawlbare pagina’s en private app-states. Pricing-pagina’s, blogposts, documentatie, templates, integraties, vergelijking-pagina’s en product-landings­pagina’s zijn pagina’s. Dashboards, onboarding­flows, modals, filters, account­schermen en opgeslagen rapporten zijn app-states.

Begin met classificeren. Vraag engineers niet om “SEO voor de app te fixen”. Vraag ze aan te geven welke routes zoek­verkeer verdienen, en kies daarna per route rendering, indexatie, canonicals en status­codes.

Routetype	Moet ranken?	Renderkeuze	Indexregel
Blogpost	Ja	SSG of SSR	Index, self-canonical
Product-landings­pagina	Ja	SSG of SSR	Index, self-canonical
Interne zoek­resultaten	Meestal niet	CSR of SSR	Vaak noindex
Dashboard-route	Nee	CSR is prima	Achter auth of noindex
Gefacetteerde filter-URL	Soms	SSR alleen als gecureerd	Canonical of noindex

Een SPA met 40 publieke URL’s en 4.000 dashboard-states heeft geen 4.040 SEO-pagina’s. Ze heeft 40 pagina’s en een product­interface. Publieke routes hebben stabiele URL’s, self-canonicals, server-delivered metadata, crawlbare links, bruikbare first-byte HTML en correcte status­codes nodig. Dashboard-routes hebben snelle interactie, auth en state-management nodig. Beide in één render­model persen maakt meestal allebei slechter.

Kies het render-model per route, niet per app

Render­strategie is een architectuur­keuze, geen plug-in-instelling. Kies je het verkeerde model, dan wordt elk later ticket een workaround.

CSR: prima voor dashboards, riskant voor landing-pagina’s

Client-side rendering is perfect voor geauthenticeerde software­schermen. Moet een gebruiker inloggen, dan hoeft een crawler de route toch niet te indexeren. CSR wordt riskant wanneer dezelfde app-shell pricing-pagina’s, docs, artikelen en product­pagina’s bedient waar content pas verschijnt nadat JavaScript draait en API’s reageren.

SSG: saai, snel en meestal het juiste antwoord

Static site generation bouwt pagina’s vooraf om naar HTML. Voor blogs, docs, changelogs, glossary-pagina’s, templates en de meeste marketing­content is SSG nauwelijks te verslaan: snel, cachebaar, goedkoop, crawler-vriendelijk. Astro 5 gaat hierin het verst met het islands-model en zero-JS-by-default.

SSR: nuttig wanneer publieke content vaak verandert

Server-side rendering past als publieke content per request varieert op basis van locatie, voorraad, permissies of versheid. Lee Robinson vatte het Next.js-model simpel samen:

“Next.js prerendert de pagina op de server naar HTML bij elke request.”

Lee Robinson, VP Developer Experience bij Vercel

SSR levert crawlers HTML zonder te wachten op de client-bundle en laat de pagina toch verse data tonen.

ISR en PPR: de pragmatische middenweg voor grote sites

Incremental static regeneration ververst statische pagina’s na publicatie. Voor programmatische SEO, docs en grote template-bibliotheken voorkomt ISR rebuild-pijn zonder terug te vallen op volledige CSR. Next.js 15 maakte Partial Prerendering (PPR) stabiel: een statische shell met gestreamde dynamische “gaten” binnen dezelfde route. Dat mengt twee houdingen binnen één URL, dichter bij hoe echte product­pagina’s zich gedragen.

Dynamic rendering: de workaround die mag uitsterven

Dynamic rendering serveert één versie aan crawlers en een andere aan gebruikers. Het kan een legacy SPA redden als een migratie nog niet klaar is, maar ik zou er geen nieuwe zoek­strategie omheen bouwen.

“Ik zou dit zien als een tijdelijke workaround – waar ‘tijdelijk’ een paar jaar kan betekenen – maar wel tijd­gebonden.”

John Mueller, Search Advocate bij Google

Gebruik dynamic rendering als brug. Vervang de brug later door server-rendered of static-first publieke routes.

Framework-details die in 2026 tellen

Het juiste render-model is ook een framework-gesprek. Defaults zijn het afgelopen jaar verschoven en sommige van die verschuivingen veranderen SPA-SEO-beslissingen.

• Next.js 15. React 19 stable, Turbopack dev stable, fetch- en GET-route­handlers standaard niet meer gecachet. Het oudere default-cachegedrag verborg verouderde-content-bugs; de nieuwe defaults dwingen expliciete caching per route. Partial Prerendering (PPR) is de headline-SEO-feature: een statische shell met gestreamde dynamische gaten, zodat product­pagina’s crawler-vriendelijk blijven zonder versheid op te geven. Zie onze Next.js-, React- en Nuxt-SEO-gids voor een diepere walkthrough.
• Nuxt 4. Applicatiecode staat nu standaard in app/. Gescheiden TypeScript-projecten voor app, server, shared en builder reduceren type-bleed die vroeger server-only secrets in client-bundles lekte. Nuxt 4.4 (maart 2026) voegde vue-router v5 en typed layout props toe; kleine wins om route-specifieke metadata schoon te shippen.
• SvelteKit 2 met Svelte 5 runes. Pagina’s worden standaard server-gerenderd; prerendering is opt-in per route. Het mentale model is “elke route is SSR tenzij ik ‘static’ zeg”, het tegenover­gestelde van de SPA-by-default-valkuil. Bundles blijven klein genoeg dat hydratatie de first paint zelden blokkeert.
• Astro 5 (en 6). Zero JavaScript by default, islands-architectuur, multi-framework component-support. Sinds Cloudflare Astro in januari 2026 overnam, is het edge-deployment­verhaal verder aangescherpt. Astro is het makkelijke antwoord voor content-zware SPA’s die alleen op specifieke pagina’s React- of Vue-componenten nodig hebben.

Het framework is minder belangrijk dan de per-route­discipline. Elk van deze vier kan een crawlbare SPA shippen. Alle vier kunnen een onzichtbare shippen als je publieke content achter hydratatie verstopt.

De crawl-traps die indexatie nog steeds breken

De harde SPA-SEO-fouten zijn meestal saai. Geen mysterieuze ranking-penalties, maar delivery-bugs.

De eerste val is de universele shell. Elke URL geeft dezelfde 200-response, dezelfde lege root, dezelfde bundle. De router beslist later of /pricing, /docs/api of /totally-fake-url bestaat. Dat laat crawlers te hard werken en creëert de tweede val: soft 404’s.

“In plaats van met 404 te antwoorden, geeft hij altijd 200 … steeds een pagina gebaseerd op JavaScript-executie.”

Martin Splitt, Developer Advocate bij Google

Ongeldige routes moeten echte 404- of 410-status­codes teruggeven. Een leuke client-side “pagina niet gevonden”-component met 200 verspilt nog steeds crawlbudget en verwart indexatiesignalen.

De derde val is navigatie die crawlers niet kunnen volgen. Buttons, click-handlers en router-events zijn prima voor interactie, maar interne ontdekking heeft anchors met echte href-waarden nodig. Als je belangrijkste pagina’s alleen bereikbaar zijn na een JavaScript-handler, is je crawlability zwakker dan het lijkt.

Metadata is een andere veel­voorkomende fout. Veel SPA’s updaten titels, descriptions, canonicals, robots-tags, Open Graph en schema pas na route-wisseling. Dat werkt visueel in een browser­tab, maar faalt nog steeds voor crawlers, social parsers en AI-bots. Route-specifieke metadata hoort in de terug­gegeven HTML.

Canonicals verdienen een eigen waarschuwing. Ik heb gehydrateerde apps een juiste canonical zien overschrijven met een staging-domein, een root-URL of de vorige route. De bug blijft stil tot duplicate URL’s slecht clusteren of de verkeerde pagina rankt.

Infinite scroll verbergt content achter client-state. Als pagina twee, drie en ouder geen crawlbare URL’s hebben, ontdekken zoek­machines ze mogelijk nooit. Gebruik gepagineerde fallback-URL’s voor belangrijke archieven en categorie-pagina’s.

API-geladen hoofd­content is fragiel. Als de H1, bodycopy, product­details, reviews of interne links API-calls na hydratatie vereisen, heb je meer fail-points. Bottraffic raakt rate-limits. API’s blokkeren onbekende user-agents. Time-outs laten de gerenderde DOM dun.

Wat AI Overviews eigenlijk citeren uit een SPA

Dit is de 2026-wending. Google’s AI Overviews geven antwoorden boven de organische lijst en citeren de bronnen die voor die samenvatting zijn gebruikt. Die citaties zijn de nieuwe top-of-funnel en belonen een specifieke HTML-vorm.

Het citaat­systeem pakt heldere, statische signalen: zichtbare tekst, headings, lijsten, tabellen, semantische HTML die in de eerste response beschikbaar is. Het wacht niet geduldig op hydratatie. Staat je meest quote-bare alinea pas na een useEffect-call, dan ziet een AI Overview die niet.

Drie dingen tellen voor SPA-pagina’s die geciteerd willen worden:

1. HTML-first antwoord­paragrafen. De eerste 300-400 woorden van elke indexeerbare route moeten de hoofd­vraag van de route beantwoorden zonder JavaScript. De meeste AIO-citaten komen uit die eerste secties.
2. Semantische structuur voor lijsten en tabellen. Geordende of bullet-lijsten en HTML-tabellen worden direct in Overviews getrokken. Divs-die-tabellen-spelen niet.
3. Stabiele URL’s die de AI-bot kan refetch-en. AI Overviews controleren geciteerde bronnen opnieuw. Hash-routes, alleen-query-routes en dynamic-rendering-forks maken refetch onbetrouwbaar.

Hetzelfde geldt voor Perplexity-citaten, ChatGPT-browse-antwoorden en Claude’s web-reads. Hun crawlers halen ruwe HTML op; staat het antwoord daar niet, dan wordt de pagina niet geciteerd. Optimizing for AI Overview citations gaat dieper, en onze AIO-impactanalyse verklaart waarom het impression-verlies erger voelt dan de klik­afdracht.

Lever elke indexeerbare route eerst als document

De regel waar ik steeds op terug­kom: als de route zoek­verkeer verdient, moet de eerste response eruitzien als een pagina.

Dat betekent dat elke publieke URL bruikbare HTML teruggeeft met de kern­sinalen al aanwezig:

• Correcte <title>.
• Meta-description.
• Self-refererende canonical.
• Eén duidelijke H1.
• Hoofd­content.
• Crawlbare interne links.
• Structured data waar relevant.
• Juiste statuscode.
• Open Graph- en Twitter-tags als delen belangrijk is.

JavaScript kan daarna componenten hydrateren, elementen personaliseren, events tracken en de ervaring verrijken. Het mag niet nodig zijn om de crawler te laten begrijpen waar de pagina over gaat.

Site­architectuur telt ook. Een publieke route zonder crawlbare links ernaartoe blijft zwak — zelfs als hij server-gerenderd is. Een perfect gerenderd document dat vijf kliks diep ligt achter client-only navigatie presteert niet zoals eentje binnen een helder intern link­systeem.

Test SPA-SEO met gerenderde HTML, niet op hoop

Test je alleen de browser­ervaring, dan test je het happy path. SPA-SEO vraagt lelijkere tests.

1. Fetch de URL met JavaScript uit en check of de content nog logisch is.
2. Inspecteer de URL in Google Search Console en bekijk de gerenderde HTML.
3. Vergelijk initiële HTML met de gerenderde DOM in Chrome DevTools.
4. Test status­codes direct met curl -I https://example.com/missing-route.
5. Crawl de site met één JS-capable crawler en één non-JS crawler.
6. Bevestig dat titles, canonicals, robots-tags, schema en interne links bestaan vóór hydratatie.
7. Check server-logs op bot-hits, geblokkeerde API’s, time-outs en onverwachte redirects.
8. Valideer structured data met Google’s Rich Results Test na rendering.

De ongemakkelijke test is de H1-test. Als Googlebot vijf stappen en twee API-calls nodig heeft om de H1 te vinden, is de pagina fragiel, ook al wordt hij uiteindelijk geïndexeerd. Pas dezelfde test toe op GPTBot, ClaudeBot en PerplexityBot: zien zij de H1 niet in ruwe HTML, dan verschijnt de route niet als AI-citaat.

SPA-SEO-checklist voor 2026

Gebruik deze op routeniveau. Een site-brede “pass” verbergt te veel SPA-fouten.

• Rendering: Publieke pagina’s gebruiken SSG, SSR, ISR of PPR. Private app-screens blijven op CSR.
• Routing: Elke indexeerbare URL heeft een unieke route, unieke content en een self-canonical.
• Status­codes: Missende pagina’s geven 404 of 410, niet 200.
• Links: Interne navigatie gebruikt crawlbare anchors met echte href-attributen.
• Metadata: Titles, descriptions, canonicals, robots-tags, Open Graph en schema zijn route-specifiek en staan in HTML.
• Content: Hoofd­tekst, H1’s, product­info en key-links bestaan zonder client-only data.
• Performance: Bundle-grootte, hydratatie­kosten, third-party scripts en route-level code-splitting zijn onder controle.
• Index-controle: Dashboards, private routes, low-value filters en dunne zoek­pagina’s zijn geblokkeerd of noindexed.
• Testing: Initiële HTML, gerenderde DOM en geïndexeerde content worden vergeleken op belangrijke templates.
• AI-zichtbaarheid: Quote-bare antwoord­paragrafen, lijsten en tabellen staan in ruwe HTML zodat AI Overviews en AI-zoekmachines ze citeren.

Search, AI-antwoorden, link-previews en discovery-systemen hangen allemaal af van toegang. Rankings komen pas daarna.

De simpelste SPA-SEO-architectuur die ik vandaag zou shippen

Als ik nu een moderne SPA met zoek­verkeer voor ogen startte, zou ik niet het hele product server-renderen. Ik zou het splitsen.

Site-onderdeel	Aanbevolen aanpak
Marketing­site	Static generation
Blog en docs	Static generation of ISR
Product­pagina’s	SSR, ISR of Next.js PPR
Programmatische SEO-pagina’s	Static generation met sterke pruning
Dashboard	CSR achter auth
Zoek- en filterpagina’s	Noindex tenzij handmatig gecureerd
Ongeldige routes	Echte 404 of 410
Gedeelde layout	Server-gerenderde metadata en navigatie

Marketing­pagina’s en artikelen moeten HTML-first zijn. Product­oppervlakken die versheid nodig hebben gebruiken SSR, ISR of PPR. Het dashboard blijft app-achtig omdat ranken onzinnig zou zijn. Programmatische SEO-pagina’s vragen beheersing: static generation maakt duizenden pagina’s makkelijk, inclusief duizenden die niemand moet indexeren. Genereer alleen pagina’s met echte zoek­vraag, bruikbare content en interne links. Snoei de rest voordat Google de beslissing voor je neemt.

De winnende SPA is niet degene die bewijst dat crawlers JavaScript kunnen draaien. De winnende SPA is degene die crawlers geen onnodig werk laat doen.

FAQ

Kan een single-page-applicatie in 2026 ranken in Google?

Ja. Een SPA kan ranken als indexeerbare routes crawlbare content, correcte metadata, interne links en geldige status­codes in de eerste HTML-response teruggeven. Google kan JavaScript renderen, maar alles daarop laten leunen maakt de site fragiel en onzichtbaar voor AI-crawlers die helemaal niet renderen.

Is server-side rendering verplicht voor SPA-SEO?

Niet voor elke route. SSR past bij publieke pagina’s met veranderende content. SSG of ISR is vaak beter voor stabiele content. Next.js 15’s Partial Prerendering mengt beide binnen één route. CSR is prima voor private dashboards en app-states die niet geïndexeerd hoeven worden.

Zijn hash-routes slecht voor SEO?

Hash-routes zijn een zwakke keuze voor indexeerbare pagina’s. Ze kunnen werken voor on-page fragmenten, maar publieke content hoort schone URL’s, route-specifieke metadata en status­codes op server­niveau te hebben.

Moeten SPA-zoek­resultaat­pagina’s worden geïndexeerd?

Meestal niet. Interne zoek­pagina’s en gefacetteerde filters creëren vaak dunne of dubbele URL’s. Gecureerde filter­pagina’s kunnen worden geïndexeerd als ze unieke vraag, stabiele content en een duidelijke canonical-strategie hebben.

Hoe weet ik of mijn SPA een soft-404-probleem heeft?

Vraag een nep-URL op en check de status­code. Als /this-page-should-not-exist 200 teruggeeft met een client-side not-found-bericht, heb je een soft-404-risico dat crawlbudget verspilt.

Zal AI Overviews een JavaScript-gerenderde SPA citeren?

Alleen als de geciteerde content in ruwe HTML staat. De meeste AI-crawlers voeren geen JavaScript uit. Server-render of prerender de alinea’s, lijsten en tabellen die je geciteerd wilt hebben.

Hulp nodig om je SPA in crawlbare pagina’s te veranderen?

SEOJuice helpt teams om crawlbare interne links en HTML-first signalen te versterken op publieke pagina’s die zoek­verkeer verdienen. Heeft jouw SPA verweesde routes, begraven templates of pagina’s die Google nooit lijkt te bereiken, dan kan geautomatiseerde interne linking de document­laag toegankelijker maken voor crawlers en AI-bots.

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Kan een single-page-applicatie in 2026 ranken in Google?", "acceptedAnswer": { "@type": "Answer", "text": "Ja. Een SPA kan ranken als indexeerbare routes crawlbare content, correcte metadata, interne links en geldige statuscodes in de eerste HTML-response leveren. Google kan JavaScript renderen, maar alles daarop laten leunen maakt de site fragiel en onzichtbaar voor AI-crawlers die helemaal niet renderen." } }, { "@type": "Question", "name": "Is server-side rendering verplicht voor SPA-SEO?", "acceptedAnswer": { "@type": "Answer", "text": "Niet voor elke route. SSR is geschikt voor publieke pagina's met veranderende content. SSG of ISR is vaak beter voor stabiele content. Next.js 15's Partial Prerendering mengt beide binnen één route. CSR is prima voor private dashboards en app-states die niet geïndexeerd hoeven te worden." } }, { "@type": "Question", "name": "Zijn hash-routes slecht voor SEO?", "acceptedAnswer": { "@type": "Answer", "text": "Hash-routes zijn geen goede keuze voor indexeerbare pagina's. Ze kunnen werken voor on-page fragmenten, maar publieke content hoort schone URL's, route-specifieke metadata en server-side statuscodes te hebben." } }, { "@type": "Question", "name": "Moeten SPA zoekresultaatpagina's worden geïndexeerd?", "acceptedAnswer": { "@type": "Answer", "text": "Meestal niet. Interne zoekpagina's en gefacetteerde filters creëren vaak dunne of dubbele URL's. Gecureerde filterpagina's kunnen worden geïndexeerd als ze unieke vraag, stabiele content en een duidelijke canonical-strategie hebben." } }, { "@type": "Question", "name": "Hoe weet ik of mijn SPA een soft 404-probleem heeft?", "acceptedAnswer": { "@type": "Answer", "text": "Vraag een niet-bestaande URL op en controleer de statuscode. Als /this-page-should-not-exist een 200 retourneert met een client-side not-found-bericht, heb je een soft 404-risico dat crawlbudget verspilt." } }, { "@type": "Question", "name": "Zal AI Overviews een JavaScript-gerenderde SPA citeren?", "acceptedAnswer": { "@type": "Answer", "text": "Alleen als de geciteerde content in ruwe HTML staat. De meeste AI-crawlers voeren geen JavaScript uit. Server-render of prerender dus de alinea's, lijsten en tabellen die je geciteerd wilt zien." } } ] } </script>