Contact

JavaScript SEO: directe checklist voor ontwikkelaars

door | aug 20, 2026 | SEO | 0 Reacties

Ontwikkelomgeving met weergave van HTML-broncode

Zorg dat je belangrijkste content en metadata in de initiële HTML staan. Niet ergens diep in een script dat pas na drie seconden vuurt, maar meteen zichtbaar in de brontekst. Dat is de kern van javascript seo, en alles hieronder is uitleg en bewijs voor die ene regel.

Drie dingen doe je vandaag nog. Eén: open view-source op je belangrijkste pagina’s en check of de H1 en meta description er al staan, zonder dat er ook maar één script hoeft te draaien. Twee: zet URL’s met commerciële of zoekwaarde op SSG, SSR of ISR in plaats van pure client-side rendering. Drie: draai een Live Test via URL Inspection in Google Search Console en vergelijk wat Google ziet met wat een bezoeker ziet.

Waarom die haast? Google werkt met een two-pass model en een render-venster van ongeveer vijf seconden. Wat na die tijd nog moet laden, mist de trein. Soms tijdelijk, soms voorgoed.

En nee, dynamic rendering is geen eindstation. Het is een noodverband, geen behandeling.

Pro-tip: Bewaar een export van view-source vóór je begint met optimaliseren. Zonder nulmeting kun je straks niet bewijzen dat je fix heeft gewerkt.

Belangrijkste inzichten

JavaScript SEO slaagt wanneer kritieke content en metadata al in de initiële HTML staan, ondersteund door SSG of SSR waar zoekwaarde telt en een vaste audit-workflow met Search Console en Lighthouse.

Punt Details
Content in initiële HTML Titel, meta description en H1 moeten zichtbaar zijn in view-source, zonder gerenderde JavaScript.
Renderingstrategie per pagina Gebruik SSG of ISR voor contentpagina’s, SSR voor sterk dynamische content, CSR alleen achter een login.
Dynamic rendering is tijdelijk Zet het nooit in als permanente oplossing, alleen als brug tijdens een migratie met een einddatum.
Test met de juiste tools Combineer URL Inspection, Lighthouse en een render-crawler zoals Sitebulb voor een volledig beeld.
Nebber voor implementatie Nebber levert een technische audit met prioriteringslijst en begeleidt de uitvoering samen met je developers.

Inhoudsopgave

Hoe zoekmachines JavaScript verwerken

Google crawlt in twee stappen, en die twee stappen zitten soms dagen uit elkaar. Pass één pakt de ruwe HTML op, precies zoals de server die aflevert, zonder dat er een regel JavaScript is uitgevoerd. Pass twee stuurt de content door een render-service op basis van headless Chromium, die de pagina daadwerkelijk opbouwt zoals een browser dat zou doen. Tussen die twee passen zit een wachtrij, en die wachtrij kan meetbare vertraging in indexatie veroorzaken.

Denk aan een postbode die eerst alle enveloppen sorteert op adres, en pas later teruggaat om de brieven die iemand nog moest invullen op te halen. Alles wat in pass één al compleet is, gaat direct de index in. De rest wacht.

De twee cijfers die er echt toe doen: Google werkt met een two-pass renderingmodel, en de render-service hanteert in de praktijk een venster van ongeveer vijf seconden per pagina. Wat buiten die vijf seconden verschijnt, loopt het risico nooit meegenomen te worden.

Dat venster is geen boete, het is een resourcelimiet. Met miljarden pagina’s kan Google niet oneindig wachten op jouw bundle van 2 MB die eerst tien API-calls moet afronden voordat de H1 verschijnt.

Een paar praktische verschillen die je moet kennen:

  • Bing rendert JavaScript ook, maar met beperktere capaciteit en een kortere geduldsdrempel dan Google.
  • De meeste taalmodellen die het web doorzoeken voor AI-antwoorden, renderen helemaal geen JavaScript en lezen alleen de ruwe HTML.
  • View-source toont je pass één, de gerenderde DOM in Chrome DevTools toont je pass twee, en pas als je die twee naast elkaar legt zie je het gat.
  • De Live Test in Google Search Console geeft je een render-snapshot die dicht bij de werkelijke indexatie ligt, inclusief een screenshot van wat de render-service ziet.

Lighthouse voegt daar een derde laag aan toe: het meet niet wát er verschijnt, maar hóé snel, en die snelheid beïnvloedt weer of je binnen dat venster van vijf seconden blijft.

Renderingstrategieën: SSG, SSR, ISR of CSR?

Voor contentpagina’s met zoekwaarde is static site generation vrijwel altijd de sterkste keuze. Bij SSG bouw je de HTML al tijdens de build, dus Google krijgt in pass één meteen de complete pagina voorgeschoteld. Geen wachten, geen renderwachtrij, geen risico. Next.js noemt SSG expliciet als de standaardaanbeveling voor SEO-kritische routes, en dat is geen toeval.

