JavaScript SEO is zorgen dat zoekmachines de inhoud en links van je site kunnen lezen, ook als JavaScript die in de browser opbouwt. Google kan JavaScript uitvoeren, maar doet dat later dan het ophalen van de HTML, en klikt niet op knoppen. Veel AI-crawlers voeren voor zover bekend helemaal geen JavaScript uit. Onze invalshoek: bij […]
JavaScript SEO is zorgen dat zoekmachines de inhoud en links van je site kunnen lezen, ook als JavaScript die in de browser opbouwt. Google kan JavaScript uitvoeren, maar doet dat later dan het ophalen van de HTML, en klikt niet op knoppen. Veel AI-crawlers voeren voor zover bekend helemaal geen JavaScript uit.
Onze invalshoek: bij een mkb-site zit het JavaScript-risico zelden in het fundament, maar in de widgets en plugins die er later bij komen. En de toets die telt, is niet "kan Google dit renderen?" maar "staat het in de paginabron?". Wat daar niet staat, ziet Google pas later en zien veel AI-crawlers nooit. Daar komt een tweede kant bij die bijna niemand noemt: JavaScript bepaalt niet alleen wat Google ziet, maar ook wat jij meet.
De drietrapstoets: bron, gerenderd, index
Je hoeft geen ontwikkelaar te zijn om dit te testen. Neem je drie belangrijkste pagina's, bijvoorbeeld je homepage, je belangrijkste dienst en een categorie of overzicht, en loop per pagina drie lagen af.
- De paginabron. Open de pagina, toets Ctrl+U (op een Mac Cmd+Option+U) en zoek met Ctrl+F op een zin uit je hoofdtekst, een kop, een review en een link uit je menu. Dit is wat de server verstuurt, vóór er JavaScript draait.
- De gerenderde versie. Voer de URL in bij de URL-inspectie in Google Search Console, kies de live test en bekijk de geteste pagina: de HTML en de schermafbeelding. Zoek opnieuw op dezelfde zinnen. Kijk ook naar bronnen die niet konden worden geladen.
- De index. Zoek in Google op een unieke zin uit de pagina tussen aanhalingstekens. Komt je pagina niet naar boven terwijl hij wel geïndexeerd is, dan is die tekst niet meegekomen.
| Uitkomst | Wat het betekent | Wat je doet |
|---|---|---|
| Staat in de paginabron | Google, AI-crawlers en andere bots lezen het direct | Niets; dit is de norm |
| Ontbreekt in de bron, staat wel in de gerenderde HTML | Google ziet het, maar later; veel AI-crawlers zien het niet | Gaat het om je hoofdtekst, prijzen, reviews of menulinks: naar de bron verhuizen. Gaat het om een chatknop of een slider: laten zo |
| Ontbreekt ook in de gerenderde HTML | Google ziet het niet | Eerst oplossen: dit kost je posities en interne links |
| Een noindex in de bron die een script later weghaalt | Google kan besluiten de pagina niet eens te renderen | Noindex alleen in de bron zetten als je hem ook echt bedoelt |
Voorbeeld (fictieve dienstpagina): in de paginabron staat bij de reviews alleen een leeg blok; de reviewwidget vult het na het laden met twaalf beoordelingen. In de gerenderde HTML van Search Console staan ze wel. Google kan ze dus lezen, een AI-crawler die alleen de bron ophaalt niet. Staan er pas meer reviews na een klik op "meer laden", dan ziet ook Google die niet. Beslissing: zet een paar sterke reviews als gewone tekst op de pagina en laat de widget de rest doen.
Wat Google met een JavaScript-pagina doet
Google verwerkt een pagina in drie stappen: crawlen (de HTML ophalen), renderen (de JavaScript uitvoeren in een browseromgeving) en indexeren. Het renderen gebeurt niet altijd direct; pagina's komen in een wachtrij. Staat de inhoud al in de eerste HTML, dan kan Google er meteen mee verder. Moet alles nog worden opgebouwd, dan hangt je zichtbaarheid af van die tweede stap.
Andere crawlers zijn minder geduldig. Wie wil dat AI-zoekmachines de inhoud kunnen citeren, zorgt dat die zonder JavaScript leesbaar is, en regelt daarnaast in robots.txt welke crawlers welkom zijn. Dat laatste staat in AI-crawlers en robots.txt.
Vier constructies die het in de praktijk breken
Knoppen die doen alsof ze links zijn
Google volgt alleen een a-element met een href naar een echte URL. Een knop of element met een klikfunctie die naar een andere pagina navigeert, ziet er voor de bezoeker uit als een link, maar Google volgt hem niet. Geldt dat voor je menu, paginering of filters, dan vindt Google je dieperliggende pagina's alleen via de sitemap of niet.
Inhoud die pas na een klik van de server komt
Tabbladen en uitklapblokken zijn meestal geen probleem, zolang de tekst bij het laden al in de HTML staat en alleen verborgen is. Het gaat mis als de inhoud pas bij de klik wordt opgehaald: "laad meer"-knoppen, reviews achter een klik, tabbladen die hun inhoud pas bij het openen laden.
Titels, canonicals en statuscodes uit scripts
Metadata die pas door JavaScript wordt ingevuld, pikt Google vaak op, maar niet altijd betrouwbaar. Bij sites die volledig in de browser draaien, krijgt een niet-bestaande pagina bovendien vaak status 200 in plaats van 404, zodat Google lege pagina's als echte pagina's behandelt.
URL's met een hekje
Alles na een # behandelt Google als een plek op dezelfde pagina. Een site die zijn pagina's opbouwt als /#/diensten en /#/contact, is voor Google één pagina. Gebruik gewone paden.
Bouw je op een framework? Kies de rendering bewust
Bij een gangbare WordPress-site levert de server al complete HTML; het risico zit daar in losse onderdelen. Bij een JavaScript-framework of een headless CMS is de manier van renderen een keuze die je aan het begin maakt.
| Aanpak | Hoe het werkt | Voor vindbaarheid |
|---|---|---|
| Client-side rendering | De server stuurt een vrijwel lege pagina; de browser bouwt alles op | Meeste risico; afhankelijk van renderen, lastig voor AI-crawlers |
| Server-side rendering | De server bouwt de complete HTML; JavaScript voegt interactie toe | Inhoud en links staan direct in de bron |
| Statisch genereren | Pagina's worden vooraf als complete HTML gebouwd | Snel en goed leesbaar; minder geschikt voor inhoud die steeds verandert |
Een aparte versie voor bots, dynamic rendering, ziet Google zelf als tijdelijke omweg en niet als oplossing: twee versies onderhouden betekent dat ze uit elkaar gaan lopen. Wij raden het af. Welk systeem bij je situatie past, lees je in wat is een CMS.
De kant die bijna niemand noemt: JavaScript bepaalt ook wat je meet
Je conversiemeting draait meestal ook op JavaScript: een tag of pixel die in de browser afgaat als iemand een formulier verstuurt of iets koopt. Wordt dat script geblokkeerd door een adblocker, een browserinstelling of een cookiebanner die verkeerd is ingesteld, dan mist Google Ads conversies en stuurt Smart Bidding op onvolledige data. Ons standpunt is daarom: meten gaat vóór schalen, en de meeste "Ads werkt niet"-klachten blijken bij nader inzien trackingproblemen.
Twee vaste werkregels uit ons Ads-beheer gelden hier direct. Leg de conversiemeting elke maand naast de echte orders of aanvragen; wijkt het af, dan zoek je de oorzaak in de meting voordat je iets aan de campagne verandert. En valt de meting een periode uit, dan zet je een gegevensuitsluiting in plaats van je doelen aan te passen. Een server-side laag naast de browsertag maakt de meting minder afhankelijk van wat in de browser wel of niet draait; hoe dat werkt, lees je in server-side tracking.
Wat we afraden
- Een widget installeren zonder bron-test. Reviews, FAQ-blokken, prijslijsten en vacatures uit externe widgets staan vaak niet in de paginabron. Doe na installatie de Ctrl+U-test.
- Filters en menu's op knoppen. Kies in je thema of filterplugin voor echte links, of juist bewust voor geen eigen URL's als die filters niets in Google te zoeken hebben.
- Testen in de inspector van je browser. Die toont de pagina na JavaScript, precies het beeld dat je niet wilt controleren. Gebruik de paginabron.
- JavaScript als eerste verdachte. Staat een pagina als niet geïndexeerd, loop dan eerst de andere oorzaken na in pagina niet geïndexeerd. JavaScript is er één van, niet de meest voorkomende.
Veelgestelde vragen over JavaScript SEO
Kan Google JavaScript lezen?
Ja. Google rendert pagina's met een actuele browserversie en voert de meeste moderne JavaScript uit. Dat gebeurt wel later dan het ophalen van de HTML, en Google klikt niet op knoppen of laadt geen inhoud die pas na een actie verschijnt. Wat er bij het laden niet staat, ziet Google dus niet.
Is een site in React of Vue slecht voor SEO?
Niet als je kiest voor server-side rendering of statisch genereren. Dan staat de inhoud gewoon in de HTML en heeft de bezoeker toch een snelle, interactieve site. Het risico zit in pure client-side rendering, waarbij de server een lege pagina stuurt en alles in de browser wordt opgebouwd.
Zien AI-zoekmachines inhoud die met JavaScript wordt geladen?
Reken er niet op. Voor zover bekend voeren veel AI-crawlers geen of maar beperkt JavaScript uit. Wil je dat je diensten, prijsinformatie of reviews in AI-antwoorden terugkomen, zet die dan als gewone tekst in de paginabron. Test dat met Ctrl+U: wat je daar niet vindt, mist zo'n crawler.
Hoe weet ik of mijn site last heeft van JavaScript-problemen?
Doe de drietrapstoets op je belangrijkste pagina's: paginabron, de live test in de URL-inspectie van Search Console en een zoekopdracht op een unieke zin. Ontbreken teksten, links of reviews in een van die lagen, dan weet je precies waar je moet zoeken.
Wil je zeker weten dat Google, AI-zoekmachines en je eigen conversiemeting zien wat je bezoeker ziet? Bekijk onze SEO-dienstverlening en plan een gesprek; dan lopen we de drietrapstoets samen langs je belangrijkste pagina's.
