JavaScript SEO

JavaScript maakt websites krachtiger.

Pagina’s worden interactiever.
Filters werken soepeler.
Content kan dynamisch worden ingeladen.
Webshops voelen meer als applicaties.
Dashboards, calculators, configurators en platforms worden mogelijk.

Maar voor SEO ontstaat er ook een risico.

Niet omdat JavaScript slecht is.

Dat is het niet.

Het risico ontstaat wanneer belangrijke content, links, metadata of technische signalen pas zichtbaar worden nadat JavaScript is uitgevoerd.

Voor een gebruiker lijkt alles dan goed.

De pagina opent.
De app laadt.
De content verschijnt.
Het menu werkt.
De knoppen reageren.

Maar een crawler ziet misschien eerst alleen dit:

<div id="app"></div>
<script src="/main.js"></script>

Voor een browser is dat vaak genoeg.

Voor SEO is het kwetsbaar.

Want voordat de volledige pagina zichtbaar wordt, moet er van alles goed gaan.

JavaScript moet geladen worden.
JavaScript moet uitgevoerd worden.
API-calls moeten slagen.
Content moet in de DOM terechtkomen.
Links moeten als echte links beschikbaar zijn.
Metadata moet correct staan.
Statuscodes moeten kloppen.
En de crawler moet überhaupt bereid en in staat zijn om dit allemaal te renderen.

Google kan JavaScript vaak verwerken.

Maar dat betekent niet dat je SEO-kritieke content afhankelijk wilt maken van client-side JavaScript.

De betere basis is:

belangrijke content, links en SEO-signalen staan zo vroeg en robuust mogelijk in de HTML.

JavaScript mag daar functionaliteit aan toevoegen.

Maar het moet de vindbaarheid niet dragen.

Dat is de kern van JavaScript SEO.

🧭 Waarom JavaScript SEO belangrijk is

JavaScript SEO is belangrijk omdat moderne websites steeds vaker worden opgebouwd met frameworks, componenten, API’s en client-side interacties.

Denk aan websites met:

• React
• Vue
• Angular
• Svelte
• Next.js
• Nuxt
• SvelteKit
• Astro
• Remix
• headless CMS’en
• single-page applications
• client-side routing
• productfilters
• infinite scroll
• dynamische voorraad
• interactieve configurators
• JavaScript-gegenereerde metadata
• API-gedreven content

Dat kan allemaal prima werken.

Maar voor SEO moet je steeds dezelfde vraag blijven stellen:

wat krijgt een crawler daadwerkelijk te zien?

Niet wat jij ziet in je browser.

Niet wat de developer ziet na het laden van de app.

Niet wat uiteindelijk op het scherm verschijnt na drie scripts, twee API-calls en een hydratiefase.

Maar:

wat staat er in de eerste HTML-response?
Wat staat er na rendering in de DOM?
Welke links zijn crawlbaar?
Welke metadata is aanwezig?
Welke statuscode geeft de server terug?
Welke content kan Google, Bing of een AI-crawler echt verwerken?

Daar gaat JavaScript SEO over.

Een JavaScript-site kan er perfect uitzien en alsnog SEO-problemen hebben.

Bijvoorbeeld omdat:

• belangrijke tekst pas na rendering verschijnt
• interne links geen echte href hebben
• een productpagina zonder productdata eerst als lege app-shell laadt
• een verwijderde route alsnog een 200-status geeft
• een canonical via JavaScript wordt aangepast
• structured data alleen soms wordt geïnjecteerd
• content pas na scroll of klik wordt geladen
• een API-fout zorgt voor een lege pagina
• Google het wel kan renderen, maar andere crawlers niet

Daarom is JavaScript SEO geen detail.

Het is een belangrijk onderdeel van technische SEO.

Zeker bij moderne websites.

⚙️ Wat JavaScript SEO is

JavaScript SEO is het optimaliseren van JavaScript-gedreven websites zodat zoekmachines belangrijke content kunnen crawlen, renderen, begrijpen en indexeren.

Het gaat dus niet alleen om JavaScript “werkend” krijgen.

Het gaat om vindbaarheid.

Een JavaScript-implementatie is SEO-technisch goed wanneer belangrijke onderdelen betrouwbaar beschikbaar zijn voor crawlers.

Denk aan:

• hoofdcontent
• headings
• interne links
• navigatie
• productinformatie
• categoriecontent
• reviews
• FAQ’s
• afbeeldingen
• video’s
• title tags
• meta descriptions
• canonicals
• robots meta tags
• structured data
• statuscodes
• paginering
• filters
• foutpagina’s

JavaScript SEO kijkt vooral naar de kloof tussen:

wat een gebruiker uiteindelijk ziet

en:

wat een crawler technisch ontvangt en verwerkt

Die kloof kan klein zijn.

Bijvoorbeeld bij een server-side rendered website waar JavaScript vooral interactie toevoegt.

Maar die kloof kan ook enorm zijn.

Bijvoorbeeld bij een single-page application waarbij de eerste HTML bijna leeg is en alle content later via JavaScript en API’s wordt opgebouwd.

Dan moet je extra goed controleren of SEO-kritieke content wel echt beschikbaar is.

🕷️ Hoe Google JavaScript verwerkt

Google verwerkt JavaScript-pagina’s grofweg in drie stappen:

🧭 Crawlen

Googlebot haalt een URL op.

De server stuurt een HTML-response terug.

Daarin kan al volledige content staan.

Maar bij JavaScript-sites staat er soms vooral een app-shell:

<html>
  <head>
    <title>Voorbeeldpagina</title>
  </head>
  <body>
    <div id="app"></div>
    <script src="/assets/app.js"></script>
  </body>
</html>

In deze eerste fase kan Google al links uit de HTML ontdekken.

Voor klassieke websites en server-side rendered pagina’s werkt dit meestal goed, omdat de belangrijkste content en links direct in de HTML staan.