Server-side rendering verdient de voorkeur zodra content per bezoeker of per moment verandert: prijzen die per gebruiker verschillen, voorraadstatussen, gepersonaliseerde aanbevelingen. SSR bouwt de pagina bij elk verzoek opnieuw op de server, dus de HTML is nog steeds compleet zodra hij bij de browser of de crawler aankomt. Het kost meer serverkracht dan SSG, maar je wint betrouwbaarheid.

Incremental Static Regeneration is de tussenweg voor sites met duizenden pagina’s die af en toe wijzigen: productcatalogi, nieuwsarchieven, vacaturesites. Je genereert statisch, maar herbouwt individuele pagina’s op de achtergrond zodra ze verouderen, zonder de hele site opnieuw te deployen. Het is de brandslang die je alleen aansluit op de kamer die daadwerkelijk in brand staat, niet op het hele gebouw.

Client-side rendering is waar het misgaat. Bij pure CSR stuurt de server een bijna lege HTML-pagina en bouwt JavaScript in de browser alles op. Dat werkt prima voor een dashboard achter een login, waar niemand op zoekt in Google. Voor een productpagina, blogartikel of landingspagina is het de langzame route naar indexatie, met een reëel risico dat content nooit of veel te laat verschijnt.

Dynamic rendering, waarbij je bots een voorgerenderde versie serveert en mensen de normale JavaScript-app, lost het probleem technisch op maar creëert een nieuw probleem: twee versies van je site onderhouden. Google zelf noemt dit een workaround, geen permanente architectuur, en waarschuwt voor de extra serverlast en het cloaking-risico als de twee versies uit elkaar gaan lopen. Acceptabel als noodbrug tijdens een migratie. Niet als eindbestemming.

Vuistregel voor je volgende sprint: content met zoekwaarde krijgt SSG of ISR, sterk dynamische content krijgt SSR, en alles achter een login mag gerust CSR blijven.

  • Contentpagina’s, blogs, productpagina’s: SSG of ISR
  • Prijzen, voorraad, gepersonaliseerde content: SSR
  • Dashboards, accountpagina’s, interne tools: CSR is prima
  • Migratieperiode zonder tijd voor herbouw: dynamic rendering, tijdelijk

Pro-tip: Kies de renderingstrategie per route, niet per project. Een webshop kan de productcatalogus op ISR draaien en het klantaccount gewoon op CSR laten staan.

Checklist: metadata, canonicals en structured data

Elke sprint waarin je JavaScript SEO aanpakt, verdient een vaste volgorde. Begin met wat zichtbaar is voordat een crawler ook maar één regel script uitvoert, werk daarna naar binnen toe.

Metadata en titels. Title en meta description horen in de initiële HTML te staan, niet pas na een useEffect-call die de tag injecteert. Test dit met view-source, niet met de browserinspectie, want die laat je altijd de gerenderde versie zien en verbergt het echte probleem.

Canonical tags en statuscodes. Zet een self-referencing canonical direct in de server-gerenderde HTML. Bij single-page applications is de meest voorkomende fout een soft 404: de server stuurt statuscode 200 terug voor een pagina die niet bestaat, met een leeg “niet gevonden”-bericht dat pas via JavaScript verschijnt. Google ziet de 200 en probeert de pagina te indexeren, ziet dan niets bruikbaars, en dat verpest je crawlbudget structureel. Gebruik de History API met echte, aanklikbare URL’s in plaats van fragment-navigatie, zodat elke route een eigen, crawlbare link heeft.

Structured data. JSON-LD moet in de server-gerenderde HTML staan, niet pas via een client-side script worden toegevoegd. Verifieer dit altijd met een render-test, niet alleen met een statische validator, want een validator controleert je brondocument en niet wat Google daadwerkelijk binnenkrijgt na rendering.

Lazy loading en afbeeldingen. Lazy loading is prima voor performance, funest voor SEO als je het verkeerd implementeert. Gebruik het native loading="lazy"-attribuut in plaats van een JavaScript-oplossing die pas laadt bij scrollen, want Googlebot scrolt niet en klikt niet. Alles wat pas verschijnt na een interactie die de crawler nooit uitvoert, bestaat voor Google simpelweg niet. Zorg dat je belangrijkste afbeelding, meestal de hero-afbeelding boven de vouw, nooit lazy load krijgt.

Web components en shadow DOM. Google plat de shadow DOM tijdens rendering, wat meestal goed uitpakt, maar test dit altijd met een render-snapshot voordat je op een webcomponentenarchitectuur bouwt voor contentpagina’s.

