Moderne sites bouwen hun pagina in de browser op. Crawlers zonder scriptuitvoering krijgen een leeg vel. Hoe je in dertig seconden controleert wat er echt wordt uitgeleverd, en wat prerendering wel en niet oplost.
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 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.
Hier zit een onderscheid dat vaak wordt platgeslagen.
De grote zoekmachine kan scripts uitvoeren en doet dat 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.
De uitkomst: een site die alleen in de browser compleet is, is met vertraging zichtbaar voor de grootste zoekmachine en vrijwel onzichtbaar voor de partijen waar AI-antwoorden vandaan komen. Zie AI-crawlers toegang geven.
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 die test 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 meteen of elke pagina een eigen titel en beschrijving heeft. Bij applicaties staat die vaak één keer in het hoofdbestand, waardoor alle pagina's dezelfde titel delen. Plak de link ook eens in een berichtenapp: de voorvertoning die je ziet, komt uit precies dezelfde HTML.
Server-rendering. De server bouwt de pagina op en stuurt complete HTML. De sterkste optie, en standaard in verschillende moderne frameworks. Vraagt wel een server die dat werk doet.
Prerendering bij het bouwen. Tijdens het bouwen wordt per pagina een complete HTML-versie weggeschreven. De bezoeker krijgt daarna gewoon de applicatie, de crawler krijgt een gevulde pagina. Ideaal voor inhoud die niet elke minuut verandert.
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 de gunstigste verhouding tussen werk en resultaat. Zie JavaScript-SEO en prerendering.
Prerendering is pas nuttig als de uitgeleverde HTML compleet is. Vier dingen horen erin.
De volledige tekst, niet alleen de kop. De interne links als echte links, want een blok dat pas na het laden verschijnt bestaat niet voor een crawler. De metagegevens per pagina, dus titel, beschrijving en de gegevens voor linkvoorvertoningen. En de gestructureerde data voor artikel, organisatie en veelgestelde vragen.
Dat tweede punt verdient nadruk. Onze eigen site schrijft de blokken met verwante artikelen bewust mee in de voorgerenderde pagina. Zonder dat zou de samenhang tussen onze blog en onze kennisbank alleen voor bezoekers bestaan en niet voor crawlers, en dan doet hij precies de helft van zijn werk. Zie interne links strategie.
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. Zichtbaarheid is een voorwaarde, geen prestatie.
Het tweede: de voorgerenderde versie en de versie die de bezoeker ziet, moeten dezelfde inhoud hebben. Een crawler iets anders voorschotelen dan een mens is geen slimme optimalisatie maar een overtreding van de richtlijnen, met verwijdering uit de index als mogelijk gevolg.
En het is 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 zijn weggeschreven en faalt als dat aantal onverwacht daalt.
Een handvol fouten komt steeds terug. De sitemap bevat alleen de homepage, omdat de generator de routes van de applicatie niet kent. Pagina's zijn alleen bereikbaar via een filter of zoekveld en staan nergens in een link. En een lege pagina geeft een technisch correcte statuscode terug, waardoor niemand merkt dat er niets in staat.
Die laatste is berucht: in de statistieken zie je bezoek op een pagina die voor de crawler leeg is. Zie een SEO-audit uitgelegd.
Ja, met vertraging en niet altijd volledig. En de partijen die AI-antwoorden voeden, doen het vaak niet.
Meestal niet. Prerendering is bij de gangbare bouwgereedschappen toe te voegen zonder de applicatie om te gooien.
Zeker voor productpagina's, want juist die komen uit een database en zijn daarom het vaakst leeg in de bron.
Nieuwe en gewijzigde pagina's worden sneller opgenomen. Verwacht geen sprong in posities van de ene op de andere week.
Die verbetert meestal mee, omdat de bezoeker eerder iets ziet. Zie Core Web Vitals en snelheid.
Met de paginabron van uw drie belangrijkste pagina's. Die controle kost een minuut en beantwoordt de vraag of dit voor u speelt.
Wilt u dat wij het nakijken, neem contact op.
dGEN Productions, AI agency en business-automation partner uit Eindhoven. info@dgenproductions.nl · 06-87413056