Bij client-side rendered sites is dat minder zeker.

Daar moet Google eerst verder.

🖥️ Renderen

Tijdens rendering voert Google JavaScript uit.

Daarna ontstaat de rendered HTML.

Dat is de DOM nadat scripts zijn uitgevoerd, componenten zijn geladen en content eventueel via API’s is opgehaald.

Bijvoorbeeld:

<div id="app">
  <main>
    <h1>Hardloopschoenen voor heren</h1>
    <p>Bekijk onze collectie hardloopschoenen voor training en wedstrijden.</p>
    <a href="/hardloopschoenen/nike/">Nike hardloopschoenen</a>
    <a href="/hardloopschoenen/asics/">ASICS hardloopschoenen</a>
  </main>
</div>

Dat is al een stuk beter.

Maar dan moet rendering dus wel lukken.

En dat is precies waar JavaScript SEO gevoelig wordt.

📦 Indexeren

Na rendering gebruikt Google de rendered HTML om content te verwerken, links opnieuw te ontdekken en de pagina beter te begrijpen.

Dat betekent dat Google JavaScript-content kan meenemen.

Maar het betekent niet dat alles altijd even snel, volledig of foutloos gaat.

Rendering voegt een extra stap toe.

En elke extra stap is een extra afhankelijkheid.

Daarom blijft server-side of statisch beschikbare content vaak robuuster voor SEO.

🧱 HTML response versus rendered HTML

Een van de belangrijkste checks bij JavaScript SEO is het verschil tussen de HTML response en de rendered HTML.

Die twee zijn niet altijd hetzelfde.

De HTML response is wat de server direct terugstuurt.

De rendered HTML is wat ontstaat nadat JavaScript is uitgevoerd.

Bij een traditionele pagina kan de HTML response al vrijwel alles bevatten:

<h1>Wat is technische SEO?</h1>
<p>Technische SEO zorgt ervoor dat zoekmachines je website goed kunnen crawlen, renderen en indexeren.</p>
<a href="/robots-txt/">Robots.txt begrijpen</a>
<a href="/xml-sitemap/">XML-sitemap maken</a>

Bij een client-side rendered app kan de HTML response veel leger zijn:

<div id="root"></div>
<script src="/main.js"></script>

Voor een gebruiker hoeft dat geen probleem te zijn.

De browser voert JavaScript uit en bouwt de pagina op.

Maar voor SEO moet je controleren wat er na rendering gebeurt.

Staat de H1 erin?
Staat de hoofdtekst erin?
Zijn interne links zichtbaar?
Klopt de canonical?
Staat structured data in de DOM?
Worden afbeeldingen geladen?
Zijn foutpagina’s herkenbaar?
Is de content afhankelijk van een API die soms faalt?

JavaScript SEO begint vaak met deze vergelijking.

Niet ingewikkelder maken dan nodig.

Eerst kijken:

wat staat er direct in de HTML?

Daarna:

wat staat er pas na rendering?

En dan:

wat mag absoluut niet ontbreken als rendering vertraagt, mislukt of niet wordt uitgevoerd?

🚨 Waarom belangrijke content niet pas na JavaScript zichtbaar moet zijn

Dit is misschien het belangrijkste punt van het hele artikel.

SEO-kritieke content wil je niet pas na client-side JavaScript zichtbaar maken.

Ook niet als de JavaScript goed gebouwd is.

Ook niet als Google het meestal kan renderen.

Ook niet als het in jouw browser perfect werkt.

Waarom niet?

Omdat je dan afhankelijk wordt van een keten.

De crawler moet de HTML ophalen.
De JavaScript-bestanden moeten bereikbaar zijn.
De scripts moeten compatibel zijn.
De renderomgeving moet de pagina goed verwerken.
API-calls moeten lukken.
Content moet op tijd geladen worden.
Er mogen geen JavaScript-errors optreden.
De uiteindelijke DOM moet alle belangrijke informatie bevatten.

Dat is veel.

En hoe meer stappen nodig zijn voordat content zichtbaar wordt, hoe groter de kans dat iets vertraagt, ontbreekt of anders wordt geïnterpreteerd.

Wat is SEO-kritieke content?

SEO-kritieke content is alles wat zoekmachines nodig hebben om de pagina goed te begrijpen en te beoordelen.

Bijvoorbeeld:

• hoofdtekst
• H1 en belangrijke headings
• productinformatie
• categoriecontent
• diensteninformatie
• prijzen en voorraad wanneer relevant
• reviews
• FAQ-content
• interne links
• breadcrumbs
• paginering
• title tag
• meta description
• canonical
• robots meta tag
• structured data
• belangrijke afbeeldingen
• video-informatie
• statuscode en foutafhandeling

Die onderdelen wil je zo robuust mogelijk aanbieden.

Liefst direct in server-rendered of statisch gegenereerde HTML.

JavaScript mag daarna zorgen voor interactie.

Bijvoorbeeld filters verfijnen, tabs openen, formulieren valideren, favorieten opslaan of extra dynamiek toevoegen.

Maar de basisinhoud van een SEO-pagina moet niet afhankelijk zijn van een succesvolle client-side render.

Progressieve verrijking is sterker

Een goede vuistregel:

HTML draagt de inhoud.
CSS verzorgt de presentatie.
JavaScript voegt interactie toe.

Dat is niet ouderwets.

Dat is robuust.

Zeker voor SEO.

Een productpagina moet zonder client-side JavaScript al duidelijk maken welk product het is. Een categoriepagina moet zonder client-side JavaScript al producten, tekst en interne links kunnen tonen. Een kennisbankartikel moet zonder client-side JavaScript al leesbare content bevatten.

Daarna mag JavaScript de ervaring beter maken.

Sneller filteren.
Gerelateerde content tonen.
Interactieve elementen toevoegen.
Een calculator activeren.
Een vergelijker openen.