Caching en fingerprinting. Gebruik lange cachetijden met content-fingerprinting in bestandsnamen, zoals main.2bb85551.js in plaats van main.js. Zonder die vingerafdruk in de bestandsnaam kan Google’s render-service een verouderde versie van je script blijven cachen, waardoor je fixes weken later nog niet zichtbaar zijn in de index. Dat is dweilen met de kraan open: je verbetert de code, maar de oude emmer blijft doorlekken naar de crawler.

Detailopname van aantekeningen over caching en een werkplek vol ideeën

Prioriteer als volgt. Sprint één: metadata in HTML en canonicals recht zetten, dat is de snelste winst met de minste code. Sprint twee: structured data en lazy loading fixen, dat vraagt meer samenwerking met developers. Sprint drie: caching-strategie en monitoring, dat is het duurzame fundament waarop je blijft bouwen.

Hoe test je JavaScript SEO stap voor stap?

Een audit zonder vaste volgorde is giswerk met een deadline. Werk deze vier stappen consequent af, in deze volgorde, en je vindt negen van de tien problemen voordat een klant ze vindt.

  1. View-source versus Inspect. Open view-source (Ctrl+U) en vergelijk dat met de gerenderde DOM via Chrome DevTools Elements-paneel. Verschilt de H1, de title of de hoofdcontent? Dan leunt die pagina te zwaar op client-side rendering.
  2. URL Inspection en Live Test. Vraag in Google Search Console een Live Test aan voor de betreffende URL. Bekijk de gerenderde HTML én de screenshot die Google toont, en let specifiek op of geblokkeerde resources in het rapport verschijnen.
  3. Render-snapshot vergelijken. Leg de Live Test-uitkomst naast wat Screaming Frog of Sitebulb tonen bij een JavaScript-crawl. Verschillen tussen die twee wijzen vaak op timing- of resourceproblemen die je in een eenmalige test mist.
  4. Lighthouse en DevTools-tabbladen. Draai Lighthouse voor Largest Contentful Paint en Time to Interactive, en gebruik het Coverage-tabblad in DevTools om te zien welk percentage van je JavaScript-bundel daadwerkelijk wordt gebruikt op de pagina.

Wat je concreet tegenkomt: een H1 die volledig ontbreekt in view-source maar wel keurig in de gerenderde DOM staat. Dat betekent niet automatisch een ramp, Google rendert immers ook, maar het betekent wel een extra afhankelijkheid en een extra risico op vertraging.

Veelvoorkomende boosdoeners om structureel te checken: resources die per ongeluk geblokkeerd zijn in robots.txt, JavaScript-fouten die alleen optreden bij de Googlebot user-agent, hydratatiemismatches tussen server- en clientrendering, H1-tags die pas na een lazy-load event verschijnen, en canonical tags die door een client-side script worden overschreven na de eerste render.

Sitebulb’s eigen documentatie benadrukt dat je rendering audits het beste automatiseert in plaats van ze telkens handmatig te herhalen, en Ahrefs biedt een vergelijkbare raw-versus-rendered-vergelijking als aanvulling op Search Console.

Pro-tip: Bouw een kleine regressietest in je CI/CD-pipeline die na elke deploy view-source van vijf representatieve URL’s checkt op de aanwezigheid van H1, title en canonical. Eén script van twintig regels bespaart je maanden aan onopgemerkte indexatieschade.

Wat betekent JavaScript SEO per framework?

Elk framework heeft zijn eigen valkuil, en die valkuil verschilt genoeg om apart te benoemen.

Next.js. Gebruik de App Router met server components als startpunt voor nieuwe projecten. Voor sites met veel pagina’s is ISR de sterkste optie: stel de revalidate-waarde per route in, kort voor snel wijzigende content, lang voor statische pagina’s.

React zonder framework. Een pure Create React App-achtige opzet met alleen client-side rendering is riskant voor elke pagina die zoekverkeer moet trekken. Migreren naar Next.js of een vergelijkbaar framework met server-rendering is voor SEO-kritische routes vrijwel altijd de juiste stap.

Nuxt (Vue). Nuxt ondersteunt SSR en SSG standaard, en dat moet je ook gebruiken voor contentpagina’s. Zet ssr:false nooit in voor een route die in Google moet ranken, want daarmee schakel je exact de functie uit die Nuxt onderscheidt van pure client-side Vue.

Angular Universal. De server-side renderingoptie voor Angular werkt, maar let op bundelgrootte en hydratatiekosten. Angular-apps hebben de neiging fors uit te dijen, en een zware hydratatiestap kan je Time to Interactive juist weer verpesten, ook al staat de content al in de HTML.

Kleine vanilla JavaScript-projecten. Houd kritieke content gewoon in de statische HTML, of gebruik build-time prerendering voor je belangrijkste pagina’s. Je hebt geen zwaar framework nodig om dit probleem op te lossen.

