Technische SEO-checklist: wat elke website op orde moet hebben

Waarom techniek eerst komt

Content schrijven voor een website met een technisch gebrek, is water naar de zee dragen. Een pagina die niet geïndexeerd wordt, scoort niet, hoe goed de tekst er ook op staat. Een site die traag laadt, verliest bezoekers voordat ze ook maar één woord hebben gelezen. Google onderzocht dat zelf al in 2016 via DoubleClick by Google: 53% van de mobiele bezoekers verlaat een pagina die langer dan drie seconden nodig heeft om te laden. Dat onderzoek dateert uit een tijd waarin mobiel internet trager was dan nu, maar het onderliggende mechanisme (snelheid is geen esthetische wens maar een directe omzetfactor) is sindsdien alleen maar belangrijker geworden, niet minder, omdat concurrenten inmiddels wel sneller zijn geworden.

Het probleem met technische SEO is dat de gevolgen zelden direct zichtbaar zijn. Een gebroken canonical-tag of een per ongeluk geblokkeerde productcategorie leidt niet tot een duidelijke foutmelding, maar tot langzaam wegzakkend verkeer dat niemand aan de juiste oorzaak koppelt. Vandaar het belang van een periodieke check, niet alleen bij lancering.

Core Web Vitals: de exacte normen

Sinds 12 maart 2024 is Interaction to Next Paint (INP) de officiële maatstaf voor interactiviteit binnen de Core Web Vitals, ter vervanging van de oudere First Input Delay (FID). Google's eigen documentatie op web.dev geeft de volgende exacte normen, gemeten op het 75e percentiel van paginabezoeken:

Metriek	Wat het meet	Goed	Matig	Slecht
LCP (Largest Contentful Paint)	Laadtijd van het grootste zichtbare element	≤ 2.500 ms	2.500–4.000 ms	> 4.000 ms
INP (Interaction to Next Paint)	Reactiesnelheid op interactie	≤ 200 ms	200–500 ms	> 500 ms
CLS (Cumulative Layout Shift)	Visuele stabiliteit tijdens laden	≤ 0,1	0,1–0,25	> 0,25

Een pagina geldt pas als "goed" wanneer minimaal 75% van de gemeten bezoeken binnen de goede drempel valt. Een paar snelle testbezoeken vanaf kantoor-wifi zeggen dus niets, het gaat om de werkelijke spreiding van echte bezoekers, inclusief iedereen op een matig mobiel netwerk onderweg, wat voor e-commerce vaak een aanzienlijk deel van het verkeer is.

Twee echte cases: Rakuten en NDTV

Dit soort normen blijft abstract totdat er een concrete uitkomst tegenover staat. Google publiceert zelf, via het web.dev-platform, case studies van bedrijven die hun Core Web Vitals daadwerkelijk hebben verbeterd en de resultaten openbaar hebben gemaakt. Rakuten 24, onderdeel van de grote Japanse e-commercegroep Rakuten, zag na het optimaliseren van zijn Core Web Vitals de omzet per bezoeker met 53,37% stijgen, en de conversieratio met 33,13%. NDTV, een van de grootste nieuwssites van India, realiseerde een verbetering van 55% in de LCP-tijd na gerichte optimalisatie.

Deze cijfers zijn uitzonderlijk hoog, en het zou oneerlijk zijn te suggereren dat elke webshop dezelfde procentuele winst kan verwachten: beide bedrijven startten vanaf een relatief trage uitgangssituatie, en hoe trager het startpunt, hoe groter doorgaans de relatieve winst van optimalisatie. Wat deze cases wél overtuigend aantonen, is dat het verband tussen laadsnelheid en omzet niet theoretisch is, maar in de praktijk, bij grote en zorgvuldig gemeten implementaties, daadwerkelijk zo groot kan uitpakken.

Crawlbaarheid en indexatie

Voordat een pagina kan scoren, moet Google hem kunnen vinden, lezen en willen opnemen in de index. Dat klinkt vanzelfsprekend, maar gaat op meer sites mis dan je zou verwachten.

Check	Waarop te letten
Robots.txt	Geen belangrijke secties per ongeluk uitgesloten (vaak een restant van een testomgeving)
XML-sitemap	Actueel, zonder dode links, automatisch bijgewerkt bij nieuwe pagina's
Canonical-tags	Wijzen naar de juiste, unieke versie van elke pagina
Noindex-tags	Alleen bewust gebruikt, niet als restant van ontwikkeling
Interne 404's	Periodiek gecontroleerd en doorverwezen of hersteld

Een concreet auditproces, stap voor stap

