SEO voor single page applications: zo krijg je een SPA geïndexeerd door Google en gelezen door AI

Kort samengevat: een single page application (SPA) laadt één HTML-schil en bouwt elke weergave met JavaScript in de browser op. Google kan JavaScript renderen, maar het renderen is vertraagd en kwetsbaar, en de crawlers achter ChatGPT, Claude en Perplexity voeren het helemaal niet uit. Om te ranken en geciteerd te worden heeft elke weergave van een SPA een eigen URL nodig, een echte link met een href, een unieke titel en beschrijving, een correcte statuscode en vooral de hoofdcontent in de HTML die de server verstuurt, via server-side rendering, statische generatie of prerendering.

SEO voor single page applications is het geheel van technieken waarmee een JavaScript-app die met React, Vue, Angular of Svelte is gebouwd net zo makkelijk te crawlen is als een klassieke website. Het probleem is goed gedocumenteerd: Google legt in zijn basis van JavaScript-SEO uit dat het JavaScript-pagina's in drie fasen verwerkt (crawlen, renderen, indexeren), en elke zwakte van een SPA zit ergens in die pijplijn. Deze gids richt zich op SPA's; lees voor JavaScript-sites in het algemeen onze gids over JavaScript-SEO.

Wat is een single page application en waarom is het lastig voor SEO?

Een traditionele website geeft voor elke URL een compleet HTML-document terug. Een SPA geeft voor elke URL vrijwel hetzelfde document terug: een lege <div id="root">, een paar metatags en een grote JavaScript-bundel. De browser downloadt de bundel, roept een API aan en tekent daarna de pagina. Wanneer de bezoeker op een link klikt, verwisselt JavaScript de content zonder opnieuw te laden.

Voor een mens met een snelle telefoon voelt het resultaat direct aan. Voor een crawler is het eerste antwoord een lege schil: geen kop, geen tekst, geen links. Alles hangt ervan af of de bot het JavaScript uitvoert, en wanneer. Dat ene feit verklaart de meeste SEO-problemen van SPA's:

• Vertraagde of ontbrekende content: de tekst bestaat pas na het renderen, wat Google later uitvoert en andere bots overslaan.
• Eén URL voor veel weergaven: oudere SPA's routeren met fragmenten (/#/pricing), en het deel na de # wordt nooit naar de server gestuurd, waardoor alle weergaven samenvallen tot één URL.
• Identieke titels en beschrijvingen: de schil bevat één <title>, en als de router die niet bijwerkt, delen alle pagina's hem.
• Links zonder href: knoppen en onClick-handlers navigeren voor gebruikers, maar geven crawlers niets om te volgen.
• Soft 404-fouten: de server antwoordt 200 voor elk pad, ook voor pagina's die niet bestaan, waardoor foutweergaven als dunne pagina's worden geïndexeerd.
• Zwaar JavaScript: grote bundels vertragen de eerste weergave en de interacties, wat de Core Web Vitals schaadt.

Hoe crawlt en rendert Google een SPA?

Googlebot haalt eerst de ruwe HTML op en leest de links en instructies die daarin staan. Pagina's die status 200 teruggeven, komen daarna in een wachtrij voor de Web Rendering Service, een headless Chromium. Google stelt dat een pagina “enkele seconden in deze wachtrij kan blijven, maar het kan ook langer duren”. Na het renderen wordt de resulterende HTML opnieuw ontleed op content en links en daarna geïndexeerd.

Vier details uit de documentatie van Google zijn belangrijk voor SPA's:

1. Alleen <a>-elementen met een href zijn betrouwbare links. Links die door JavaScript worden toegevoegd, zijn prima zolang ze dat formaat volgen.
2. Fragmenten zijn geen aparte pagina's. Google vraagt je de History API (pushState) te gebruiken in plaats van #-routes. Het schafte zijn oude AJAX-crawlschema (de #!-URL's) in oktober 2015 af.
3. Een noindex in de oorspronkelijke HTML wint. Google kan het renderen overslaan als het noindex ziet, dus het later met JavaScript verwijderen werkt niet.
4. Renderen gebruikt gecachte bestanden. Googlebot cachet JavaScript en CSS fors, dus gebruik bestandsnamen met vingerafdruk (een contenthash in de bestandsnaam) om verouderde bundels te vermijden.

