JavaScript SEO: waarom Google je content soms niet ziet

JavaScript SEO is het zorgen dat zoekmachines de content zien die jouw JavaScript op het scherm tovert. Het korte antwoord: Google rendert JavaScript wel, maar niet altijd zoals jij denkt, en als de rendering misgaat, indexeert Google je content niet. Bijna alle moderne sites draaien op JavaScript (volgens W3Techs gebruikt 98,9% van alle websites het), dus dit raakt vrijwel iedereen. In dit artikel lees je welke rendering-problemen het vaakst voorkomen, hoe je ze opspoort, en hoe je ze oplost zonder maandenlang te wachten.

Wat is JavaScript-rendering en waarom telt het voor SEO?

Een pagina bestaat in twee versies. De ruwe HTML is wat de server stuurt voordat JavaScript draait. De gerenderde HTML is wat je ziet nadat JavaScript heeft uitgevoerd. Het verschil tussen die twee is precies waar JavaScript SEO over gaat.

Er zijn twee manieren om dat renderen te doen. Bij server-side rendering bouwt de server de complete pagina al op en stuurt die kant-en-klaar naar de browser. Bij client-side rendering krijgt de browser (of de crawler) eerst kale HTML en moet die zelf het JavaScript uitvoeren om de pagina af te maken. Die tweede aanpak is trager en foutgevoeliger, en is voor de meeste sites af te raden.

Het punt is dit: rendert JavaScript niet voor je bezoeker, dan rendert het zeker niet voor de crawler van Google. En wat Google niet kan renderen, kan het niet indexeren of ranken. Voor een B2B-site betekent een onzichtbare pagina geen gemiste klik, maar een gemiste lead. Daarom hoort JavaScript SEO in je website-strategie thuis, naast je content en je technische SEO.

Kan Google JavaScript wel lezen?

Belangrijk nuanceverschil: Google crawlt geen JavaScript, maar het kan het wel renderen. Het zet je JavaScript dus om naar gerenderde HTML, en die HTML crawlt en indexeert het vervolgens. In theorie komt je content er dus alsnog in.

In de praktijk zit de adder onder het gras. Dat renderen kost Google extra tijd en middelen, het gebeurt in een aparte stap na het eerste crawlen, en het kan misgaan op tientallen manieren. Eén geblokkeerd bestand, één tegenstrijdige instructie, en je content valt door de mand. Reken er dus niet op dat Google het altijd “wel oplost”. Je controleert het zelf.

Hoe spoor je rendering-problemen op?

De kern is steeds dezelfde test: vergelijk je ruwe HTML met je gerenderde HTML. Wijken ze af op dingen die ertoe doen (de paginatitel, de H1, de hoofdtekst, links, hreflang), dan loop je risico zodra de rendering een keer hapert.

Een paar concrete manieren om dat te checken:

• Google Search Console. De URL-inspectie laat je de gerenderde HTML en een screenshot zien zoals Google de pagina ophaalt. Zie je daar je content niet, dan ziet Google die ook niet. Hoe je dit leest, staat in Google Search Console uitleg.
• Een crawler zoals Screaming Frog. Die kan beide versies naast elkaar zetten en laat precies zien waar JavaScript content toevoegt die in de ruwe HTML ontbreekt.
• De source code bekijken. Open je pagina, bekijk de paginabron, en zoek naar je belangrijkste tekst en titels. Staan ze er niet, dan komen ze pas via JavaScript binnen.

Een analyse van drie bekende SaaS-sites (Zoom, Asana en een marketingblog) liet zien dat zelfs grote, technisch volwassen merken hier last van hebben. Bij Zoom ontbrak het hreflang-attribuut in de ruwe HTML, stond de H1 er niet in, en toonde de ruwe titel “Loading” terwijl de gerenderde titel “Zoom Learning Center” was. Op zich vaak geen ramp zolang de rendering slaagt, maar elk verschil is een potentieel lek zodra die rendering een keer faalt.

Welke JavaScript rendering-problemen komen het vaakst voor?

Drie problemen duiken telkens op. Goed nieuws: ze zijn alle drie op te lossen.

Geblokkeerde .js-bestanden in robots.txt

Als ik er één mocht uitlichten, is dit het. Blokkeer je je JavaScript-bestanden in je robots.txt, dan kan Google ze nooit ophalen, dus nooit renderen, dus nooit de content erachter indexeren. In de SaaS-analyse hadden alle drie de sites in meer of mindere mate geblokkeerde JS-resources; bij de best presterende site bleef de schade beperkt tot een handvol URL’s.

De fix is verrassend simpel: laat je robots.txt aanpassen zodat kritieke resources (je JavaScript-bestanden) niet langer geblokkeerd worden. Daarna hoef je niet weken te wachten tot Google vanzelf terugkomt; je kunt via Search Console expliciet vragen om je URL’s opnieuw te crawlen.

Tegenstrijdige directives