Een technische audit die daadwerkelijk iets oplevert, volgt een vaste volgorde in plaats van willekeurig problemen op te sporen. Eerst een volledige crawl met een tool als Screaming Frog SEO Spider, die in enkele minuten alle interne links, statuscodes, canonical-tags en metadata van de site in kaart brengt; dit legt structurele problemen bloot die met het blote oog nooit opvallen, zoals honderden pagina's die naar een niet-bestaande URL verwijzen. Vervolgens een vergelijking met Google Search Console: welke pagina's zijn daadwerkelijk geïndexeerd versus welke hadden dat moeten zijn, en op welke pagina's daalt het aantal vertoningen structureel, wat vaak een vroeg signaal is van een probleem voordat het verkeer zelf al zichtbaar daalt. Daarna een snelheidsmeting via PageSpeed Insights, specifiek op basis van echte veldgegevens (Chrome UX Report) in plaats van alleen een eenmalige labtest, omdat labtests systematisch gunstiger uitvallen dan de werkelijke ervaring van bezoekers op wisselende netwerken en apparaten. Tot slot, voor grotere sites, een aanvullende audit met Ahrefs Site Audit, dat specifiek goed is in het signaleren van interne linkstructuur-problemen over duizenden pagina's heen.

De volgorde is bewust: een crawl eerst, omdat die in enkele minuten de grootste structurele problemen blootlegt zonder dat er al naar snelheid of content hoeft te worden gekeken. Wie begint met een snelheidsmeting op een site met honderden niet-geïndexeerde productpagina's, optimaliseert de verkeerde laag eerst: een razendsnelle pagina die niet in de index staat, levert nul organisch verkeer op, hoe goed de LCP-score ook is.

Het JavaScript-renderingprobleem