Het praktische gevolg: Google kan een SPA met rendering aan de clientzijde indexeren, maar je voegt aan elke pagina een tweede stap, een vertraging en een faalpunt toe. Een time-out, een geblokkeerde API-aanroep of een JavaScript-fout tijdens het renderen laat de geïndexeerde versie leeg. Controleer wat Google ziet met de URL-inspectietool in Search Console, en lees onze gids over hoe indexering door Google werkt als pagina's buiten de index blijven.

Lezen ChatGPT, Claude en Perplexity JavaScript?

Meestal niet. In een studie die in december 2024 werd gepubliceerd over het verkeer van zijn netwerk, vonden Vercel en MERJ dat “geen van de grote AI-crawlers momenteel JavaScript rendert”: GPTBot, OAI-SearchBot en ChatGPT-User (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Meta-ExternalAgent en Bytespider lezen allemaal alleen de ruwe HTML. Ze downloaden wel JavaScript-bestanden (ongeveer 11,5% van de verzoeken van ChatGPT en 23,8% van die van Claude) maar voeren ze niet uit. De uitzonderingen zijn Gemini, dat steunt op de renderinfrastructuur van Google, en AppleBot, dat een crawler op basis van een browser gebruikt.

Voor een SPA met rendering aan de clientzijde betekent dit dat de AI-crawlers die ChatGPT, Claude en Perplexity voeden een lege pagina zien. Je product kan op Google ranken en toch onzichtbaar zijn in AI-antwoorden, omdat de assistent er geen woord van heeft gelezen. Hetzelfde geldt voor de meeste bots voor linkvoorbeelden op sociale netwerken en berichtenapps, die de Open Graph-tags in de ruwe HTML lezen. Controleer zodra de content in de HTML staat ook of je robots.txt de AI-crawlers toestaat die je wilt.

Welke renderingstrategie moet een SPA gebruiken?

De oplossing is echte HTML te versturen in het eerste antwoord. Google noemt dynamic rendering (alleen aan bots een geprerenderde versie serveren) “een noodoplossing en geen aanbevolen oplossing” in zijn documentatie over dynamic rendering en verwijst in plaats daarvan naar server-side rendering, statische rendering of hydratatie. De onderstaande definities volgen het naslagwerk Rendering on the Web van web.dev.

De meeste moderne frameworks laten je strategieën per route mengen: statisch voor marketingpagina's, server-side gerenderd voor de catalogus, aan de clientzijde gerenderd voor de app met inlog. Die hybride opzet geeft crawlers volledige HTML waar het zoekverkeer zit en behoudt de SPA-ervaring waar die waarde toevoegt.

Opties per framework

Sites die door AI-websitebouwers zijn gegenereerd verdienen een aparte vermelding: veel exporteren een React-app met rendering aan de clientzijde. Als je je site met een van deze bouwers hebt gemaakt, zie dan onze notities over SEO en GEO voor Lovable voordat je aanneemt dat Google en ChatGPT hem kunnen lezen.

SEO-checklist voor SPA's: wat je route voor route moet herstellen

1. Geef elke weergave een schone, crawlbare URL

Gebruik de History API (/pricing, nooit /#/pricing), één URL per stuk content en dezelfde URL, of de bezoeker nu rechtstreeks komt of via navigatie in de app. Elke URL moet de juiste content laden wanneer je hem in een nieuw tabblad opent, wat de test is die een crawler uitvoert.

2. Gebruik echte links

Elk navigatie-element dat naar een indexeerbare pagina leidt, moet een <a href="/path"> zijn. Linkcomponenten van frameworks (Link, NuxtLink, routerLink) geven deze markup af; eigen klikhandlers op div- of button-elementen doen dat niet. Goede links dragen ook je sitearchitectuur: als een pagina niet is gelinkt, vinden crawlers hem zelden.

3. Werk titel, beschrijving en canonical per route bij

Elke route heeft een eigen titel, metabeschrijving, canonical en Open Graph-tags nodig, waar mogelijk op de server gegenereerd. Onze pagina over metatags somt op wat je moet instellen. Houd één canonical tag aan: Google raadt aan hem in de HTML in te stellen, en als JavaScript hem wijzigt, mag het resultaat de oorspronkelijke niet tegenspreken.

4. Geef eerlijke statuscodes terug

Ontbrekende producten en verwijderde artikelen mogen niet met 200 en een foutmelding antwoorden. Geef met SSR een echte 404 of 410 terug vanaf de server. In een pure SPA accepteert Google twee terugvalopties: met JavaScript doorverwijzen naar een URL die een 404 teruggeeft, of een noindex-robotsmetatag aan de foutweergave toevoegen.

5. Zet de hoofdcontent en gestructureerde data in de HTML

Koppen, lopende tekst, prijzen, FAQ en gestructureerde JSON-LD-data horen in het serverantwoord te staan, niet pas na een klik of scroll te laden. Content achter tabbladen die op verzoek worden gerenderd, of achter knoppen als “meer laden”, wordt vaak gemist.

6. Houd het JavaScript licht

Splits de bundel per route, stel uit wat niet nodig is voor de eerste weergave en vermijd het opnieuw renderen van de hele pagina tijdens de hydratatie. Let op dat veldgegevens van Chrome (CrUX) de statistieken van navigatie binnen de app toewijzen aan de URL die de bezoeker als eerste laadde, dus test je belangrijkste sjablonen afzonderlijk.

7. Test wat bots ontvangen

Vergelijk drie versies van elk belangrijk sjabloon: de ruwe HTML (bekijk de bron of haal de pagina op met een opdrachtregeltool), de gerenderde HTML van Google (URL-inspectie, daarna “Gecrawlde pagina bekijken”) en de pagina met JavaScript uitgeschakeld. Als de hoofdtekst alleen in de tweede versie verschijnt, zien AI-crawlers hem niet. Onze gratis crawlbaarheidsaudit voor AI en de indexeerbaarheidscheck voeren deze controles uit op elke URL.

Hoe weet je of je SPA een SEO-probleem heeft?

SEO voor SPA's en GEO: gevonden worden op Google en geciteerd door AI

Jarenlang was rendering aan de clientzijde een beheersbaar risico, omdat Google JavaScript uiteindelijk rendert. Nu een deel van de ontdekking in ChatGPT, Claude, Gemini en Perplexity plaatsvindt, zijn de kosten veranderd: een pagina die pas bestaat na het uitvoeren van JavaScript, ontbreekt in de bronnen die de meeste assistenten kunnen lezen. Crawlbaarheid in de ruwe HTML is de eerste voorwaarde van generatieve zoekmachineoptimalisatie geworden.

Zodra de HTML compleet is, volgt de rest de gebruikelijke regels: pagina's die één vraag helder beantwoorden, met onderbouwde feiten en gestructureerde data, zijn de pagina's die assistenten citeren. De functies voor GEO-optimalisatie van Sorank helpen je die content te schrijven en te publiceren, en AI-vermeldingstracking laat zien of ChatGPT, Claude en Gemini je merk citeren na de oplossing voor het renderen.

De kernregel van SEO voor single page applications past in één zin: alles wat je door Google wilt laten ranken en door AI wilt laten citeren, moet in de HTML staan die de server verstuurt. Bewaar de SPA voor de ervaring na het inloggen, render openbare pagina's op de server of tijdens de build en test wat bots ontvangen vóór en na elke release.