Maar niet:

eerst een lege pagina.

Dan pas de inhoud.

🤖 Waarom AI-crawlers en andere zoekmachines extra gevoelig zijn

Google is relatief goed in JavaScript-rendering.

Maar Google is niet de enige crawler.

Je hebt ook:

• Bing
• andere zoekmachines
• prijsvergelijkers
• social crawlers
• SEO-tools
• AI-crawlers
• answer engines
• archiveringsbots
• preview-generators
• interne crawlers
• monitoringtools

Die verwerken JavaScript niet allemaal op dezelfde manier.

Sommige crawlers renderen JavaScript beperkt.
Sommige doen het langzaam.
Sommige doen het alleen onder bepaalde voorwaarden.
Sommige doen het helemaal niet.

Dat maakt client-side-only content kwetsbaar.

Bing heeft eerder aangegeven JavaScript in het algemeen te kunnen renderen, maar ook dat het lastig is om JavaScript op schaal voor elke pagina van elke website te verwerken. En bij AI-crawlers is het risico nog duidelijker: in analyses van Vercel en MERJ werd bij grote AI-crawlers zoals GPTBot, ClaudeBot en PerplexityBot geen JavaScript-rendering waargenomen. Dat betekent niet dat crawlergedrag nooit verandert, maar wel dat je er niet blind op moet vertrouwen dat AI-systemen dezelfde rendering doen als Google.

Daarom wordt server-rendered of statisch beschikbare HTML steeds belangrijker.

Niet alleen voor klassieke SEO.

Ook voor zichtbaarheid in AI-zoekervaringen, AI-antwoorden en systemen die webcontent ophalen, samenvatten of gebruiken als bron.

Als je belangrijkste content alleen na JavaScript verschijnt, kan een crawler een veel armere versie van je pagina zien.

Of bijna niets.

En dat is precies wat je wilt voorkomen.

🧩 Wanneer JavaScript SEO-problemen veroorzaakt

JavaScript veroorzaakt vooral SEO-problemen wanneer het de basislaag van je pagina overneemt.

Niet wanneer het alleen interactie toevoegt.

Een uitklapmenu met JavaScript is meestal geen probleem.
Een formulier met JavaScript-validatie ook niet.
Een calculator die interactief wordt na het laden kan prima.

Maar JavaScript wordt risicovol wanneer belangrijke SEO-onderdelen afhankelijk zijn van rendering.

Bijvoorbeeld:

• content verschijnt pas na API-calls
• HTML bevat alleen een lege app-root
• links worden opgebouwd met klikhandlers zonder echte href
• routes werken alleen met hash-URL’s
• filters maken belangrijke pagina’s zonder crawlbare URL
• infinite scroll heeft geen paginering of links
• canonicals worden via JavaScript gewijzigd
• metadata wordt pas na rendering gezet
• structured data wordt alleen soms geïnjecteerd
• foutpagina’s geven een 200-status terug
• verwijderde producten worden soft 404’s
• afbeeldingen verschijnen pas na interactie
• content staat achter scripts die crawlers niet goed verwerken
• JavaScript-errors breken de pagina voor crawlers
• API’s blokkeren bots of reageren anders
• scripts worden geblokkeerd in robots.txt
• rendering duurt te lang of vraagt te veel resources

Het lastige is:

veel van deze problemen zie je niet als je gewoon naar de website kijkt.

De pagina lijkt te werken.

Maar technisch ontvangt een crawler iets anders.

Daarom moet je JavaScript SEO altijd testen vanuit crawlerperspectief.

Niet alleen vanuit gebruikersperspectief.

🔄 Renderingstrategieën: CSR, SSR, SSG en hydration

Niet elke JavaScript-site werkt hetzelfde.

De renderingstrategie bepaalt waar en wanneer HTML wordt opgebouwd.

Dat is belangrijk voor SEO.

🧑‍💻 Client-side rendering

Bij client-side rendering wordt de pagina grotendeels in de browser opgebouwd.

De server stuurt vaak een minimale HTML-response terug.

Daarna downloadt de browser JavaScript, voert het script uit, haalt data op en bouwt de pagina op.

Voorbeeld:

<div id="app"></div>
<script src="/bundle.js"></script>

Voordeel:

het geeft veel vrijheid voor interactieve applicaties.

Nadeel:

SEO-kritieke content is mogelijk niet direct beschikbaar.

Client-side rendering kan prima zijn voor onderdelen waarvoor SEO minder belangrijk is.

Denk aan:

• dashboards achter login
• interactieve tools
• accountomgevingen
• interne applicaties
• configurators waarvan de basispagina al indexeerbaar is

Maar voor publieke SEO-pagina’s is pure client-side rendering vaak niet de sterkste basis.

Zeker niet voor:

• categoriepagina’s
• productpagina’s
• dienstenpagina’s
• blogartikelen
• kennisbankartikelen
• locatiepagina’s
• landingspagina’s
• documentatiepagina’s

Daar wil je dat content direct beschikbaar is.

🖥️ Server-side rendering

Bij server-side rendering wordt HTML op de server opgebouwd.

De gebruiker en crawler krijgen dus al een inhoudelijke HTML-pagina terug.

Daarna kan JavaScript de pagina interactief maken.

Dit is vaak sterk voor SEO.

Omdat de belangrijkste content meteen beschikbaar is.

Bijvoorbeeld:

<main>
  <h1>JavaScript SEO</h1>
  <p>JavaScript SEO helpt zoekmachines om JavaScript-gedreven websites goed te crawlen, renderen en indexeren.</p>
  <a href="/technische-seo/">Technische SEO</a>
</main>
<script src="/app.js"></script>

De pagina is al begrijpelijk vóórdat JavaScript klaar is.

Dat maakt SSR geschikt voor veel SEO-pagina’s.