Een technisch probleem dat bij moderne webshops steeds vaker over het hoofd wordt gezien, zit in hoe content wordt opgebouwd. Platforms die zwaar leunen op JavaScript om content te renderen (bepaalde maatwerk-Shopify-thema's, of custom React-lagen bovenop WooCommerce) laden hun belangrijkste tekst en links soms pas ná de eerste weergave van de pagina, via code die in de browser wordt uitgevoerd. Googlebot kan JavaScript inmiddels renderen, maar doet dat in een tweede, vertraagde fase van het crawlproces, en niet elke pagina komt gegarandeerd aan die tweede fase toe, zeker niet op grotere sites met een beperkt crawlbudget. Het resultaat: een productpagina die voor een menselijke bezoeker er prima uitziet, maar waarvan de productbeschrijving, specificaties of interne links voor Google pas laat of helemaal niet zichtbaar worden.

De praktische test is eenvoudig: bekijk een pagina via Google Search Console's URL-inspectietool, specifiek de gerenderde HTML die daar wordt getoond, en vergelijk die met wat een bezoeker in de browser daadwerkelijk ziet. Ontbreekt er tekst, een prijsvermelding of een interne link in die gerenderde versie die wel zichtbaar is voor een bezoeker, dan is dat een concreet, oplosbaar probleem, meestal door kerncontent server-side te renderen in plaats van volledig afhankelijk te maken van client-side JavaScript.

Crawlbudget en logbestand-analyse

Voor kleinere sites met een paar honderd pagina's is crawlbudget zelden een probleem: Google heeft ruim voldoende capaciteit om alles regelmatig te bezoeken. Zodra een webshop uitgroeit naar duizenden productpagina's, inclusief filtercombinaties die elk hun eigen URL genereren (denk aan een productoverzicht gefilterd op merk, smaak en verpakkingsgrootte tegelijk), verandert dat. Google besteedt een beperkt, impliciet "budget" aan crawlbezoeken per site, en als dat budget grotendeels opgaat aan duizenden laagwaardige filtervariaties, blijven de daadwerkelijk belangrijke pagina's (nieuwe producten, bijgewerkte content) onderbelicht.

Logbestand-analyse, het daadwerkelijk doorzoeken van de ruwe serverlogs op bezoeken van Googlebot, is de enige manier om dit met zekerheid vast te stellen in plaats van te vermoeden. Een logbestand laat precies zien welke URL's Googlebot bezoekt, hoe vaak, en welke statuscode daarbij wordt teruggegeven. Vindt een groot deel van die bezoeken plaats op URL's die feitelijk nutteloos zijn voor SEO (gefilterde variaties, interne zoekresultaten, sessie-parameters), dan is het blokkeren daarvan via robots.txt of canonical-tags geen marginale verbetering, maar een directe manier om crawlcapaciteit vrij te maken voor wat er daadwerkelijk toe doet.

Redirect-ketens: de stille snelheidsmoordenaar

Een enkele 301-redirect kost nauwelijks iets. Een keten van drie of vier redirects achter elkaar (URL A verwijst naar B, die verwijst naar C, die uiteindelijk naar D verwijst) kost zowel laadtijd als een deel van de linkwaarde die bij elke stap een klein beetje verdampt. Dit soort ketens ontstaat vrijwel altijd onbedoeld: een productpagina wordt hernoemd, krijgt een redirect naar de nieuwe URL, en een jaar later wordt diezelfde nieuwe URL opnieuw hernoemd zonder dat de eerste redirect wordt bijgewerkt. Na een paar jaar en een paar herstructureringen heeft een gemiddelde webshop tientallen van dit soort ketens, onzichtbaar voor een bezoeker die uiteindelijk toch op de juiste pagina terechtkomt, maar wel meetbaar in zowel laadtijd als crawlefficiëntie. Een crawl met Screaming Frog, specifiek gefilterd op redirect-ketens van twee stappen of meer, brengt dit in een paar minuten in kaart; de oplossing is simpel (elke redirect direct naar de uiteindelijke bestemming laten wijzen) maar wordt zelden structureel gedaan.

Technische SEO-mythes die niet kloppen

Niet alles wat als technische SEO-wijsheid wordt gedeeld, houdt stand. "Meer backlinks lossen alles op" is een hardnekkige mythe: een site met een gebroken crawlstructuur of een trage checkout profiteert nauwelijks van extra autoriteit, omdat het onderliggende probleem (bezoekers of crawlers die vastlopen) onopgelost blijft. "Schema-markup is altijd nodig voor goede rankings" is eveneens te stellig: structured data helpt machines een pagina correct te interpreteren, maar is zelden doorslaggevend voor de klassieke ranking zelf, en welke schema-types daadwerkelijk tot zichtbare rich results leiden, verandert bovendien regelmatig. En "keyword density moet een bepaald percentage zijn" is een idee uit een tijdperk waarin zoekmachines nog vooral op letterlijke woordmatches draaiden; moderne systemen begrijpen semantische samenhang ruim voldoende om dit soort mechanische optimalisatie overbodig, en soms zelfs schadelijk voor de leesbaarheid, te maken.

Structuur en interne links

Een logische structuur helpt niet alleen bezoekers, het helpt ook zoekmachines om te begrijpen welke pagina's het belangrijkst zijn. Een hiërarchie waarin categoriepagina's goed verbonden zijn met subcategorieën en productpagina's, verdeelt autoriteit door de site op een manier die een platte, ongestructureerde site nooit bereikt. Interne links zijn hierin het meest onderbenutte instrument: een nieuw artikel dat ergens op de site "los" wordt gepubliceerd, zonder links vanuit relevante bestaande pagina's en zonder links terug naar die pagina's, bouwt nauwelijks autoriteit op. Zie bijvoorbeeld hoe dit speelt bij e-commerce-structuren, waar categoriepagina's vaak node zijn in een grotere interne linkstructuur.

Mobiel en beveiliging

Google indexeert mobile-first: de mobiele versie van een pagina is bepalend, niet de desktopversie. Een site die op desktop prima werkt maar op mobiel traag laadt of onhandig te bedienen is, wordt daardoor direct benadeeld, vooral gezien de INP-normen hierboven die onder mobiele omstandigheden sneller worden overschreden dan op een snelle desktop-verbinding. Daarnaast is een geldig SSL-certificaat inmiddels een basisvereiste, geen extra.

Welke technische fix je als eerste doet

Met een auditrapport vol bevindingen is de vraag niet wat er allemaal kan verbeteren, maar wat eerst. De volgorde die in de praktijk het meeste oplevert: eerst indexatieproblemen (een pagina die niet in de index staat, levert sowieso nul verkeer op, ongeacht hoe goed de rest is), dan crawlbaarheid en crawlbudget bij grotere sites, dan JavaScript-renderingproblemen op cruciale pagina's zoals productcategorieën, dan pas de Core Web Vitals-optimalisatie zelf. Dat is een andere volgorde dan de meeste generieke checklists aanhouden, die vaak met snelheid beginnen omdat dat het meest meetbare en zichtbare resultaat oplevert. Snelheid optimaliseren op een pagina die niet geïndexeerd is, is tijd die nergens aan bijdraagt.

Een technisch gezonde basis is wat autoriteit en vertrouwen pas echt laat landen, zoals de Rakuten- en NDTV-cijfers hierboven concreet laten zien. Zodra die basis staat, wordt het zinvol om te kijken naar hoe E-E-A-T in de praktijk werkt, met name voor content in een gevoelige categorie zoals voeding en gezondheid.