JavaScript kan een pagina veranderen nadat de browser de eerste HTML heeft geladen. Lees hoe Google zulke pagina’s crawlt en rendert, waardoor belangrijke inhoud soms buiten de zoekresultaten blijft en hoe je controleert wat Google daadwerkelijk kan zien.

Crawlen, renderen en indexeren zijn verschillende stappen

Bij een gewone HTML-pagina staat de hoofdinhoud vaak al in het antwoord van de server. Een browser kan die meteen tonen en een crawler kan de tekst en links direct uitlezen. Bij een JavaScript-pagina kan dat anders zijn: de server levert eerst een vrijwel lege HTML-shell, waarna JavaScript de inhoud opbouwt. Google moet dan meer doen dan alleen de eerste HTML ophalen.

Het proces bestaat grofweg uit crawlen, renderen en indexeren. Tijdens het crawlen vraagt Googlebot een URL op en leest het onder meer de HTML en verwijzingen. Als verwerking met JavaScript nodig is, kan Google de pagina later met een browseromgeving renderen. De resulterende inhoud kan vervolgens worden meegenomen in de beoordeling voor indexering. Die stappen gebeuren niet noodzakelijk tegelijk. Een pagina die is gecrawld, is dus niet automatisch gerenderd of opgenomen in de index.

Dat onderscheid helpt bij het zoeken naar de oorzaak van ontbrekende zoekresultaten. Een URL kan bijvoorbeeld wel bekend zijn bij Google, maar nog niet zijn verwerkt. Of de URL wordt gerenderd, maar de hoofdtekst ontbreekt door een fout in de applicatie. Kijk daarom niet alleen of Google de URL kent: controleer ook de gerenderde inhoud, de indexeringsstatus en eventuele meldingen over ophalen of verwerken. Elke stap vraagt om een andere oplossing.

Client-side rendering kan belangrijke inhoud verbergen

Bij client-side rendering (CSR) stuurt de server doorgaans een HTML-document met weinig inhoud. De browser downloadt daarna JavaScript en haalt eventueel gegevens op via een API. Pas dan verschijnen productteksten, categorieën of artikelen. Voor bezoekers met een snelle verbinding lijkt dat vloeiend, maar een crawler moet de scripts succesvol ophalen en uitvoeren voordat die inhoud beschikbaar is.

Dat maakt CSR niet per definitie ongeschikt voor SEO. Het vergroot wel het aantal afhankelijkheden. Een geblokkeerd script, een fout in de bundel, een API die traag antwoordt of code die alleen na een gebruikersactie draait, kan ertoe leiden dat de crawler een lege of onvolledige pagina ziet. Ook een fout die alleen in productie voorkomt, kan onopgemerkt blijven als ontwikkelaars uitsluitend lokaal testen.

Server-side rendering (SSR) stuurt de inhoud al in de HTML mee. Dat verkort de route naar zichtbare tekst en links en maakt de pagina minder afhankelijk van JavaScript voor de eerste weergave. Static generation kan vergelijkbare voordelen bieden voor pagina’s die niet voortdurend veranderen. Een hybride aanpak is vaak praktisch: lever kerninhoud en interne links server-side, en gebruik JavaScript voor interactieve onderdelen. De afweging zit onder meer in serverbelasting, gegevensactualiteit en complexiteit van caching. Kies niet alleen op basis van een frameworktrend, maar op basis van de inhoud die zoekmachines betrouwbaar moeten kunnen verwerken.

Interne links moeten echte crawlbare URL’s opleveren

Single-page-applicaties wisselen vaak van scherm zonder een volledige nieuwe pagina te laden. Dat kan prettig navigeren zijn, maar de manier waarop routes en links zijn gebouwd is belangrijk voor crawlers. Een interne link hoort in de HTML een herkenbare bestemming te hebben, doorgaans als een normaal ankerelement met een href naar een echte URL. Een klikbare div of een link die uitsluitend via een event-handler werkt, is minder betrouwbaar: Googlebot hoeft niet te handelen alsof het een bezoeker is die op elk bedieningselement klikt.