Vooral wanneer content dynamisch is, maar wel direct vindbaar moet zijn.

Denk aan:

• productpagina’s
• categoriepagina’s
• vacaturepagina’s
• zoekresultaatpagina’s met SEO-waarde
• dashboards met deels publieke data
• platformpagina’s
• marktplaatsen

SSR is geen magische oplossing.

Je moet nog steeds letten op performance, caching, statuscodes, metadata, canonicals en hydration.

Maar de basis is robuuster dan een lege app-shell.

🧊 Static rendering en Static Site Generation

Static rendering betekent dat pagina’s vooraf als HTML worden opgebouwd.

Static Site Generation, vaak afgekort als SSG, is daar een bekende vorm van.

Bij SSG worden pagina’s tijdens build-time gegenereerd.

Daarna staan ze klaar als statische HTML-bestanden.

Dat is vaak heel sterk voor SEO.

Vooral bij content die niet elke seconde verandert.

Denk aan:

• kennisbankartikelen
• blogartikelen
• documentatie
• landingspagina’s
• modulepagina’s
• casepagina’s
• categoriepagina’s met stabiele content
• marketingpagina’s

Voordelen:

• snelle eerste HTML-response
• content direct beschikbaar
• minder afhankelijk van client-side rendering
• vaak goede performance
• makkelijk te cachen
• geschikt voor CDN-delivery

Nadeel:

bij zeer dynamische content moet je goed nadenken over updatefrequentie, rebuilds en cache-invalidering.

Maar voor veel SEO-content is SSG een uitstekende optie.

Zeker voor kennisbanken.

Een kennisbankartikel hoeft meestal niet pas in de browser opgebouwd te worden.

Dat artikel kan gewoon als HTML klaarstaan.

💧 Hydration

Hydration betekent dat de pagina eerst als HTML wordt geleverd en daarna interactief wordt gemaakt met JavaScript.

De gebruiker ziet dus snel content.

Daarna “pakt” JavaScript de pagina over om interacties mogelijk te maken.

Dit kan een sterke balans zijn.

Je krijgt:

• inhoud direct beschikbaar
• betere crawlbaarheid
• snellere eerste weergave
• interactieve componenten na het laden

Maar hydration kan ook zwaar worden.

Vooral wanneer veel JavaScript nodig is om een pagina interactief te maken.

Dan kan je INP verslechteren.

Of je pagina voelt geladen, maar reageert nog traag.

Daarom zie je steeds vaker ideeën als partial hydration, islands architecture en server components. Het doel is steeds hetzelfde:

niet de hele pagina onnodig vol JavaScript gooien.

Maak interactief wat interactief moet zijn.

Laat statisch wat statisch kan zijn.

🚧 Dynamic rendering als tijdelijke workaround

Dynamic rendering betekent dat gebruikers en crawlers technisch een andere renderroute krijgen.

Gebruikers krijgen bijvoorbeeld de normale client-side app.

Crawlers krijgen een vooraf gerenderde HTML-versie.

Dat kan helpen wanneer crawlers moeite hebben met JavaScript-content.

Maar het is meestal geen ideale eindoplossing.

Waarom niet?

Omdat het extra complexiteit toevoegt.

Je moet crawlerdetectie doen.
Je moet twee renderpaden onderhouden.
Je moet zorgen dat crawlers en gebruikers inhoudelijk dezelfde content krijgen.
Je moet caching goed regelen.
Je moet fouten in de pre-renderer monitoren.
Je moet voorkomen dat de botversie achterloopt op de gebruikersversie.

Voor bestaande complexe JavaScript-sites kan dynamic rendering soms tijdelijk helpen.

Maar voor nieuwe projecten is het meestal beter om te kiezen voor SSR, SSG, static rendering of een goede hydration-aanpak.

Dynamic rendering is dus meer noodbrug dan bouwfundament.

🧰 Frameworks: React, Vue, Angular, Next.js, Nuxt en SvelteKit

JavaScript SEO gaat vaak over frameworks.

Maar het framework zelf is meestal niet het echte probleem.

De renderingstrategie is het probleem.

React is niet automatisch slecht voor SEO.
Vue is niet automatisch slecht voor SEO.
Angular is niet automatisch slecht voor SEO.
Svelte is niet automatisch goed of slecht voor SEO.

De vraag is:

welke HTML komt er uit?

React SEO

React wordt vaak client-side gebruikt.

Dan kan SEO kwetsbaar worden als de eerste HTML leeg is en content pas in de browser verschijnt.

Maar React kan ook prima SEO-vriendelijk worden gebruikt.

Bijvoorbeeld met Next.js, SSR, SSG of React Server Components.

React SEO draait dus niet om React vermijden.

Het draait om zorgen dat belangrijke content, links en metadata niet pas afhankelijk zijn van client-side rendering.

Vue SEO

Vue heeft hetzelfde principe.

Een pure client-side Vue-app kan SEO-risico’s geven.

Maar Vue met Nuxt kan server-side of statisch renderen.

Dan wordt de basis veel sterker.

Ook hier geldt:

niet het framework bepaalt de SEO-kwaliteit.

Maar de output.

Angular SEO

Angular wordt vaak gebruikt voor applicatieachtige websites.

Daarbij moet je extra letten op rendering, routing, metadata, statuscodes en performance.

Angular kan met server-side rendering werken, maar je moet het bewust inrichten.

Een Angular-app die alleen client-side routes opbouwt en voor alles een 200-status geeft, kan SEO-problemen veroorzaken.

Next.js, Nuxt, SvelteKit, Astro en Remix

Moderne meta-frameworks zijn vaak beter geschikt voor SEO, omdat ze opties bieden voor SSR, SSG, hydration en server routes.

Denk aan:

• Next.js voor React
• Nuxt voor Vue
• SvelteKit voor Svelte
• Astro voor contentgerichte sites
• Remix voor servergerichte webapplicaties