Een praktisch migratiepatroon voor grote, oude codebases: bouw eerst alleen de contentpagina’s om naar server-gerenderde routes, en laat de rest van de applicatie voorlopig ongemoeid. Dynamic rendering kan dienen als tijdelijke brug tijdens die migratie, maar plan een einddatum, anders wordt de tijdelijke oplossing stilzwijgend permanent.

Pro-tip: Vraag bij elke framework-keuze niet “kan dit SEO”, maar “wat kost hydratatie mij op deze specifieke pagina”. Dat is vaak de echte showstopper, niet de renderingmethode zelf.

Wat betekent JavaScript SEO per framework? — overview diagram

Ramon’s zeven quick wins uit audits

Deze zeven punten kom ik terug in bijna elke technische audit, gerangschikt van directe winst naar structurele verbetering.

  1. Dag één: metadata naar de initiële HTML. Meet de indexatiestatus in Search Console een week later. Verwacht sneller herindexeren van gewijzigde titels.
  2. Dag één: canonical tags server-side instellen. Meet duplicate content-waarschuwingen in Search Console, die zouden binnen twee weken moeten dalen.
  3. Week één: lazy loading omzetten naar native loading="lazy". Meet Largest Contentful Paint in Lighthouse, met een verwachte verbetering van een paar honderd milliseconden op zware pagina’s.
  4. Week één: soft 404’s opsporen en corrigeren naar echte statuscodes. Meet het aantal “gecrawld, momenteel niet geïndexeerd”-meldingen in Search Console.
  5. Week twee: JSON-LD server-side injecteren. Verifieer met de Live Test of structured data zichtbaar is zonder client-side render.
  6. Maand één: contentpagina’s migreren van CSR naar SSG of ISR. Meet indexatiesnelheid van nieuwe pagina’s, die vaak van weken naar dagen daalt.
  7. Maand één: asset-fingerprinting invoeren voor caching. Meet of fixes na deploy sneller zichtbaar worden in de Live Test.

CSR voor contentpagina’s: niet doen. Ik zeg dit letterlijk in bijna elke audit die ik voor Nebber uitvoer, en negentien jaar ervaring heeft me nog geen enkele uitzondering laten zien die het risico waard was.

Waarom JavaScript SEO pragmatisch moet zijn

Architecturale perfectie wint geen rankings. Ik zie ontwikkelteams maanden besteden aan de perfecte micro-frontendstructuur, terwijl de productpagina’s die daadwerkelijk omzet maken nog steeds op pure client-side rendering draaien. Dat is een kasteel bouwen terwijl de voordeur openstaat.

Kies drie paginatypen die je omzet of leads opleveren, zet die op SSG of SSR, en meet indexatiesnelheid en Largest Contentful Paint. De rest van de site mag wachten.

Wat Nebber voor je JavaScript SEO kan doen

Een audit vertelt je wat er mis is. De vraag die er echt toe doet: wie zet dat om in een sprint die je developers ook daadwerkelijk oppakken? Nebber levert die brug. Ik lever een technische audit, een prioriteringslijst op basis van impact versus implementatiekosten, en begeleiding tijdens de implementatie zelf, samen met je eigen developers.

Nebber

Geen ellenlang rapport dat in een la verdwijnt. Wel een lijst die begint met wat binnen een dag op te lossen is en eindigt met wat een kwartaal kost. Met negentien jaar ervaring in technische SEO weet ik welke JavaScript-problemen echt ranking kosten en welke alleen theoretisch pijn doen. Wil je weten waar jouw site precies lekt? Vraag een gratis quickscan aan bij Nebber en ik geef je binnen een week concreet inzicht in wat prioriteit verdient.

Bronnen

Voor de basisregels van JavaScript-indexatie is Google Search Central de eerste plek om te checken, inclusief de officiële waarschuwing tegen permanente dynamic rendering. Wil je begrijpen wanneer SSG, SSR of ISR de juiste keuze is, dan geven de Next.js-documenten over renderingstrategieën een helder beslissingskader. Voor het daadwerkelijk debuggen van renderproblemen is de Sitebulb-gids over rendering een van de meest praktische die er is, en Search Engine Land’s JavaScript SEO-gids legt goed uit waarom Googlebot nooit klikt of scrolt.

Gebruik Search Console voor indexatievragen, Lighthouse voor performance en Sitebulb of Screaming Frog voor crawl-brede renderproblemen. Voor client-side routing is de MDN-documentatie over de History API onmisbaar naslagwerk. Meer diepgang over on-pagina metadata vind je in Nebber’s gids over on-page SEO-factoren, en voor lazy loading specifiek de checklist voor webprofessionals.

Aanbeveling