Controleer ook of de URL’s zelfstandig werken. Plak een categorie- of product-URL in een nieuw tabblad en laad die opnieuw. Als de server alleen de homepage terugstuurt, een foutmelding geeft of de route pas na navigatie vanuit de homepage herkent, kan dat problemen geven bij ophalen en delen. Een SPA moet deep links correct afhandelen, met een passende statuscode en de juiste inhoud voor de gevraagde route.

Let op links die pas verschijnen na scrollen, filteren of het openen van een menu. Een menu mag interactief zijn, maar belangrijke bestemmingen moeten via normale links bereikbaar blijven. Paginering verdient extra aandacht: gebruik afzonderlijke URL’s voor pagina’s met unieke inhoud en zorg dat die URL’s onderling te crawlen zijn. Filters kunnen nuttig zijn voor bezoekers, maar een onbeperkte combinatie van parameters kan enorme aantallen URL’s opleveren. Bepaal daarom welke routes indexeerbaar moeten zijn en voorkom dat navigatie onbedoeld een onbegrensde crawlruimte creëert.

API-verzoeken en timing bepalen welke tekst verschijnt

Veel dynamische pagina’s vullen hun inhoud met gegevens uit een API. De server kan bijvoorbeeld de productnaam leveren, terwijl JavaScript voorraad, prijs, varianten en aanbevelingen later ophaalt. Als het verzoek mislukt of te laat klaar is, kan een crawler wel de algemene pagina zien maar niet de informatie die de pagina uniek maakt. Een lege laadindicator is geen vervanging voor inhoud, ook niet als de gegevens voor een menselijke bezoeker na enkele seconden alsnog verschijnen.

Onderzoek in de browserontwikkelaarstools welke netwerkverzoeken nodig zijn voor de hoofdinhoud. Controleer of ze zonder cookies, inlogstatus of speciale headers werken en of de API-response geldige gegevens bevat. Let op foutcodes, time-outs, CORS-problemen en limieten die geautomatiseerde verzoeken anders behandelen dan normaal verkeer. Een API die alleen op een gebruikersactie wordt aangeroepen, levert bovendien niets op zolang die actie niet plaatsvindt.

Een praktische keuze is om essentiële tekst en kerngegevens al tijdens server-rendering mee te geven. Hydration kan de pagina daarna interactief maken. Als gegevens snel veranderen, zoals voorraad, kan client-side verversing nog steeds nuttig zijn; zorg dan dat de basisinhoud niet afhankelijk is van die verversing. Vermijd onnodig lange wachttijden en scripts die blijven wachten op niet-essentiële aanbevelingen voordat ze de hoofdtekst tonen. Test ook foutscenario’s: een API die tijdelijk niet beschikbaar is, mag niet leiden tot een lege pagina of een misleidende status. Monitoring van de API alleen is onvoldoende; controleer ook wat er uiteindelijk in de gerenderde pagina terechtkomt.

Titels, canonicals en structured data moeten overeenkomen

JavaScript kan niet alleen de zichtbare inhoud aanpassen, maar ook de title-tag, meta description, canonical en structured data. Dat is risicovol wanneer de eerste HTML andere waarden bevat dan de gerenderde pagina. Google kan signalen uit meerdere bronnen tegenkomen en moet dan bepalen welke versie betrouwbaar is. Een canonical die na het laden naar een andere URL verandert, of per ongeluk op iedere route naar de homepage wijst, kan de gewenste indexering ondermijnen.

Controleer daarom metadata op twee momenten: in de oorspronkelijke HTML en in de gerenderde DOM. Bij SSR kunnen de juiste waarden direct worden meegestuurd; bij CSR moeten scripts ze op iedere relevante route correct instellen. Let extra op navigatie binnen een SPA. Als de zichtbare producttitel verandert maar de title-tag en canonical niet, krijgt Google tegenstrijdige signalen. Ook een gedeelde standaardtitel voor honderden URL’s maakt pagina’s minder onderscheidend.

