Technische SEO checklist 2026: 50 punten die écht tellen

De meeste checklists sorteren op onderwerp: eerst crawlen, dan snelheid, dan structured data. Handig om te lezen, onhandig om uit te voeren. Want als punt 34 je hele site uit de index houdt, is al het werk aan punt 1 tot 33 verspilde tijd. Deze technische SEO checklist is daarom gerangschikt op ernst, niet op onderwerp: eerst wat je zichtbaarheid blokkeert, dan wat je crawlbudget verspilt, dan wat je prestaties verzwakt, en pas daarna wat je positie versterkt. Werk hem van boven naar beneden af en je lost de dure problemen eerst op.

Wat is een technische SEO audit, en waarom bepaalt de volgorde alles?

Een technische SEO audit is een systematische controle of zoekmachines je site kunnen bereiken, begrijpen en indexeren, en of de gebruikservaring die controle niet ondermijnt. Het gaat niet over de inhoud van je pagina’s, maar over de infrastructuur eromheen.

De volgorde is geen detail. Technische problemen zijn hiërarchisch: een noindex op een sjabloon maakt elke optimalisatie aan Core Web Vitals op diezelfde pagina’s waardeloos. Onderstaande vier blokken lopen daarom van ernstig naar aanvullend.

Blok 1: Blokkerend: kan Google je site überhaupt bereiken? (punt 1–12)

Deze twaalf punten bepalen of je bestaat in de index. Vind je hier iets, stop dan met de rest en los dit eerst op. Crawlbaarheid en indexatie problemen zijn zelden subtiel: ze kosten meestal alles tegelijk.

1. robots.txt is bereikbaar op de root en geeft een 200-status
2. Geen Disallow: / op productie — de klassieke fout na een livegang vanaf staging
3. Bot-bescherming (WAF, Cloudflare, ratelimiting) blokkeert Googlebot niet; controleer met de URL-inspectie in Search Console
4. Geen onbedoelde noindex in de HTML of in de X-Robots-Tag-header
5. De canonical wijst naar een indexeerbare 200-pagina, niet naar een redirect of 404
6. Elke belangrijke pagina heeft minstens één interne link; geen weespagina’s
7. De XML-sitemap bevat uitsluitend canonieke 200-URL’s en is ingediend in Search Console
8. HTTPS op alle pagina’s, geen mixed content
9. Eén domeinversie leidend; alle andere varianten 301 daarheen
10. Kerncontent staat in de server-HTML, niet uitsluitend in JavaScript
11. Het rapport Pagina-indexering toont geen onverklaarde piek in uitgesloten URL’s
12. Geen soft 404’s: lege of verwijderde pagina’s geven een echte 404 of 410

Google beschrijft in zijn documentatie over robots.txt expliciet dat het bestand bedoeld is om crawlverkeer te sturen en niet om pagina’s uit de index te houden. Wie robots.txt gebruikt om iets te verbergen, bereikt vaak precies het tegenovergestelde.

Blok 2: Verspillend: waar gaat je crawlbudget verloren? (punt 13–24)

Deze punten blokkeren niets, maar leiden Googlebot langs pagina’s die er niet toe doen. Bij kleine sites is dat hinderlijk; bij webshops met filters loopt het snel uit de hand.

13. Redirectketens teruggebracht tot één sprong
14. Interne links wijzen direct naar de eindbestemming, niet naar een redirect
15. Geen 404’s in de interne linkstructuur of in de sitemap
16. Parameter-URL’s (filters, sortering, sessie-ID’s) uitgesloten of gecanonicaliseerd
17. Facetnavigatie genereert geen oneindige URL-combinaties
18. Paginering met unieke titels en self-referencing canonicals
19. Interne zoekresultaatpagina’s niet indexeerbaar
20. Tag- en auteurarchieven alleen indexeren als ze zelfstandige waarde hebben
21. Geen varianten door www, trailing slash of hoofdlettergebruik
22. Staging en testsubdomeinen afgeschermd met authenticatie, niet alleen met robots.txt
23. Dunne of verlopen pagina’s samengevoegd of afgevoerd met een 410
24. Serverlogs gecontroleerd: waar besteedt Googlebot zijn bezoeken werkelijk aan?

Google raadt in de richtlijnen over het samenvoegen van dubbele URL’s af om robots.txt voor canonicalisatie te gebruiken; geblokkeerde URL’s kunnen alsnog zonder inhoud in de index belanden.

