Contact

Rendering SEO problemen: waarom Google je content mist

door | sep 11, 2026 | SEO | 0 Reacties

Browserpagina tijdens de JavaScript-renderingtest

Ja, rendering is vaak de schuldige. Als je titel, H1 of tekst alleen verschijnt nadat JavaScript is uitgevoerd, loop je het risico dat Google die content mist of pas dagen later verwerkt. Check nu de “URL Inspection” in Search Console en klik op “Bekeken pagina testen”. Zie je daar je kritieke tekst niet staan? Dan lekt daar je rendering. Verderop staat de volledige checklist.

Kort samengevat:

  • Renderingproblemen worden vaak veroorzaakt door geblokkeerde JavaScript- of CSS-bestanden in robots.txt, waardoor Google de belangrijkste content pas in pass twee ziet.
  • Test je rendering door view-source te vergelijken met de gerenderde DOM en gebruik de URL-inspectietool om de daadwerkelijke HTML te controleren die Googlebot ziet.
  • Veelvoorkomende fouten zijn lazy-loading van kritieke inhoud, client-side routing met hash-URL’s, en het injecteren van metadata via JavaScript, die de indexatie negatief kunnen beïnvloeden.
  • Voor grotere sites is het vaak beter te migreren naar server-side rendering of generateeropties als SSG en ISR, afhankelijk van de updatefrequentie en inhoudsbehoefte.
  • Gebruik gerichte tools zoals Search Console, Chrome DevTools en Screaming Frog om renderingproblemen snel en effectief te identificeren en op te lossen.
Nebber
Laat rendering SEO niet lekken
Nebber helpt bedrijven met technische SEO en praktische adviezen om organisch verkeer en zichtbaarheid in zoekmachines te verbeteren.

Bekijk Nebber

Inhoudsopgave

Wat is JavaScript-rendering: pass 1 versus pass 2

Google werkt in twee golven. Bij de eerste golf leest de crawler de rauwe HTML die je server terugstuurt, zonder ook maar één regel JavaScript uit te voeren. Die eerste golf krijgt voorrang, want ze is goedkoop en snel. Pas in de tweede golf stuurt Google de pagina door een renderer die JavaScript daadwerkelijk uitvoert, en dat kost rekenkracht. Tussen die twee golven kan uren tot dagen verstrijken.

Stel je het voor als een emmer die eerst leeg wordt opgehaald en pas later gevuld teruggezet. Kijk je in de broncode (“view-source”) van een zwaar client-side gerenderde pagina, dan zie je vaak alleen een kale <div id="root"> en het woord “Loading…”. De rest van je content zit in de tweede emmer, die soms pas veel later aan de beurt komt.

Rendert Google JavaScript wel goed? de beperkingen

Google gebruikt Headless Chromium en kan JavaScript dus echt uitvoeren. Maar “kan” is niet hetzelfde als “doet dat altijd snel en volledig”. De renderwachtrij is prioriteit-gestuurd: populaire, snelle sites komen eerder aan de beurt dan een trage pagina met tien externe scripts. Dat is geen technisch mankement van Google, het is gewoon een kosten-batenafweging op hun schaal.

Prioriteitsgestuurde JavaScript-rendering door Google

Het misverstand dat “Google rendert alles perfect, dus hoef ik niets te doen” is de kern van veel indexatieproblemen. In de praktijk betekent dit: content die afhankelijk is van zware hydratatie, trage API-calls of user-interactie komt onregelmatig binnen. Metadata die via JavaScript wordt geïnjecteerd, kan in pass 1 volledig ontbreken en in pass 2 te laat komen om nog impact te hebben op hoe Google je pagina eerst beoordeelt.

Hoe spoor je rendering-problemen op?

Je gaat niet gokken, je test. Zo doe je dat in de juiste volgorde:

  1. Vergelijk view-source met de gerenderde DOM. Open de pagina, bekijk de broncode, en zet daarnaast Chrome DevTools met JavaScript uitgeschakeld. Zie je je H1 en hoofdtekst niet in view-source? Dan staat die content pas in de tweede golf.
  2. Draai de URL Inspection-tool in Search Console. Klik op “Live URL testen” en daarna op “Bekeken pagina”. Dit toont je exact de HTML die Googlebot na rendering zag, inclusief eventuele foutmeldingen of geblokkeerde bronnen.
  3. Maak twee crawls met Screaming Frog, één met JavaScript-rendering aan en één uit. Verschillen in titel, H1 of woordenaantal wijzen direct naar renderafhankelijkheid.
  4. Controleer robots.txt en caching-headers. Een geblokkeerd .js-bestand is de meest voorkomende oorzaak van een kapotte render, en niemand kijkt er als eerste naar.

Pro-tip: Draai de Screaming Frog crawl twee keer met een tussenpauze van enkele minuten. Verschillen tussen die twee runs wijzen vaak op caching- of timeoutproblemen in de renderpijplijn, niet op een structureel probleem.

Veelvoorkomende rendering-fouten en hun snelle fix