Directives zijn instructies aan crawlers, zoals noindex (niet indexeren) en nofollow (geen linkwaarde doorgeven). Het probleem ontstaat als je ruwe HTML een andere directive bevat dan je gerenderde HTML. Staat er bijvoorbeeld noindex in de ene versie en niet in de andere, dan weet Google niet wat te doen, en het resultaat is vaak dat geen van beide versies geïndexeerd raakt. Het kan zelfs een timeout-fout opleveren in je performance-rapporten.

De oplossing: maak je intentie eenduidig. Wil je dat een pagina geïndexeerd wordt, haal de noindex dan uit zowel de ruwe als de gerenderde HTML. Wil je hem juist uit de index houden, zorg dan dat noindex in beide versies staat.

Links die niet renderen

Links die alleen in JavaScript bestaan, kunnen falen te renderen, bijvoorbeeld omdat een plugin is uitgeschakeld of een themabestand is verwijderd. Het gevolg: rendert de link niet, dan kan Google hem niet volgen, en geef je geen interne linkwaarde door aan de bestemmingspagina. Op een B2B-site waar je met interne links je belangrijkste dienstpagina’s wilt versterken, lekt daar dus autoriteit weg. Controleer regelmatig welke JavaScript-links niet renderen en ruim ze op, ook om scriptbloat te voorkomen.

Wat is het verschil tussen server-side en client-side rendering?

Voor de meeste B2B-sites is dit de belangrijkste structurele keuze. Bij server-side rendering (SSR) krijgt de crawler een complete pagina: de server haalt de data op, bouwt de HTML, en stuurt die af. Geen extra renderstap, geen wachten, niets dat kan misgaan in de browser van Google. Bij client-side rendering schuif je dat werk door naar de client, met alle risico’s van dien.

Bouw je een nieuwe site of plan je een migratie, kies dan voor server-side rendering of een variant die de belangrijkste content al in de ruwe HTML zet. Het is de schoonste manier om rendering-problemen bij voorbaat uit te sluiten. En het sluit aan bij je Core Web Vitals: minder client-side JavaScript betekent vaak een snellere, stabielere pagina.

Wat moet je hier als B2B-bedrijf mee?

Eerlijk advies: je hoeft hier niet paranoïde van te worden, maar je moet het wél één keer goed checken. De meeste rendering-fouten hebben geen zichtbaar effect tot het moment dat ze dat plots wél hebben, en dan verlies je een belangrijke pagina uit de index zonder dat je het doorhebt.

Onze stelling is simpel: stuur op klanten en omzet, niet op ijdele cijfers. Een rendering-probleem op je blog dat niemand bezoekt, is het oplossen niet waard. Een rendering-probleem op je dienstpagina of je belangrijkste landingspagina is een directe bedreiging voor je leadstroom. Wij zijn een klein team, dus we beginnen altijd bij de pagina’s die geld opleveren, niet bij een checklist die je 200 onbenullige fixes oplegt.

Een B2B-site is ook geen webshop. Je hebt geen tienduizend productpagina’s die allemaal moeten renderen; je hebt een handvol pagina’s die echt tellen. Dat maakt het behapbaar. Een technische SEO checklist doorlopen of een SEO-audit laten doen, geeft je in een paar uur duidelijkheid over of Google je geld-pagina’s wel correct ziet.

Veelgestelde vragen over JavaScript SEO

Kan Google mijn JavaScript-content indexeren?

Ja, Google kan JavaScript renderen en de resulterende HTML indexeren. Maar dat gebeurt in een aparte stap die kan falen, bijvoorbeeld door geblokkeerde bestanden of tegenstrijdige directives. Vertrouw er dus niet blind op en controleer het via de URL-inspectie in Search Console.

Wat is het verschil tussen ruwe en gerenderde HTML?

Ruwe HTML is wat de server stuurt voordat JavaScript draait. Gerenderde HTML is wat je ziet nadat JavaScript is uitgevoerd. Belangrijke elementen die alleen in de gerenderde versie staan (titel, H1, tekst, links), lopen risico als de rendering een keer mislukt.

Hoe weet ik of mijn site een rendering-probleem heeft?

Vergelijk de twee versies. Gebruik de URL-inspectie in Google Search Console of een crawler zoals Screaming Frog en kijk of je belangrijkste content, titels en links in de gerenderde HTML staan die Google ophaalt.

Is server-side rendering altijd beter?

Voor SEO meestal wel: de crawler krijgt een complete pagina zonder extra renderstap, dus er kan minder misgaan. Het is ook gunstig voor laadsnelheid. Voor de meeste B2B-sites is het de veiligste keuze.

Laat checken of Google je belangrijkste pagina’s écht ziet

JavaScript SEO is geen academische oefening: als Google je dienstpagina niet rendert, verlies je leads zonder dat je het merkt. Wij kijken eerst naar de pagina’s die omzet opleveren, vertellen je eerlijk of er een echt probleem is, en lossen alleen op wat ertoe doet. Geen lijst van 200 cosmetische fixes, wel een site die Google volledig kan lezen.

Plan je gratis intake