Structured data hoort bij de inhoud van de betreffende pagina en moet overeenkomen met wat bezoekers kunnen zien. Plaats geen productprijs, beoordeling of beschikbaarheid in JSON-LD als die informatie op de pagina ontbreekt of verouderd is. Test de markup met geschikte validatietools en vergelijk de uitkomst met de gerenderde inhoud. Een technisch geldige markup garandeert geen uitgebreide weergave in zoekresultaten; Google bepaalt zelf of en hoe die wordt gebruikt. Behandel metadata en structured data daarom als onderdelen van dezelfde paginaversie, niet als losse scripts die later misschien worden bijgewerkt.

Lazy loading en oneindig scrollen vragen om extra aandacht

Lazy loading kan prestaties verbeteren door afbeeldingen of andere onderdelen pas te laden wanneer ze nodig zijn. Problemen ontstaan wanneer de belangrijkste tekst, producten of links pas verschijnen nadat een bezoeker scrolt of een knop indrukt. Googlebot kan pagina’s renderen, maar het is onverstandig om te veronderstellen dat iedere interactie precies wordt uitgevoerd zoals bij een menselijke gebruiker. De eerste render moet daarom al genoeg informatie bevatten om het doel van de URL te begrijpen.

Bij afbeeldingen is native lazy loading vaak eenvoudiger dan een eigen mechanisme dat afhankelijk is van scroll-events. Zorg dat de afbeelding een bruikbare src of srcset krijgt en dat essentiële alt-tekst in de HTML staat. Voor productlijsten moet de eerste set resultaten direct beschikbaar zijn. Een knop als ‘toon meer’ kan daarnaast handig zijn voor bezoekers, maar maak de onderliggende inhoud ook via afzonderlijke, crawlbare URL’s bereikbaar wanneer die inhoud zelfstandig relevant is.

Oneindig scrollen vormt een bekend risico: een bezoeker kan steeds verder bladeren, terwijl er geen vaste URL bestaat voor latere delen van de lijst. Zoekmachines kunnen dan vooral de eerste items aantreffen. Combineer oneindig scrollen daarom met normale paginering of een andere aanpak waarbij elke reeks een eigen URL heeft. Controleer dat die URL’s direct laden en dat links naar volgende pagina’s in de HTML staan. Vermijd bovendien dat dezelfde producten eindeloos onder verschillende parametercombinaties verschijnen; dat verspilt crawlcapaciteit en maakt het lastiger om de voorkeursversie te bepalen.

Controleer de gerenderde pagina met Search Console

Google Search Console biedt met URL-inspectie een praktische manier om te onderzoeken hoe Google een specifieke URL verwerkt. Bekijk eerst de indexeringsinformatie en voer daarna, waar beschikbaar, een live test uit. Die test helpt vaststellen of Google de URL op dat moment kan ophalen en renderen. Let op de gerenderde HTML of schermafbeelding, de status van de pagina en eventuele meldingen over resources. Een succesvolle live test bewijst niet dat de URL wordt geïndexeerd; de test gaat vooral over de actuele technische bereikbaarheid.

Vergelijk de uitkomst met de oorspronkelijke HTML. De optie ‘paginabron weergeven’ toont wat de server aanvankelijk heeft geleverd; dat is niet hetzelfde als de DOM nadat JavaScript heeft gedraaid. In de gerenderde weergave hoort de hoofdtekst aanwezig te zijn, samen met de relevante links en metadata. Als de schermafbeelding er goed uitziet maar de HTML inhoud mist, kan de pagina visueel overtuigend zijn terwijl belangrijke informatie voor verwerking ontbreekt.

Bekijk ook welke bronnen niet konden worden geladen. Een geblokkeerd script of API-verzoek kan een aanwijzing zijn, maar niet iedere waarschuwing is automatisch een SEO-probleem. Bepaal of de betreffende resource nodig is om de hoofdinhoud te tonen. Search Console kan bovendien een momentopname geven; gedrag kan verschillen door cache, timing of tijdelijke serverproblemen. Test daarom meerdere representatieve URL’s, zoals een categorie, productdetail en artikel, en herhaal controles na grote wijzigingen. Bewaar screenshots of gerenderde HTML als referentie, zodat veranderingen tussen releases zichtbaar worden.

