Technische SEO-checklist voor developers

Technische SEO is geen marketingfeestje, het zijn keuzes die jij als developer maakt in code, hosting en configuratie. Deze checklist geeft je 8 concrete punten (laadtijd, mobile-first, redirects, sitemap, robots.txt, schone HTML, structured data en interne links) die rechtstreeks bepalen of Google je B2B-site goed kan crawlen, indexeren en ranken. De korte versie: snelheid en mobiel wegen het zwaarst, en de meeste fouten zitten in dingen die nooit op een designmockup staan. Begin bovenaan en werk naar beneden.

Wat is technische SEO en waarom is het een dev-taak?

Technische SEO is alles wat ervoor zorgt dat zoekmachines je site zonder problemen kunnen vinden, lezen en begrijpen. Content en backlinks zijn één kant van SEO, maar als je pagina traag laadt, niet mobielvriendelijk is of per ongeluk geblokkeerd staat in robots.txt, dan ranken zelfs je beste teksten niet.

Het probleem op veel B2B-sites: marketing schrijft de content, maar de beslissingen die rankings kosten worden in de codebase genomen. Een framework dat te veel JavaScript laadt, een redirect-keten die niemand opruimt, een sitemap die nooit ververst. Dat is dev-terrein. Op customerimpact.be sturen we niet op ijdele cijfers zoals “aantal geïndexeerde pagina’s”, maar op de vraag die telt: kunnen zoekmachines de pagina’s vinden die jou klanten en omzet opleveren? Als het antwoord nee is, begint het werk hier.

Wil je weten waar je technisch staat, dan is een technische SEO-audit of een bredere SEO-audit het logische startpunt. Deze checklist helpt je de uitkomst van zo’n audit zelf te begrijpen en op te lossen.

1. Hoe belangrijk is laadtijd echt voor je rankings?

Laadtijd is een van de meest onderschatte rankingfactoren, en de impact op bezoekersgedrag is brutaal. Bij een laadtijd van 2 seconden ligt de bounce rate volgens onderzoek van Pingdom rond 6%, maar bij 5 seconden springt die naar 38%. Een fors deel van je bezoekers haakt af voordat de pagina volledig staat. Google ziet dat gedrag en trekt zijn conclusies.

Wat je concreet kunt doen:

Comprimeer en serveer afbeeldingen in moderne formaten (WebP, AVIF) met correcte dimensies, geen 4000px-bestanden in een 400px-container.
Verwijder of stel render-blocking JavaScript en CSS uit; laad alleen wat de eerste viewport nodig heeft.
Zet caching en een CDN op, en gebruik lazy loading voor afbeeldingen onder de vouw.
Meet met Core Web Vitals (LCP, INP, CLS) in plaats van op gevoel.

Eerlijk advies: jaag niet op een perfecte 100/100 Lighthouse-score als je site al snel laadt. De laatste paar punten kosten vaak dagen werk voor een verwaarloosbaar resultaat. Krijg je van 5 seconden naar 2, dan win je leads. Van 1,2 naar 1,0 seconde wint niemand iets.

2. Waarom is mobile-first geen optie meer?

Mobile-first is geen designvoorkeur, het is hoe Google je site beoordeelt. Ruim de helft van het websiteverkeer (rond de 60%) komt van mobiele apparaten, en Google gebruikt mobile-first indexing: de mobiele versie van je pagina is de versie die telt voor rankings. Wat niet in je mobiele HTML staat, telt voor Google niet mee.

Voor developers betekent dat:

Geen content die alleen op desktop laadt of achter een “lees meer” verstopt zit die mobiel niet rendert.
Tap-targets en knoppen groot genoeg, geen horizontaal scrollen, leesbare lettergroottes zonder zoomen.
Dezelfde structured data en metadata op mobiel als op desktop.
Test met echte toestellen of throttled emulatie, niet alleen een smal browservenster.

Voor B2B met lange salescycli is mobiel makkelijk te onderschatten (“onze beslissers zitten toch op desktop”). Maar de eerste oriëntatie gebeurt vaak mobiel, en als Google je daar slecht indexeert, mis je de instap.

