Er is een situatie die we regelmatig tegenkomen bij nieuwe klanten. De website ziet er goed uit, de teksten kloppen, alles laadt netjes, en toch staat er van een aantal pagina’s helemaal niets in Google. Geen slechte positie, maar simpelweg niets. Negen van de tien keer blijkt dan dat de inhoud pas verschijnt nadat JavaScript is uitgevoerd, en daar zit precies het probleem waar JavaScript SEO over gaat.
Het is een onderwerp dat snel technisch klinkt, maar de kern is eenvoudig. Google moet jouw pagina eerst ophalen en daarna begrijpen. Bij een gewone HTML-pagina gebeurt dat in één beweging. Bij een pagina die zijn inhoud met JavaScript opbouwt, zijn dat twee losse stappen, en de tweede stap gaat lang niet altijd goed.
In dit stuk leggen we uit wat er precies gebeurt, hoe je in tien minuten controleert of jouw site hier last van heeft, en wat je eraan kunt doen. Je hoeft geen ontwikkelaar te zijn om het te volgen. Wel helpt het om te weten wat je aan je websitebouwer moet vragen.
Wat JavaScript SEO precies is
JavaScript SEO is het geheel aan maatregelen dat ervoor zorgt dat zoekmachines de inhoud van een website kunnen zien wanneer die inhoud met JavaScript wordt geladen. Het is geen aparte discipline, meer een aandachtspunt binnen de technische kant van vindbaarheid.
Om te snappen waarom het bestaat, helpt het om te weten hoe Google werkt. Er is eerst een stap waarin de pagina wordt opgehaald, precies zoals hij van de server komt. Daarna komt er een tweede stap waarin de pagina wordt uitgevoerd alsof er een browser omheen zit, zodat alles wat later wordt geladen alsnog zichtbaar wordt.
Die tweede stap heet renderen, en hij kost Google veel meer rekenkracht dan de eerste. Daarom gebeurt hij niet direct. Soms binnen uren, soms na dagen, en bij grote of trage sites soms helemaal niet voor alle pagina’s. Alles wat pas in die tweede stap verschijnt, staat dus in het beste geval later in de index.
Wat we vaak zien is dat mensen denken dat Google geen JavaScript kan lezen. Dat is niet waar, Google kan het prima. Het punt is dat het niet altijd gebeurt, niet altijd volledig, en niet op het moment dat jij het nodig hebt.
Wanneer dit voor jou speelt
Voor een gewone WordPress-site met een standaard thema speelt dit meestal niet. De inhoud staat gewoon in de HTML en Google ziet hem meteen. Dat geldt voor het overgrote deel van de sites van dienstverleners.
Het gaat spelen zodra er een moderne bouwmethode achter zit. Sites gebouwd met React, Vue of Angular laden hun inhoud vaak pas na het uitvoeren van scripts. Ook webshops met filters, en sites die op een headless manier zijn opgezet, vallen in deze categorie.
Het speelt ook bij losse onderdelen op een verder normale site. Reviews die van een externe dienst komen, een agenda die wordt ingeladen, een overzicht van vacatures dat uit een systeem komt, tabbladen waar tekst pas in verschijnt als je klikt. Dat zijn stuk voor stuk plekken waar inhoud kan wegvallen voor zoekmachines.
Een derde geval dat we vaak tegenkomen is de oneindige lijst. Een blogoverzicht dat steeds meer items laadt terwijl je scrolt, of een knop met meer laden. Als er geen echte links naar de vervolgpagina’s zijn, komt Google nooit verder dan de eerste twaalf artikelen.
Hoe je in tien minuten controleert of het misgaat
De snelste controle is een stuk tekst van je pagina in Google zoeken tussen aanhalingstekens, samen met je domeinnaam. Komt de pagina niet naar boven terwijl hij wel bestaat, dan is dat een signaal.
Een tweede controle die iedereen kan doen: open de pagina, klik rechts en kies pagina-broncode weergeven. Dat toont de HTML zoals de server hem verstuurt, zonder JavaScript. Zoek daar met een zoekopdracht naar een zin uit je tekst. Staat hij er niet in, dan wordt hij door JavaScript geplaatst.
De meest betrouwbare controle is de URL-inspectie in Google Search Console. Daar kun je een pagina live testen en zien welke HTML Google na het renderen overhoudt, inclusief een schermafbeelding. Wat je daar mist, mist Google ook.
Wat in de broncode staat, ziet Google zeker. Wat er pas na het uitvoeren van scripts bij komt, ziet hij misschien en meestal later.
Doe die controles op verschillende typen pagina’s. Een dienstpagina, een blogartikel, een overzichtspagina en eventueel een locatiepagina. Vaak blijkt dat één type goed gaat en een ander type niet, en dan weet je meteen waar het probleem zit. Meer over dit soort controles vind je in onze kennisbank over technische SEO.
De vier problemen die het vaakst voorkomen
Het eerste en grootste probleem is inhoud die alleen na renderen bestaat. Titels, teksten, productbeschrijvingen. Google indexeert de pagina dan wel, maar met een lege of halve inhoud, en dan is er weinig om op te ranken.
Het tweede probleem zijn links die geen echte links zijn. Een menu-item dat is gebouwd als een knop met een klik-handeling erachter, in plaats van een gewone verwijzing naar een adres. Google volgt zulke elementen niet. Alles achter dat menu wordt daarmee onbereikbaar via de normale route.
Het derde probleem is de titel en de omschrijving die met JavaScript worden aangepast. Dat werkt technisch, maar het is fragiel. Gaat er iets mis in de uitvoering, dan blijft de standaardtitel staan en zie je in de zoekresultaten opeens overal dezelfde tekst.
Het vierde probleem is snelheid. Zware scripts maken het renderen traag, en trage pagina’s krijgen minder aandacht van Google. Bij een site met vijftig pagina’s merk je dat nauwelijks. Bij een site met vijfduizend pagina’s is het een reden waarom een deel nooit wordt opgepakt.
De oplossingen, van simpel naar ingrijpend
De beste oplossing is de eenvoudigste: zet de inhoud die ertoe doet gewoon in de HTML. Titel, tekst, koppen en de belangrijkste links. Alles daarnaast mag met JavaScript, dat is prima. Het gaat om wat er moet staan als er niets wordt uitgevoerd.
Bij sites die met een modern framework zijn gebouwd, heet die aanpak server-side rendering. De server bouwt de pagina op en stuurt hem compleet door. Elk gangbaar framework ondersteunt dit tegenwoordig, dus het is meestal een instelling en geen verbouwing.
Een variant die goed werkt voor pagina’s die weinig veranderen, is de pagina vooraf laten opbouwen bij het publiceren. Dienstpagina’s, blogartikelen en locatiepagina’s lenen zich daar goed voor. De bezoeker krijgt een kant-en-klaar bestand en Google ook.
Voor de kleinere gevallen zijn er kleinere oplossingen. Menu-items maak je tot echte links. Onder een oneindige lijst komt een gewone verwijzing naar pagina twee, ook als bezoekers hem nooit gebruiken. Reviews en agenda’s laad je aan de serverkant in wanneer de inhoud ervan meetelt voor je vindbaarheid.
Wat we in de praktijk adviseren is om niet meteen de hele site om te bouwen. Begin bij de pagina’s waar het meeste van afhangt: je dienstpagina’s en de overzichten die daarnaartoe leiden. Als die goed staan, heb je het grootste deel van het probleem al te pakken. De rest kan mee in het volgende onderhoudsmoment.
Wat dit betekent voor de AI-zoekmachines
Hier wordt het onderwerp actueler dan het jarenlang was. De AI-zoekmachines waar jouw klanten steeds vaker terechtkomen, halen pagina’s op met veel eenvoudigere technieken dan Google. Ze voeren in de regel geen JavaScript uit.
Het gevolg is direct. Een pagina die voor Google uiteindelijk wel goed komt na het renderen, kan voor ChatGPT of Perplexity volledig leeg zijn. Wordt jouw bedrijf daar niet genoemd terwijl je concurrent wel wordt aangehaald, dan kan dit de verklaring zijn.
Wij houden daarom in alles wat we bouwen rekening met drie zoek-werelden tegelijk, wat wij Triple Search Marketing noemen: Google, Meta en de AI-zoekmachines. De laagste gemene deler van die drie is eenvoudig: inhoud die zonder scripts leesbaar is. Meer daarover lees je op onze pagina over Triple Search Marketing.
Wat dit prettig maakt, is dat de oplossing hetzelfde is als voor Google. Je hoeft niets aparts te bouwen voor AI. Een pagina die zichzelf zonder JavaScript kan uitleggen, werkt in alle drie de werelden.
Hoe dit uitpakt per type dienstverlener
Bij een kliniek of praktijk zit het knelpunt meestal in het afsprakensysteem en de behandelingenlijst. Die komen vaak uit een extern pakket en worden met scripts ingeladen. De behandelpagina’s zelf staan dan wel in de HTML, maar het overzicht dat ernaartoe leidt niet, waardoor Google er moeilijk komt.
Bij een advocatenkantoor of adviesbureau gaat het vaker om het kennisbank-gedeelte. Een overzicht dat artikelen bijlaadt terwijl je scrolt, zorgt dat alleen de nieuwste stukken worden gevonden. Alles ouder dan een paar maanden verdwijnt uit beeld terwijl de inhoud prima is.
Bij een HR-bureau met een vacaturemodule speelt hetzelfde. De vacatures komen uit een systeem en worden na het laden getoond. Ze staan dan niet in de HTML, en daarmee ook niet in de zoekresultaten, terwijl juist die pagina’s veel verkeer kunnen opleveren.
Bij coaches en consultants met een site op een visuele bouwer zien we een ander patroon. Daar is de inhoud meestal wel gewoon aanwezig, maar wordt hij vertraagd getoond met animaties. Dat is doorgaans geen probleem voor de indexering, wel voor de snelheid.
En bij webshops en bedrijven met een productcatalogus komt het knelpunt bijna altijd bij de filters vandaan. Een bezoeker vinkt een categorie aan, de lijst verandert, maar het adres in de browser blijft hetzelfde. Voor Google bestaan die gefilterde overzichten dan niet, terwijl het juist de pagina’s zijn waar mensen op zoeken. Een filter dat het adres wél aanpast en dat het resultaat aan de serverkant opbouwt, lost dat in één keer op.
Wat je aan je websitebouwer vraagt
Je hoeft dit niet zelf op te lossen, maar het helpt enorm als je de goede vragen stelt. De eerste is of de inhoud van de belangrijkste pagina’s in de HTML staat die de server verstuurt. Een bouwer die daar meteen antwoord op heeft, weet waar hij het over heeft.
De tweede vraag gaat over de navigatie: zijn alle menu-items en overzichtslinks echte verwijzingen naar adressen. Dat klinkt vanzelfsprekend, maar in de praktijk is het dat niet.
De derde vraag gaat over paginatitels en omschrijvingen: worden die aan de serverkant gezet of pas daarna aangepast. Als het antwoord het laatste is, vraag dan of dat anders kan.
De vierde vraag is of er een testomgeving is waarop je dit kunt controleren voordat iets live gaat. Wie na elke aanpassing even de broncode bekijkt, ontdekt dit soort dingen binnen een minuut in plaats van na drie maanden dalende bezoekersaantallen.
Wat we vaak zien misgaan
De meest voorkomende misser is dat er pas naar wordt gekeken als de site al af is. Een nieuwe website gaat live, de bezoekersaantallen zakken in, en dan begint het zoeken. Terwijl één gesprek vooraf het had voorkomen.
De tweede misser is dat er alleen naar de homepage wordt gekeken. Die is meestal goed gebouwd omdat er de meeste aandacht naartoe gaat. De overzichtspagina’s en de detailpagina’s zijn de plekken waar het misgaat, en daar komt het verkeer vandaan.
De derde misser is dat er te veel wordt gerepareerd met tussenoplossingen. Er zijn diensten die de gerenderde versie van je pagina apart aan zoekmachines aanbieden. Dat werkt, maar het is een extra laag die kan omvallen en die je moet blijven betalen. Als het aan de bron kan worden opgelost, is dat bijna altijd verstandiger.
De vierde misser is niet controleren of het is opgelost. Een aanpassing wordt doorgevoerd, iedereen gaat ervan uit dat het goed is, en niemand kijkt of de pagina’s daadwerkelijk worden opgenomen. Dat check je in Search Console, en die controle kost vijf minuten. Hoe je die cijfers leest, staat verder uitgewerkt in onze kennisbank over data en conversie.
Veelgestelde vragen over JavaScript SEO
Kan Google JavaScript lezen?
Ja, Google kan JavaScript uitvoeren en de inhoud die daarmee verschijnt gewoon indexeren. Het gebeurt alleen in een tweede ronde die veel rekenkracht kost, waardoor het later plaatsvindt en bij grote of trage websites niet altijd voor alle pagina’s. Inhoud die direct in de HTML staat, wordt zonder die vertraging opgepakt.
Hoe zie ik of mijn website JavaScript nodig heeft om inhoud te tonen?
Open de pagina, klik rechts en kies pagina-broncode weergeven. Zoek daar naar een zin uit je tekst. Staat die zin er niet in, dan wordt hij met JavaScript geplaatst. De URL-inspectie in Google Search Console geeft het meest betrouwbare beeld, inclusief een schermafbeelding van wat Google na het renderen overhoudt.
Wat is server-side rendering?
Bij server-side rendering bouwt de server de pagina volledig op en stuurt hij hem compleet naar de browser of zoekmachine. Er is dan geen tweede stap meer nodig om de inhoud zichtbaar te maken. Elk gangbaar framework ondersteunt dit, waardoor het meestal een instelling is en geen volledige verbouwing van de site.
Heeft een gewone WordPress-site last van JavaScript SEO?
Meestal niet, want bij een standaard thema staat de inhoud gewoon in de HTML. Losse onderdelen kunnen wel problemen geven: reviews van een externe dienst, een vacaturemodule, een agenda of een blogoverzicht dat artikelen bijlaadt tijdens het scrollen. Die controleer je apart via de broncode.
Zien AI-zoekmachines zoals ChatGPT wel JavaScript-inhoud?
In de regel niet. De meeste AI-zoekmachines halen pagina’s op zonder scripts uit te voeren, waardoor een pagina die voor Google uiteindelijk goed komt voor hen leeg kan zijn. Dat is een reden waarom bedrijven soms niet genoemd worden in AI-antwoorden terwijl ze in Google prima scoren.
Wat dit onderwerp prettig maakt, is dat de oplossing bijna altijd dezelfde kant op wijst: inhoud die zonder scripts leesbaar is, werkt overal. Wil je hier samen naar kijken en controleren of jouw pagina’s echt worden gezien? Plan een strategiegesprek, dan lopen we het rustig door.