Maar ook hier geldt:

een framework met goede SEO-mogelijkheden garandeert nog geen goede SEO.

Je kunt in Next.js alsnog verkeerde canonicals zetten.
Je kunt in Nuxt alsnog content client-side ophalen.
Je kunt in SvelteKit alsnog interne links verkeerd bouwen.
Je kunt in Astro alsnog te veel JavaScript laden.

Tools helpen.

Maar implementatie bepaalt het resultaat.

JavaScript versus TypeScript

Of je JavaScript of TypeScript gebruikt, maakt voor SEO niet direct het verschil.

TypeScript helpt developers om robuustere code te schrijven.

Maar crawlers beoordelen geen TypeScript.

Ze beoordelen uiteindelijk:

• HTML
• links
• metadata
• content
• statuscodes
• structured data
• rendering
• performance

TypeScript kan dus indirect helpen door minder bugs te veroorzaken.

Maar het is geen SEO-factor op zichzelf.

🔗 Links en routing in JavaScript-sites

Links zijn essentieel voor SEO.

Zo ontdekken crawlers nieuwe URL’s.
Zo begrijpen ze structuur.
Zo stroomt interne linkwaarde door je website.

Bij JavaScript-sites gaat dit vaak mis.

Voor belangrijke interne links wil je echte HTML-links gebruiken.

Dus:

<a href="/diensten/seo/">SEO diensten</a>

Niet alleen:

<button onclick="goToSeoPage()">SEO diensten</button>

Of:

<div onclick="navigate('/diensten/seo/')">SEO diensten</div>

Een gebruiker kan daar misschien prima mee navigeren.

Maar voor crawlers is het minder robuust.

Gebruik echte href-links

Voor belangrijke navigatie gebruik je links met een href.

Denk aan:

• menu-items
• categorieën
• breadcrumbs
• paginering
• gerelateerde artikelen
• productlinks
• dienstenlinks
• footerlinks
• interne links in tekst
• filterpagina’s met SEO-waarde

JavaScript mag de klik daarna intercepten voor een soepele ervaring.

Maar de link moet ook als gewone link bestaan.

Dat is de veilige basis.

Vermijd hash-routing voor SEO-pagina’s

Sommige single-page applications gebruiken hash-routes.

Bijvoorbeeld:

example.com/#/producten
example.com/#/diensten/seo

Voor belangrijke SEO-pagina’s is dat niet ideaal.

Gebruik liever normale, crawlbare URL’s:

example.com/producten/
example.com/diensten/seo/

Bij moderne SPA-routing gebruik je meestal de History API, zodat elke belangrijke view een echte URL heeft.

Elke indexeerbare pagina moet zelfstandig werken.

Dus als iemand direct naar de URL gaat, moet de server een correcte response geven.

Niet alleen wanneer iemand via de app navigeert.

Geef belangrijke views eigen URL’s

Een belangrijk principe:

als iets moet ranken, moet het een URL kunnen zijn.

Niet alleen een schermtoestand.

Niet alleen een tab.

Niet alleen een filterstand zonder URL.

Niet alleen een view die alleen na klikken ontstaat.

Voor SEO wil je dat belangrijke pagina’s:

• een unieke URL hebben
• intern gelinkt worden
• een correcte statuscode geven
• eigen metadata hebben
• crawlbare content bevatten
• eventueel een self-referencing canonical hebben

Dat geldt ook voor JavaScript-sites.

Juist daar.

🏷️ Metadata, canonicals en robots meta tags met JavaScript

Metadata is gevoelig bij JavaScript-sites.

Omdat title tags, meta descriptions, canonicals en robots meta tags soms pas via JavaScript worden gezet of aangepast.

Dat kan werken.

Maar het is kwetsbaarder dan metadata die direct in de HTML staat.

Title tags en meta descriptions

Elke indexeerbare pagina moet een duidelijke title tag en meta description hebben.

Bij JavaScript-routing moet je opletten dat metadata per route correct verandert.

Anders krijg je situaties zoals:

• elke route heeft dezelfde title
• productpagina’s tonen de homepage-title
• categoriepagina’s missen een meta description
• metadata verandert pas laat
• metadata klopt wel in de browser, maar niet in de eerste HTML
• crawlers zien een generieke app-title

Voor SEO-pagina’s is het sterker als metadata server-side of statisch wordt meegeleverd.

Canonical tags

Canonicals moeten heel precies zijn.

Een canonical via JavaScript injecteren kan in sommige gevallen werken, maar het is foutgevoelig.

Vooral als er al een canonical in de HTML staat.

Dan kun je conflicten krijgen.

Bijvoorbeeld:

HTML response:

<link rel="canonical" href="https://example.com/producten/" />

JavaScript voegt later toe:

<link rel="canonical" href="https://example.com/producten?kleur=zwart" />

Dat wil je niet.

Een pagina moet één duidelijke canonical hebben.

Liefst direct in de HTML.

Niet afhankelijk van late JavaScript-aanpassingen.

Robots meta tags

Robots meta tags zijn nog gevoeliger.

Vooral noindex.

Als een pagina in de eerste HTML een noindex heeft, moet je er niet op vertrouwen dat JavaScript die later veilig weghaalt.

Dat is een riskant patroon.

Beter:

zet indexeringsinstructies correct aan de serverkant.

Dus:

• indexeerbare pagina’s krijgen geen noindex
• niet-indexeerbare pagina’s krijgen noindex
• foutpagina’s krijgen een passende statuscode of noindex
• tijdelijke states worden niet via rommelige JavaScript opgelost

Robots-instructies zijn geen plek voor improvisatie.

Zeker niet bij JavaScript-sites.

🚦 Statuscodes, soft 404’s en SPAs

Single-page applications hebben vaak een klassiek SEO-probleem:

alles geeft een 200-status.

Ook pagina’s die eigenlijk niet bestaan.

Bijvoorbeeld:

example.com/product/bestaat-niet-meer/

De server geeft 200.

De app laadt.

De API zegt: product niet gevonden.

De gebruiker ziet misschien een foutmelding.

Maar technisch was de response nog steeds 200.

Dat kan een soft 404 veroorzaken.

Google ziet dan een pagina die technisch “oké” lijkt, maar inhoudelijk eigenlijk een foutpagina is.

Dat is rommelig.

Wanneer statuscodes misgaan

Dit gebeurt vaak bij:

• verwijderde producten
• verlopen vacatures
• lege categorieën
• oude blogroutes
• fout gespelde URL’s
• verwijderde gebruikersprofielen
• niet-bestaande SPA-routes
• API-fouten
• filters zonder resultaten

Voor SEO wil je dat foutstatussen technisch kloppen.

Een niet-bestaande pagina hoort meestal een 404 te geven.
Een permanent verwijderde pagina kan soms een 410 geven.
Een verplaatste pagina hoort een redirect te krijgen.
Een tijdelijke fout moet niet als normale indexeerbare pagina blijven bestaan.

Soft 404’s voorkomen

Bij JavaScript-sites voorkom je soft 404’s door foutafhandeling niet alleen in de browser te doen.

De serverroute moet ook begrijpen wat er gebeurt.

Bijvoorbeeld:

• product bestaat niet meer → 404 of redirect
• vacature is verlopen → 404, 410 of archiefstrategie
• categorie heeft geen waarde → noindex of andere route
• oude URL heeft vervanger → 301 redirect
• API geeft geen data → geen indexeerbare lege 200-pagina

Een mooie foutmelding voor gebruikers is goed.

Maar voor SEO moet de technische status ook kloppen.

🖼️ Lazy loading, afbeeldingen en infinite scroll

JavaScript wordt vaak gebruikt voor lazy loading, afbeeldingen en infinite scroll.

Dat kan prima.

Maar het moet crawlbaar blijven.

Lazy loading

Lazy loading is nuttig voor content lager op de pagina.

Maar belangrijke content mag niet alleen verschijnen na gedrag dat crawlers niet goed uitvoeren.

Voor afbeeldingen geldt:

• belangrijke boven-de-vouw-afbeeldingen niet onnodig lazy loaden
• LCP-afbeeldingen snel beschikbaar maken
• afbeeldingen in HTML of rendered HTML beschikbaar houden
• geen lazy loading die afhankelijk is van onbetrouwbare scroll-events
• fallback gebruiken waar nodig

Voor tekstcontent geldt hetzelfde principe.

Een kennisbankartikel moet niet pas tekstblokken ophalen nadat iemand scrolt. Een categoriepagina moet niet pas producten tonen nadat een script beslist dat de gebruiker ver genoeg is. Een FAQ-sectie met SEO-waarde moet niet alleen na klik of late API-call bestaan.

Infinite scroll

Infinite scroll kan fijn zijn voor gebruikers.

Maar voor SEO moet je zorgen dat content ook via crawlbare URL’s bereikbaar is.

Bijvoorbeeld met paginering:

example.com/blog/
example.com/blog/page/2/
example.com/blog/page/3/

Of met crawlbare categorie- en overzichtspagina’s.

Niet alleen:

scroll maar eindeloos, dan verschijnen er vanzelf meer items.

Crawlers scrollen niet altijd zoals gebruikers.

En zelfs als Google bepaalde rendering aankan, wil je belangrijke content niet verstoppen achter eindeloze interactie.

Filters

Filters zijn extra gevoelig.

Een filter kan puur UX zijn.

Bijvoorbeeld:

sorteer op prijs.
toon 24 in plaats van 48 producten.
kleur tijdelijk aanvinken.

Maar sommige filtercombinaties hebben SEO-waarde.

Bijvoorbeeld:

• zwarte hardloopschoenen
• leren hoekbanken
• elektrische stadsfietsen
• blauwe zomerjurken
• tweedehands laptops

Als zo’n filterpagina SEO-waarde heeft, moet hij niet alleen een tijdelijke JavaScript-state zijn.

Dan wil je meestal:

• een stabiele URL
• crawlbare interne links
• eigen metadata
• duidelijke content
• correcte canonical
• indexeerbaarheid waar relevant

JavaScript mag het filter interactief maken.

Maar SEO-waardige filters hebben een echte pagina nodig.

🧩 Structured data in JavaScript-sites

Structured data kan via JavaScript worden toegevoegd.

Maar ook hier geldt:

test wat er na rendering echt staat.

Veel websites injecteren JSON-LD via componenten, templates of tagmanagers.

Dat kan werken.

Maar het kan ook fout gaan.

Bijvoorbeeld:

• structured data ontbreekt op sommige routes
• productdata is leeg door een API-fout
• prijs of voorraad wijkt af van zichtbare content
• FAQ structured data staat er, maar de FAQ-content niet
• meerdere scripts geven conflicterende schema markup
• structured data verschijnt pas na een late client-side render
• templates gebruiken oude of incomplete velden
• canonical en structured data verwijzen naar verschillende URL’s

Structured data moet passen bij de zichtbare content.

Niet bij wat je hoopt dat de pagina is.

Bij JavaScript-sites moet je daarom niet alleen de broncode bekijken.

Je moet de rendered HTML testen.

Gebruik bijvoorbeeld:

• Rich Results Test
• URL-inspectie in Google Search Console
• een crawl met JavaScript-rendering
• handmatige DOM-checks
• templatecontroles

Structured data is het volgende artikel in deze module.

Maar de brug is duidelijk:

als schema markup technisch wordt gegenereerd, moet je zeker weten dat die consistent, zichtbaar en geldig is na rendering.

⚡ JavaScript en Core Web Vitals