3. Hoe voorkom je dat redirects en kapotte links je crawl verspillen?

Elke redirect kost crawltijd en laadtijd, en redirect-ketens stapelen die kost op. Een keten van vier redirects voor één URL is verspilde tijd die Google liever aan je echte pagina’s besteedt.

Houd het schoon:

Gebruik 301 (permanent) voor verhuisde URL’s, niet 302 (tijdelijk), tenzij het echt tijdelijk is.
Maak ketens plat: laat A direct naar de eindbestemming wijzen, niet via B en C.
Ruim 404’s op door ze te redirecten naar een relevant alternatief of door de interne links te fixen.
Controleer na elke migratie of herstructurering of oude URL’s correct doorverwijzen.

Een veelgemaakte fout bij site-migraties is alle oude URL’s naar de homepage redirecten. Dat is technisch een 301, maar je gooit alle opgebouwde autoriteit van die pagina’s weg. Redirect naar het meest relevante alternatief. Meer hierover lees je bij interne links.

4. Wat moeten je sitemap en robots.txt precies doen?

Je XML-sitemap en robots.txt sturen hoe zoekmachines je site verkennen, en kleine fouten hier hebben grote gevolgen. Een verkeerd geplaatste regel in robots.txt kan je hele site uit de index houden.

Voor de sitemap:

Neem alleen indexeerbare, canonical URL’s op (geen redirects, geen noindex, geen 404’s).
Houd hem actueel: genereer hem dynamisch zodat nieuwe pagina’s er automatisch in komen.
Dien hem in via Google Search Console en verwijs ernaar in robots.txt.

Voor robots.txt:

Blokkeer geen CSS- of JS-bestanden die Google nodig heeft om je pagina te renderen.
Verwar Disallow (niet crawlen) niet met noindex (niet indexeren); ze doen iets anders.
Test elke wijziging voordat je hem live zet, één foute regel kan duur uitvallen.

5. Welke HTML-tags maken je pagina’s leesbaar voor Google?

Schone, semantische HTML is de basis waarop alle technische SEO rust. Zoekmachines lezen je structuur via je tags, dus een rommelige DOM maakt het werk voor Google moeilijker.

De essentials per pagina:

Eén <h1> met je hoofdonderwerp, daarna een logische <h2>/<h3>-hiërarchie (geen koppen kiezen op basis van lettergrootte).
Een unieke, beschrijvende <title> en meta description per pagina, niet één template voor alles.
Betekenisvolle alt-teksten op afbeeldingen, zowel voor toegankelijkheid als voor beeld-SEO.
Een canonical-tag om duplicate content te voorkomen wanneer dezelfde inhoud via meerdere URL’s bereikbaar is.
Semantische elementen (<nav>, <main>, <article>) in plaats van een zee van <div>’s.

Dit overlapt sterk met on-page SEO, maar het verschil is wie het oppakt: de tags zelf zijn dev-werk, de inhoud erin is content-werk. Spreek af wie wat doet, anders blijft het liggen.

6. Wat levert structured data je op (en wanneer niet)?

Structured data (schema.org-markup) vertelt zoekmachines expliciet wat je content betekent, en kan rich results opleveren zoals sterren, FAQ’s of breadcrumbs in de zoekresultaten. Voor B2B is dit ook steeds relevanter voor GEO: AI-zoeksystemen gebruiken gestructureerde data om je content te begrijpen en te citeren.

Waar het loont:

Organization en LocalBusiness voor je bedrijfsgegevens.
FAQPage op pagina’s met echte vraag-en-antwoordstructuur.
BreadcrumbList voor duidelijke navigatiepaden.
Article op je kennis- en blogpagina’s.

Eerlijk advies: stop geen schema op pagina’s waar het niet klopt, en verzin geen FAQ-markup voor content die geen FAQ is. Google bestraft misleidende structured data, en een rich result garanderen kun je sowieso niet. Implementeer het waar het de inhoud eerlijk beschrijft (JSON-LD in de <head> is de aanbevolen methode), en valideer met de Rich Results Test. Meer over de AI-kant lees je bij SEO voor AI.

7. Hoe houd je je interne linkstructuur crawlbaar?