Blok 3: Verzwakkend: snelheid en gebruikservaring (punt 25–36)

Site speed SEO is zelden de reden dat je niet rankt, maar wel vaak de reden dat je het net niet wint van een gelijkwaardige concurrent. Google publiceert voor Core Web Vitals concrete drempelwaarden.

25. LCP onder 2,5 seconden
26. INP onder 200 milliseconden
27. CLS onder 0,1
28. Beoordeeld op velddata uit Search Console, niet uitsluitend op labscores
29. De LCP-afbeelding wordt vooraf geladen en níét lazy geladen
30. Expliciete width en height op alle afbeeldingen tegen layout shift
31. Moderne beeldformaten (WebP of AVIF) met responsieve srcset
32. Lettertypen zelf gehost, met font-display: swap
33. Render-blokkerende CSS en JavaScript teruggebracht
34. Overbodige third-party scripts verwijderd; vaak de grootste veroorzaker van slechte INP
35. Caching en compressie (Brotli of gzip) actief op serverniveau
36. TTFB onder controle, ook bij piekbelasting

Blok 4: Versterkend: structuur, data en AI-zichtbaarheid (punt 37–50)

Dit blok maakt je site niet vindbaar, maar wel begrijpelijk. Dat is precies wat er zwaarder is gaan wegen nu antwoordmachines losse alinea’s ophalen in plaats van hele pagina’s.

37. Eén H1 per pagina, met een logische kopstructuur eronder
38. Unieke title en meta description per pagina
39. Korte, sprekende URL’s zonder overbodige parameters
40. Interne links met beschrijvende ankertekst, niet “lees meer”
41. Breadcrumbs zichtbaar in de HTML én als BreadcrumbList-markup
42. Organization– of LocalBusiness-markup op één centrale pagina
43. Article– of FAQPage-markup alleen waar die inhoudelijk klopt
44. Structured data gevalideerd met de Rich Results Test
45. Hreflang correct en wederkerig bij meertalige sites
46. Mobiele versie bevat dezelfde content, links en markup als desktop
47. Toegankelijkheid op orde: alt-teksten, contrast, focusstates
48. AI-crawlers bewust toegelaten of geblokkeerd in robots.txt — een keuze, geen toeval
49. Elke sectie opent met een zelfstandig antwoord van enkele zinnen
50. Vaste hercontrole na elke release of CMS-update, want techniek verslechtert vanzelf

De schematypen vind je in het volledige overzicht op Schema.org. Punt 48 en 49 zijn nieuw ten opzichte van een klassieke checklist en horen bij het bredere werk aan AI-zichtbaarheid en SEO-content.

Wat bewust niet op deze checklist staat

Eerlijk zijn over wat je weglaat, zegt meer dan de lijst zelf.

• Een Lighthouse-score van 100. Dat is labdata onder gesimuleerde omstandigheden. Google beoordeelt page experience op basis van wat echte bezoekers meemaken.
• Meta keywords. Google gebruikt deze tag niet.
• Zoekwoorddichtheid als percentage. Er bestaat geen doelwaarde.
• Domeinautoriteit als doel. Dat is een score van een externe leverancier, geen signaal van Google.

Deze punten kosten uren en leveren zelden iets op. De twaalf punten uit blok 1 leveren doorgaans meer op dan alle vier bij elkaar.

Hoe voer je deze technische SEO checklist uit?

Werk in de volgorde van de blokken en houd per punt vast wat je hebt gevonden, wat je hebt veranderd en wanneer. Een audit zonder logboek herhaal je over een half jaar volledig opnieuw.

Praktisch: begin met een crawl van je hele site, leg die naast de Search Console-rapporten en toets steekproefsgewijs met de URL-inspectie. Een crawler laat zien wat er ís; Search Console laat zien wat Google ervan heeft gemaakt. Het verschil tussen die twee is meestal waar je audit begint. Welke gereedschappen daarbij passen, hangt af van je schaal en budget — een vergelijking van AI-SEO-software helpt bij die keuze, en met een AI-zichtbaarheidsrapport zie je of het technische fundament zich ook vertaalt naar vermeldingen in AI-antwoorden.

Loop deze technische SEO checklist minimaal twee keer per jaar door, en altijd na een migratie, een redesign of een grote CMS-update. Wil je de eerste doorloop samen doen op je eigen site, dan kun je een demo inplannen.

Veelgestelde Vragen