De meeste renderproblemen zijn geen mysterie, het zijn herhalende patronen die je in vijf minuten herkent als je weet waar je moet kijken.

  • Geblokkeerde .js of .css in robots.txt: hef de blokkade op en test opnieuw met de URL Inspection-tool.
  • Metadata die via JavaScript wordt geïnjecteerd: verplaats title, meta description en structured data naar de server-response, niet naar een script dat pas na de load draait.
  • Client-side routing met hash-URL’s (zoals #/product/123): serveer echte URL’s met een padstructuur, of zet server-side routes op.
  • Lazy-loading van kritieke content: als je H1 of hero-tekst pas laadt bij scroll, zit die niet in pass 1. Zet die tekst gewoon in de eerste HTML.
  • Soft 404’s door JavaScript-fouten: een kapotte fetch-call toont een lege pagina met statuscode 200 in plaats van een echte 404. Regel dat statuscode-gedrag server-side af.

Elk van deze fouten is op zichzelf klein. Samen zorgen ze ervoor dat je dweilt met grote lekken, want elke nieuwe pagina erft dezelfde fout.

SSR, SSG, ISR of dynamic rendering: welke oplossing past bij jou?

Hier kies je de structuur die je probleem echt oplost, niet alleen verzacht. Vier routes, elk met eigen kosten en baten.

  1. Server-Side Rendering (SSR): elke request wordt server-side gerenderd voordat de HTML naar de browser gaat. Ideaal voor sites met veel unieke, dynamische pagina’s, zoals grote e-commerce-catalogi. Frameworks zoals Next.js en Nuxt.js maken dit relatief eenvoudig te implementeren.
  2. Static Site Generation (SSG): de pagina’s worden vooraf gebouwd tot statische HTML. Snelste optie, perfect voor blogs en marketingpagina’s die niet elk uur veranderen.
  3. Incremental Static Regeneration (ISR): een tussenweg die statische snelheid combineert met periodieke verversing. Voor veel sites in 2026 is dit de aanbevolen middenweg, zeker als contentupdates niet realtime moeten zijn.
  4. Dynamic rendering: je serveert een aparte, vooraf gerenderde versie specifiek aan crawlers. Dit kan als tijdelijke pleister werken, maar Google raadt het zelf niet meer aan als permanente oplossing, onder andere door de extra infrastructuur en het risico op verschillen tussen wat gebruikers en crawlers zien.

Voor een blog kies je SSG. Voor een marketingsite met af en toe een update werkt ISR uitstekend. Voor een webapp met interactieve dashboards is clientside rendering vaak prima, want daar zoekt niemand op. Voor een e-commerce-catalogus met duizenden productpagina’s is SSR of ISR bijna altijd de juiste keuze.

Pro-tip: Begin een migratie nooit in één keer op de hele site. Kies een subsectie van pakweg vijftig pagina’s, migreer die naar SSR of ISR, en vergelijk de indexatiesnelheid met een vergelijkbare subsectie die je nog niet hebt aangepakt.

Checklist: wat pak je eerst aan?

Niet alles is even urgent. Sommige fixes doe je vandaag, andere kosten een sprint.

  • Vandaag: metadata naar server-side verplaatsen, geblokkeerde .js/.css-bestanden vrijgeven, sitemap controleren op verweesde URL’s.
  • Deze week: interne links controleren op echte href-attributen in plaats van JavaScript-only click handlers, canonical-tags server-side verifiëren.
  • Deze maand tot kwartaal: migratie naar SSR, SSG of ISR voor de kernpagina’s die omzet of leads opleveren.

De render-pass die tussen initiële HTML en volledige JavaScript-executie uren tot dagen kan duren, is precies waarom je dit niet laat liggen: elke dag vertraging in indexatie is een dag gemiste zichtbaarheid. Meet je succes aan twee KPI’s: de tijd tussen publiceren en eerste indexatie in Search Console, en het aantal “gecrawld, momenteel niet geïndexeerd”-meldingen dat afneemt.

Welke tools test je waarvoor?

Je hebt niet tien tools nodig, je hebt de juiste vier op het juiste moment.

  • URL Inspection in Search Console: gebruik “Bekeken pagina” om te zien wat Google daadwerkelijk rendert, inclusief geblokkeerde resources en JavaScript-fouten.
  • Chrome DevTools: schakel JavaScript uit via de command palette, en check het Network- en Coverage-tabblad om te zien welke scripts laden en welke code ongebruikt blijft.
  • Screaming Frog: crawl met en zonder JavaScript-rendering aan, en vergelijk titel, H1 en woordenaantal tussen beide crawls.
  • Web en PageSpeed Insights: check laadtijd en lazy-loading-gedrag, want een trage render vergroot de kans dat Google de tweede golf overslaat of uitstelt.

Waarom Ramon hierop praat

Negentien jaar in technische SEO leert je één ding: rendering-problemen zijn zelden zichtbaar totdat je specifiek zoekt. Ramon Gulikers voert dit soort audits uit als vast onderdeel van technisch SEO-werk, met praktische checklists als vertrekpunt. Wil je bewijs zien voordat je een aanpak kiest? Vraag om concrete voor- en na-metingen van indexatiesnelheid en om screenshots van de URL Inspection-tool, niet om vage garanties.

Waarom Ramon hierop praat — overview diagram

Ramon’s korte mening: migreren of tijdelijk fixen

Client-side rendering is prima voor een dashboard achter een login, niemand zoekt daar toch op. Maar voor contentpagina’s die omzet moeten maken, is migreren naar SSR of ISR geen luxe. Test eerst op een subset, monitor negentig dagen, en trek dan de conclusie. Dynamic rendering is een noodverband. Wortel eruit, altijd.

— Ramon

Wat Nebber concreet voor je oplost

Er zijn alternatieven voor dure technische audits bij grote bureaus: gerichte diagnoses die binnen dagen laten zien waar rendering lekt. De audit combineert view-source, DevTools en Search Console-data, wijst quick wins aan die je zelf kunt oplossen, en bouwt daarna een migratieplan voor structurele oplossingen zoals een overstap naar SSR of ISR.

Nebber

Er is geen abonnement of verplicht vervolgtraject. Payment per opdracht. Vooraf is duidelijk wat je krijgt: een concreet rapport met prioriteiten. Wil je weten waar jouw site precies lekt? Vraag een audit aan via Nebber en start met de diagnose die je vandaag nog verder helpt.

Bronnen

Aanbevelingen