Interne links zijn hoe Google de relatie tussen je pagina’s begrijpt en autoriteit verdeelt. Een pagina die nergens vanuit gelinkt wordt (een “orphan page”) is voor Google bijna onzichtbaar.

Praktisch:

Zorg dat elke belangrijke pagina vanuit minstens één andere relevante pagina gelinkt is.
Gebruik beschrijvende anchor-teksten (“technische SEO-checklist”) in plaats van “klik hier”.
Gebruik echte <a href>-links, geen JavaScript-onclicks die Google niet altijd volgt.
Houd de klikdiepte beperkt: belangrijke pagina’s binnen drie klikken vanaf de homepage.

Voor B2B-sites met veel dienstenpagina’s is dit waar veel waarde verloren gaat. Je diensten verdienen organische instroom, dus link er bewust naartoe. Lees verder bij interne links.

8. Hoe maak je technische SEO een vast onderdeel van je workflow?

Technische SEO is geen eenmalig project maar onderhoud, en de winst zit in het inbouwen ervan in je dev-proces. Eén opgeschoonde site die vervolgens een jaar verwaarloosd wordt, vervalt langzaam weer.

Bouw het in:

Zet Lighthouse of een vergelijkbare check in je CI-pipeline, zodat een trage build opvalt voor hij live gaat.
Monitor Google Search Console maandelijks op crawlfouten, indexeringsproblemen en Core Web Vitals.
Maak een korte pre-launch-checklist (sitemap, robots.txt, redirects, structured data) verplicht bij elke release.
Laat marketing en dev samen naar de Search Console-data kijken, niet apart.

De rode draad: stuur op wat klanten oplevert. Niet elke technische optimalisatie is de moeite waard, en een goed team weet wanneer iets niet loont. Twijfel je waar je tijd het meest oplevert, kijk dan eerst naar de tools die je crawlbaarheid en snelheid meten, en prioriteer op impact.

Veelgestelde vragen over technische SEO voor developers

Wat is het verschil tussen technische SEO en on-page SEO? Technische SEO gaat over hoe goed zoekmachines je site kunnen crawlen, renderen en indexeren (snelheid, mobile-first, sitemap, redirects). On-page SEO gaat over de inhoud van een pagina (koppen, teksten, keywords). De tags zelf zijn vaak dev-werk, de inhoud content-werk.

Heeft technische SEO zin voor een kleine B2B-site? Ja. Juist op kleinere sites kost één technische fout (een trage homepage, een verkeerde robots.txt) je relatief veel van je beperkte organische instroom. De basis goed zetten is meestal een beperkte investering met blijvend rendement.

Hoe snel zie ik resultaat van technische verbeteringen? Snelheids- en crawlverbeteringen worden vaak binnen enkele weken opgepikt zodra Google opnieuw crawlt, maar rankingverbeteringen volgen pas daarna. Reken op weken tot maanden, afhankelijk van crawlfrequentie en concurrentie.

Moet ik streven naar een perfecte Lighthouse-score van 100? Nee. De grootste winst zit in het verschil tussen traag en snel, niet tussen snel en perfect. Krijg je de laadtijd onder de drempel waar bezoekers afhaken, dan is verder optimaliseren vaak verspilde tijd.

Welke technische SEO-fout zie je het vaakst? Pagina’s die per ongeluk op noindex staan of in robots.txt geblokkeerd zijn na een migratie, plus redirect-ketens en niet-doorverwezen oude URL’s. Een goede pre-launch-checklist vangt de meeste hiervan af.

Liever dat we het technische werk overnemen?

Heb je de checklist doorlopen en zie je dat er werk aan de winkel is, maar ontbreekt de tijd of de SEO-kennis in je dev-team? Dan kijken we er graag mee naar. Wij zijn een klein team dat snel beweegt, eerlijk adviseert (ook wanneer iets niet loont) en stuurt op klanten en omzet, niet op ijdele cijfers. Bekijk onze SEO-dienst of laat ons je technische basis nakijken zodat je rankings en leads de ruimte krijgen.

Plan je gratis intake

Technische SEO-checklist voor developers: 8 keuzes die je rankings maken of breken