JavaScript SEO gaat niet alleen over indexeerbaarheid.

Het gaat ook over performance.

JavaScript kan grote invloed hebben op Core Web Vitals.

Vooral op INP.

Maar ook op LCP en CLS.

INP

INP meet hoe snel een pagina reageert op interacties.

JavaScript speelt daar vaak een hoofdrol.

Te veel JavaScript kan de main thread blokkeren.

Dan voelt een pagina traag bij:

• menu openen
• filter gebruiken
• formulier invullen
• productvariant kiezen
• tab openen
• accordion gebruiken
• checkoutstap doorgaan
• zoekfunctie gebruiken

Een pagina kan visueel geladen lijken, maar toch traag reageren.

Dat is typisch JavaScript-probleem.

LCP

JavaScript kan ook LCP vertragen.

Bijvoorbeeld wanneer:

• hoofdcontent pas client-side wordt opgebouwd
• hero-afbeeldingen pas laat ontdekt worden
• rendering wacht op JavaScript
• CSS en JS de eerste weergave blokkeren
• de pagina eerst een lege app-shell toont
• API-data nodig is voordat content verschijnt

Bij SEO-pagina’s wil je dat de belangrijkste content snel zichtbaar is.

Niet pas nadat een zware JavaScript-bundel klaar is.

CLS

JavaScript kan layout shifts veroorzaken wanneer content later wordt ingevoegd.

Bijvoorbeeld:

• banners
• sliders
• widgets
• reviews
• productblokken
• aanbevelingen
• cookiemeldingen
• dynamically inserted content

Als daar geen ruimte voor is gereserveerd, springt de layout.

Dat is slecht voor gebruikers.

En voor Core Web Vitals.

Third-party scripts

Veel JavaScript komt niet eens uit je eigen codebase.

Denk aan:

• analytics
• tag managers
• chatwidgets
• heatmaps
• A/B-testtools
• advertentiepixels
• personalisatietools
• reviewscripts
• trackingpixels
• social embeds

Elk script lijkt klein.

Tot ze samen de pagina zwaar maken.

Daarom hoort JavaScript SEO ook samen te werken met performance-audits.

Niet alleen:

kan Google de content zien?

Maar ook:

hoeveel JavaScript is nodig om deze pagina bruikbaar te maken?

🧪 Hoe controleer je JavaScript SEO?

JavaScript SEO controleer je niet met één tool.

Je combineert meerdere checks.

Omdat je verschillende lagen wilt begrijpen:

• serverresponse
• broncode
• rendered HTML
• crawlbaarheid
• indexeerbaarheid
• links
• metadata
• structured data
• statuscodes
• performance
• verschillen tussen mobiel en desktop

🔎 Google Search Console URL-inspectie

Gebruik URL-inspectie om te zien hoe Google een URL beoordeelt.

Let op:

• is de pagina indexeerbaar?
• welke canonical ziet Google?
• kan Google de pagina ophalen?
• zijn er crawlproblemen?
• zijn belangrijke resources geblokkeerd?
• hoe ziet de rendered pagina eruit?
• ontstaan er JavaScript-fouten?
• ziet Google de content die je verwacht?

Gebruik ook live testen.

Niet alleen de geïndexeerde versie.

De geïndexeerde versie kan achterlopen.

De live test helpt om te zien wat Google nu kan ophalen en renderen.

🧪 Rich Results Test

De Rich Results Test is handig voor structured data.

Maar ook voor JavaScript SEO.

Je kunt namelijk controleren of structured data na rendering aanwezig is.

Let op:

• wordt JSON-LD gevonden?
• staan de juiste schema types erin?
• ontbreken verplichte velden?
• komen waarden overeen met zichtbare content?
• is structured data aanwezig op alle relevante templates?
• verschilt mobiel van desktop?

Voor JavaScript-sites is dit belangrijk, omdat structured data soms via scripts wordt geïnjecteerd.

Dat moet je niet aannemen.

Dat moet je testen.

🕷️ Screaming Frog met JavaScript-rendering

Een gewone crawl ziet vaak alleen de eerste HTML.

Een JavaScript-rendered crawl laat zien wat er na rendering zichtbaar wordt.

Dat verschil is goud waard.

Vergelijk bijvoorbeeld:

• title tags
• meta descriptions
• H1’s
• canonicals
• meta robots
• word count
• interne links
• statuscodes
• afbeeldingen
• structured data
• response time
• indexability
• hreflang waar relevant

Crawl eerst zonder JavaScript-rendering.

Daarna met JavaScript-rendering.

Kijk waar grote verschillen ontstaan.

Bijvoorbeeld:

zonder rendering: 12 interne links.
met rendering: 248 interne links.

Of:

zonder rendering: geen H1.
met rendering: H1 aanwezig.

Of:

zonder rendering: bijna geen tekst.
met rendering: volledige content.

Dat zegt iets belangrijks.

Niet per se dat alles fout is.

Wel dat je afhankelijk bent van rendering.

En dan moet je bepalen of dat acceptabel is.

🧰 Chrome DevTools

Chrome DevTools helpt bij technische verdieping.

Gebruik vooral:

• Elements
• Network
• Console
• Performance
• Coverage
• Lighthouse

Controleer bijvoorbeeld:

• welke API-calls content ophalen
• of scripts fouten geven
• wanneer content verschijnt
• welke bestanden groot zijn
• of afbeeldingen laat ontdekt worden
• of JavaScript de main thread blokkeert
• hoeveel ongebruikte JavaScript wordt geladen
• of metadata in de DOM verandert
• of links echte href-links zijn

DevTools is vooral nuttig wanneer je weet dát er iets misgaat, maar nog niet waarom.

🔁 HTML response vergelijken met rendered HTML

Dit is misschien de belangrijkste handmatige check.

Bekijk eerst de broncode.

In Chrome:

rechtermuisknop → View Page Source.

Daarna bekijk je de rendered DOM.

In Chrome:

Inspect → Elements.

Vergelijk:

• staat de H1 al in de broncode?
• staat hoofdcontent al in de broncode?
• staan interne links al in de broncode?
• staat de canonical al in de broncode?
• staat structured data al in de broncode?
• wat komt pas na JavaScript?
• wat ontbreekt ook na rendering?

Voor SEO-kritieke pagina’s wil je dat de belangrijkste onderdelen niet alleen na rendering bestaan.

Zeker niet bij pagina’s die moeten ranken.

🤖 Test met crawlers die geen JavaScript uitvoeren

Omdat niet elke crawler JavaScript rendert, is het nuttig om ook zonder rendering te testen.

Gebruik bijvoorbeeld:

• gewone HTML-fetch
• command line tools
• SEO-crawls zonder rendering
• text-only checks
• robots/user-agent tests
• server logs

Vraag jezelf af:

wat blijft er over als JavaScript niet wordt uitgevoerd?

Als het antwoord is:

bijna niets

dan is dat een risico.

Vooral bij belangrijke SEO-content.

📜 Server logs

Server logs laten zien wat crawlers echt ophalen.

Dat is waardevol bij JavaScript SEO.

Je kunt onderzoeken:

• welke bots komen langs?
• halen ze HTML op?
• halen ze JavaScript-bestanden op?
• halen ze API-routes op?
• komen ze op oude assets uit?
• raken ze 404’s?
• volgen ze redirects?
• crawlen ze belangrijke routes?
• besteden ze veel tijd aan onbelangrijke bestanden?

Voor grote websites is dit vaak verhelderend.

Want tools simuleren gedrag.

Logs laten echt gedrag zien.

⚠️ Veelgemaakte fouten met JavaScript SEO

JavaScript SEO gaat vaak mis door aannames.

“Google kan JavaScript toch renderen?”

“De pagina werkt in mijn browser.”

“Next.js is toch SEO-vriendelijk?”

“De content staat er uiteindelijk wel.”

Dat soort aannames zijn gevaarlijk.

Je moet testen.

❌ Een lege HTML-response accepteren voor SEO-pagina’s

Een lege app-shell is kwetsbaar.

Voor applicaties achter login kan dat prima zijn.

Voor SEO-pagina’s meestal niet.

Als een categoriepagina, productpagina of kennisbankartikel moet ranken, wil je belangrijke content directer beschikbaar maken.

❌ Belangrijke content pas na API-calls tonen

API-gedreven content is niet automatisch fout.

Maar als een API-call nodig is voordat de pagina inhoud heeft, ontstaat afhankelijkheid.

Faalt de API?

Dan faalt je content.

Is de API traag?

Dan verschijnt je content laat.

Blokkeert de API crawlers?

Dan zien crawlers niets.

❌ Links bouwen zonder echte href

Klikbare elementen zijn niet altijd links.

Voor SEO wil je echte links.

Gebruik dus geen knoppen, divs of clickhandlers voor belangrijke interne navigatie zonder href.

❌ Hash-routing gebruiken voor belangrijke pagina’s

Routes zoals #/producten zijn geen sterke basis voor SEO-pagina’s.

Gebruik normale URL’s en moderne routing.

Elke belangrijke view moet zelfstandig bereikbaar zijn.

❌ Alle SPA-routes een 200-status geven

Niet-bestaande pagina’s moeten geen normale 200-pagina’s zijn.

Anders krijg je soft 404’s.

Zorg dat foutstatussen technisch kloppen.

❌ Canonicals via JavaScript laten conflicteren

Een canonical in de HTML en een andere canonical via JavaScript is rommelig.

Maak één duidelijke keuze.

Liefst server-side of statisch in de HTML.

❌ Noindex later via JavaScript proberen te verwijderen

Indexeringsinstructies moeten betrouwbaar zijn.

Als een pagina eerst noindex heeft en JavaScript dat later wijzigt, bouw je een riskant systeem.

Zet robots meta tags liever correct in de serverresponse.

❌ Structured data niet in rendered HTML controleren

Structured data kan via JavaScript worden geïnjecteerd.

Maar dan moet je testen of het ook echt aanwezig en geldig is na rendering.

Niet alleen in je componentlogica.

Niet alleen in je CMS.

In de rendered HTML.

❌ Infinite scroll zonder crawlbare URL’s

Content die alleen via eindeloos scrollen verschijnt, is kwetsbaar.

Zorg dat belangrijke vervolgcontent ook via links en URL’s bereikbaar is.

❌ Filters zonder SEO-strategie bouwen

Niet elke filtercombinatie hoeft indexeerbaar te zijn.

Maar filterpagina’s met zoekwaarde moeten stabiele URL’s, metadata, content, canonicals en interne links hebben.

Anders blijven ze vluchtige JavaScript-states.

❌ JavaScript-performance negeren

Een pagina kan indexeerbaar zijn en toch slecht werken.

Te veel JavaScript kan INP, LCP en gebruikerservaring verslechteren.

SEO gaat niet alleen over gezien worden.

Ook over bruikbaar zijn.

❌ Alleen Google testen

Google is belangrijk.

Maar niet de enige crawler.

Test ook wat zichtbaar is zonder JavaScript.

Zeker nu AI-crawlers, answer engines, social crawlers en andere systemen een grotere rol spelen in hoe content wordt gevonden en gebruikt.

👉 Volgende stap

JavaScript SEO laat goed zien hoe belangrijk technische implementatie is voor vindbaarheid.

Vooral wanneer content, metadata en structured data dynamisch worden opgebouwd.

Daarom gaan we hierna door naar een onderdeel dat vaak technisch wordt gegenereerd, geïnjecteerd en getest:

Schema markup technisch implementeren.

❓ Vragen beantwoord in dit artikel