Een moderne website is vaak een applicatie. De server stuurt een vrijwel lege pagina met een verwijzing naar een script, en dat script bouwt in de browser de inhoud op. Voor een bezoeker werkt dat prima. Voor alles wat geen browser is, is het een leeg vel.
Dat verschil is de kern van JavaScript-SEO. De vraag is niet of je site mooi is, maar wat er in het antwoord van de server staat voordat er ook maar één script heeft gedraaid. Zie technische SEO checklist voor de bredere controle.
Hier zit een belangrijk onderscheid dat vaak wordt platgeslagen.
De grote zoekmachine kan scripts uitvoeren. Hij doet het in twee rondes: eerst de kale pagina, later het renderen. Die tweede ronde kan uren tot dagen later komen, en bij een grote site wordt hij niet altijd volledig gedaan.
Veel andere partijen doen het niet of beperkt. Crawlers van AI-aanbieders, voorvertoningen van links in berichtenapps en sociale netwerken, en allerlei kleinere diensten halen de HTML op en kijken niet verder. Wat daar niet in staat, bestaat voor hen niet.
Dat betekent: een site die alleen in de browser compleet is, is zichtbaar voor de grootste zoekmachine met vertraging, en onzichtbaar voor de partijen waar AI-antwoorden vandaan komen. Zie AI-crawlers toegang geven.
Server-rendering. De server bouwt de pagina op en stuurt complete HTML. Sterkste optie, en standaard in verschillende moderne frameworks. Vraagt wel een server die dat werk doet.
Prerendering bij het bouwen. Tijdens het bouwen van de site wordt per pagina een complete HTML-versie weggeschreven. De bezoeker krijgt daarna gewoon de applicatie, maar de crawler krijgt een gevulde pagina. Ideaal voor sites waarvan de inhoud niet elke minuut verandert: blogs, kennisbanken, diensten- en casepagina's.
Statisch bouwen. De hele site is een verzameling HTML-bestanden. Snelst en eenvoudigst, maar niet altijd haalbaar bij een applicatie met ingelogde delen.
Voor de meeste bedrijfssites is de tweede optie de gunstigste verhouding tussen werk en resultaat. Onze eigen site werkt zo: elke blogpost, elk kennisbank-artikel en elke dienstpagina wordt bij het bouwen als complete HTML weggeschreven, inclusief titels, teksten, interne links en gestructureerde data.
Prerendering is pas nuttig als de uitgeleverde HTML compleet is. Vier dingen horen erin te staan.
De volledige tekst, niet alleen de kop. Een pagina die de eerste alinea toont en de rest na een klik laadt, is half zichtbaar.
De interne links als echte links. Een blok "verder lezen" dat pas na het laden verschijnt, bestaat niet voor een crawler. Precies daar loopt het bij ons ook langs de prerender, want zonder dat zou de verweving tussen blog en kennisbank alleen voor bezoekers bestaan. Zie interne links strategie.
De metagegevens per pagina. Titel, beschrijving, canonieke URL en de gegevens voor linkvoorvertoningen, per pagina verschillend. Eén set voor de hele site is een veelgemaakte fout bij applicaties.
De gestructureerde data. Artikel, organisatie, veelgestelde vragen. Zie schema markup voor AI.
Dit is het deel dat je zelf kunt doen, vandaag, zonder gereedschap dat geld kost.
Open een pagina in de browser en kies "paginabron weergeven". Dat toont de HTML zoals hij binnenkwam, niet zoals de browser hem heeft opgebouwd. Zoek daarin een zin uit het midden van je tekst. Staat hij er niet, dan ziet een crawler zonder scriptuitvoering hem ook niet.
Doe dat op drie soorten pagina's: de homepage, een artikel en een detailpagina die uit een database komt. Die laatste is bijna altijd de zwakste.
Controleer daarnaast of elke pagina een eigen titel en beschrijving heeft, en of de voorvertoning klopt als je de link in een berichtenapp plakt. Die voorvertoning komt uit dezelfde HTML.
Het is geen wondermiddel, en twee misverstanden houden hardnekkig stand.
Het eerste: voorgerenderde pagina's maken dunne content niet beter. Een pagina van honderdvijftig woorden is zichtbaar en nog steeds niet de moeite waard om te tonen. De zichtbaarheid is een voorwaarde, geen prestatie.
Het tweede: de voorgerenderde versie en de versie die de bezoeker ziet, moeten dezelfde inhoud hebben. Een crawler een volledige tekst voorschotelen en de bezoeker iets anders, is geen slimme optimalisatie maar een overtreding van de richtlijnen, met verwijdering uit de index als mogelijk gevolg.
Verder is prerendering niet gratis in onderhoud. Een nieuwe pagina die niet in de lijst van te renderen routes staat, blijft leeg, en dat merk je pas weken later. Neem daarom in je bouwproces een controle op die telt hoeveel pagina's er zijn weggeschreven en faalt als dat aantal onverwacht daalt.
Een handvol fouten komt steeds terug. Alle pagina's delen dezelfde titel omdat die in het hoofdbestand staat. De sitemap bevat alleen de homepage, omdat de generator de routes van de applicatie niet kent. Pagina's die alleen bereikbaar zijn via een filter of een zoekveld, staan nergens in een link. En een lege pagina die een technisch correcte statuscode 200 teruggeeft, waardoor niemand merkt dat er niets in staat.
Die laatste is berucht: je ziet in de statistieken bezoek op een pagina die voor de crawler leeg is. Zie een SEO-audit uitgelegd voor hoe je dit systematisch nagaat.
De winst is zelden een sprong in posities van de ene op de andere week. Het is dat je pagina's meedoen: ze worden sneller opgenomen, ze verschijnen in linkvoorvertoningen, en ze zijn beschikbaar voor de partijen die AI-antwoorden samenstellen zonder scripts uit te voeren.
Wat wij zelf tegenkwamen bij het zichtbaar maken van een React-site staat in je React-site is mooi, maar ziet Google hem ook. Zie ook Core Web Vitals en snelheid, want dezelfde opzet raakt ook de laadtijd.
dGEN Productions, AI agency en business-automation partner uit Eindhoven. info@dgenproductions.nl · 06-87413056