Test JavaScript-SEO met browsertools en geautomatiseerde controles

Search Console is waardevol, maar niet altijd geschikt om snel tientallen routes te controleren. Gebruik daarnaast een normale browser en vergelijk de geladen pagina met de oorspronkelijke HTML. De ontwikkelaarstools laten zien welke scripts en API-verzoeken zijn uitgevoerd, hoe lang ze duurden en waar fouten optraden. Test met een schoon browservenster, zonder ingelogde sessie of eerder opgeslagen gegevens: die kunnen inhoud tonen die een crawler niet kan bereiken.

Een eenvoudige controle is JavaScript tijdelijk uitschakelen. Dat is geen exacte nabootsing van Googlebot, maar maakt zichtbaar hoeveel kerninhoud afhankelijk is van client-side code. Controleer daarnaast de pagina met een crawler die JavaScript-rendering ondersteunt en inspecteer de uiteindelijke HTML. Gebruik zulke tools als aanvulling, niet als bewijs dat Google exact hetzelfde resultaat krijgt. Crawlers verschillen in browseromgeving, wachttijd en verwerking van resources.

Neem representatieve URL’s op in geautomatiseerde tests. Laat bijvoorbeeld controleren of een productpagina een unieke titel, hoofdtekst, canonical en interne links bevat nadat rendering klaar is. Voeg ook foutgevallen toe: een ontbrekend product, een API-time-out en een ongeldige route. Controleer statuscodes apart van wat de browser uiteindelijk toont; een pagina die visueel ‘niet gevonden’ zegt maar HTTP 200 terugstuurt, kan als soft 404 worden behandeld. Test ten slotte na deploys op de productieomgeving, want CDN-configuratie, caching, toestemmingsteksten en beveiligingsregels kunnen daar anders uitpakken dan lokaal.

Voorkom renderproblemen door performance en toegang te bewaken

Een pagina kan technisch renderbaar zijn en toch onbetrouwbaar blijven wanneer scripts zwaar zijn of resources regelmatig falen. Hoe meer JavaScript nodig is voordat de hoofdinhoud verschijnt, hoe groter de kans op vertraging, time-outs en een onvolledige render. Dat schaadt niet alleen crawlerverwerking: bezoekers op tragere apparaten ervaren vaak hetzelfde probleem. Meet daarom welke code noodzakelijk is voor de eerste weergave en stel niet-essentiële functionaliteit uit.

Controleer of robots.txt belangrijke JavaScript- en CSS-bestanden niet blokkeert. Een browser kan zonder die bestanden een afwijkend beeld van de pagina krijgen, ook als de HTML wel bereikbaar is. Bekijk daarnaast serverlogs om te zien welke URL’s Googlebot opvraagt en welke statuscodes de server terugstuurt. Gebruik verificatie van Googlebot voordat je verkeer als echt Googlebot-verkeer interpreteert; een user-agentstring alleen kan worden nagebootst. Let op pieken in verzoeken, veel herhaalde foutcodes of routes die de server consequent als 404 behandelt.

Caching vraagt om een bewuste afweging. Een verouderde HTML-shell kan naar oude scripts verwijzen, terwijl een nieuwe API-response niet past bij de opgeslagen pagina. Gebruik consistente assetversies en test na publicatie ook een cache-miss en een verse sessie. Houd foutmeldingen in de console en server-side renderinglogs bij, maar beoordeel ze op impact: een fout in een advertentie-widget is iets anders dan een fout die voorkomt dat de producttekst verschijnt. Door renderbaarheid als onderdeel van monitoring en releasecontrole te behandelen, worden tijdelijke technische problemen eerder zichtbaar dan wanneer je uitsluitend naar rankings kijkt.