Een website kan een prachtig ontwerp hebben en een groen rondje in de SEO-plugin, en toch mensen verliezen voordat de hoofdinhoud überhaupt is geladen. Of Google indexeert een andere URL dan je verwacht. Of een bestelling werkt, maar de meting registreert die twee keer.
Daarom begin ik een technische audit niet met het najagen van een score van honderd in één test. Eerst zoek ik naar fouten die het bedrijf, de indexering of het gebruik van de website belemmeren. Pas daarna werk ik de kleine details af.
1. Controleer of belangrijke URL’s de juiste status teruggeven
Controleer de belangrijkste dienstenpagina’s, artikelen die verkeer ontvangen, de contactpagina en het conversiepad. Een belangrijke pagina moet 200 teruggeven. Inhoud die permanent is verhuisd, moet één directe 301-omleiding hebben. Een verwijderde pagina mag niet stilletjes op de homepage eindigen.
Ik controleer ook HTTP en HTTPS, www- en non-www-varianten, trailing slashes en parameters. Het resultaat moet één canonieke URL zijn. Google beschrijft een redirect als een sterk signaal voor canonicalisatie en adviseert die te combineren met een consistente canonical en sitemap in zijn documentatie over canonieke URL’s.
2. Controleer indexering vanuit het perspectief van de echte pagina
Robots.txt, meta robots, canonical en sitemap moeten samenwerken. Een veelgemaakte fout is dat je een pagina indexeert die niets te zoeken heeft in de zoekresultaten, terwijl belangrijke inhoud wordt geblokkeerd. Gebruik URL-inspectie in Search Console voor meerdere representatieve URL’s. Je ziet daarmee wat Google over de pagina weet en kunt de liveversie testen.
- Is de canonieke URL de URL die je wilt?
- Is de pagina beschikbaar zonder inloggen of blokkering?
- Bevat de sitemap alleen indexeerbare URL’s met 200?
- Vermijden interne links redirects?
- Zijn belangrijke pagina’s verweesd?
Google houdt deze onderwerpen bij elkaar in zijn documentatie over crawlen en indexeren.
3. Meet snelheid bij mensen, niet alleen in het lab
PageSpeed Insights en Lighthouse zijn nuttige diagnostische tools. Maar een labtest is niet hetzelfde als de ervaring van echte bezoekers. De huidige Core Web Vitals zijn LCP, INP en CLS; veldgegevens zijn gebaseerd op echte apparaten en verbindingen. De officiële documentatie over Web Vitals legt het overzicht en het verschil tussen veld- en labgegevens uit.
Ik zou de prioriteiten zo lezen:
- LCP: wanneer de hoofdinhoud verschijnt.
- INP: hoe snel de pagina reageert op gebruik.
- CLS: of elementen tijdens het laden verspringen.
- TTFB en netwerk: of er überhaupt snel iets begint te gebeuren.
Google zegt ook expliciet dat een goede score geen topposities garandeert. Algemene bruikbaarheid is belangrijker dan het najagen van één getal. Bekijk de documentatie over pagina-ervaring.
4. Vind de echte oorzaak van het laden
Kijk in de waterfall en DevTools naar lange servertijd, blokkerende CSS en JavaScript, te grote afbeeldingen, fonts, herhaalde verzoeken en scripts van derden. De oude regel om ‘alle bestanden te combineren’ is niet langer universeel. Bij moderne protocollen kunnen de hoeveelheid ongebruikte code en blokkering van de main thread belangrijker zijn.
- Laad de hoofdafbeelding op een passende grootte en in een modern formaat.
- Stel afbeeldingsafmetingen in, zodat de inhoud niet verspringt.
- Inhoud onder de eerste viewport kan native lazy loading gebruiken.
- Laad alleen de vereiste fontgewichten en tekensets.
- Laad marketingscripts asynchroon en alleen waar ze een doel dienen.
- Comprimeer tekstbronnen en stel een lange cache in voor bestanden met versies.
Een externe dienst kost niet alleen milliseconden. Elke pixel, chatwidget en heatmap zorgt voor extra operationele en dataverantwoordelijkheid. Als niemand het rapport gebruikt, verwijder dan het script.
5. Doorloop de website als klant met toetsenbord en mobiele telefoon
Doorloop op mobiel de navigatie, het formulier, de cookiedialoog en de bestelling. Vergroot de tekst, schakel afbeeldingen uit en gebruik een toetsenbord. Koppen moeten een begrijpelijke structuur vormen, een formulier heeft labels nodig en een foutmelding moet zeggen wat je moet oplossen.
Elke pagina moet één hoofdtaak hebben. Dat betekent niet koste wat kost één knop, maar wel een duidelijke hiërarchie. Vind meer praktische aandachtspunten in de basis-UX-checklist.
6. Los fouten met resources en JavaScript op
Een 404 voor een afbeelding, font of script is niet cosmetisch. Het kan de vormgeving, meting of functionaliteit verstoren. Controleer fouten in de browserconsole, mislukte netwerkverzoeken en herhaalde 5xx-antwoorden op de server. Test kritieke paden na elke deployment.
7. Gebruik structured data alleen voor waarheidsgetrouwe inhoud
Schema is geen manier om sterbeoordelingen af te dwingen. Het is een machineleesbare beschrijving van wat er daadwerkelijk op de pagina staat. Gebruik een ondersteund type en test dit in de Rich Results Test. Google vermeldt de huidige ondersteunde formaten en testtools in zijn documentatie over structured data.
8. Metingen mogen de website die ze moeten meten niet verstoren
Laad GA4, advertentieplatforms en andere scripts op een niet-blokkerende manier. Benoem events op basis van beslissingen, niet van elke klik. Controleer duplicaten, toestemming en of iemand de gegevens daadwerkelijk gebruikt. Vind een praktische basis in de artikelen over Google Tag Manager en Google Analytics 4.
9. Geld en risico bepalen de volgorde van verbeteringen
- Een bestelling, formulier of login die niet werkt.
- Een belangrijke pagina die niet beschikbaar of niet indexeerbaar is.
- Een beveiligingsprobleem en verouderde componenten.
- Grote problemen met mobiele bruikbaarheid en Core Web Vitals.
- Meetfouten die tot slechte beslissingen leiden.
- Pas daarna kleine scores en cosmetische problemen.
Technische SEO is de startlijn. Het wint de race niet op zichzelf, maar een kapotte website kan al verliezen voordat het startschot klinkt. Als je technische bevindingen wilt vertalen naar bedrijfsprioriteiten, kun je de website en de beslissing waar je voor staat beschrijven.