Technische SEO-audit: wat hij controleert, stap voor stap, en wat je aan het eind krijgt

Wat een technische SEO-audit is en waarin hij verschilt van de rest

Een technische SEO-audit beantwoordt een eenvoudige vraag: kan Google je pagina's bereiken, lezen en begrijpen welke ervan belangrijk zijn? Hij beoordeelt niet of de teksten goed zijn of of je genoeg links van andere sites hebt. Hij kijkt naar het fundament. Is het fundament scheef, dan werkt alles wat je erop bouwt met verlies. En anders dan bij content raken technische problemen meestal tientallen pagina's tegelijk, niet één.

Het verschil met een content-audit is makkelijk uit te leggen. Een content-audit vraagt of de pagina goed antwoord geeft op wat mensen zoeken. Een technische audit vraagt of de pagina überhaupt in de juiste vorm bij Google aankomt. In de praktijk is de technische audit de eerste stap van elk project voor SEO-optimalisatie, omdat hij laat zien wat er gerepareerd moet worden voordat je in nieuwe artikelen investeert.

Hieronder lopen we de controles één voor één door, in de volgorde waarin we ze uitvoeren. Bij elke controle geven we een echt voorbeeld, gevonden op onze eigen website. Niet omdat we graag onze fouten laten zien, maar omdat het precies het soort problemen is dat je met het blote oog niet ziet en dat een goede audit wel vindt. Alles is opgelost, en bij elke stap beschrijven we kort de oplossing.

Stap 1: indexering en toegang voor crawlers

Het eerste wat we controleren is of de belangrijke pagina's in de index van Google staan. De betrouwbare bron hiervoor is het rapport Paginaindexering in Search Console, niet een site:-zoekopdracht in Google. Het rapport laat zien welke pagina's geïndexeerd zijn en, voor de rest, de reden: een 404-fout, een pagina met noindex, geblokkeerd door robots.txt, een duplicaat zonder door de gebruiker gekozen canonieke pagina, of „gecrawld, momenteel niet geïndexeerd”.

Google schrijft duidelijk in de documentatie dat je niet moet verwachten dat alle URL's van je site geïndexeerd worden, alleen de canonieke pagina's. Schrik dus niet van een lijst met niet-geïndexeerde pagina's. Kijk of er een pagina tussen staat die geld oplevert. Daar begint het werk. Staat je belangrijkste dienstpagina op „gecrawld, momenteel niet geïndexeerd”, dan is dat een probleem. Verschijnen filterpagina's of URL's met parameters, dan is dat vaak precies het gedrag dat je wilt.

Ons voorbeeld: op 16 september 2026 stuurde Search Console ons een mail met een fout „Not found (404)” voor een adres van de vorm /blog/cat-costa-un-site-de-prezentare. Die pagina bestond niet en er werd nergens in het menu of in de tekst naar gelinkt. De oorzaak zat in de gestructureerde gegevens: elk artikel gaf in het breadcrumb-schema een adres /blog/artikelnaam op, terwijl de artikelen eigenlijk op /blog-artikelnaam staan. Google volgt ook de adressen in het schema, niet alleen de zichtbare links. We hebben het adres in het schema gecorrigeerd, een 301-redirect ingesteld voor elk oud adres van dat type en onze automatische linkcontrole uitgebreid, zodat die ook de adressen in JSON-LD leest.

Stap 2: canonicals, redirects en dubbele pagina's

Bijna elke site heeft meerdere adressen die naar dezelfde inhoud leiden: met en zonder www, met en zonder slash aan het eind, met trackingparameters. Google kiest er één van als hoofdversie. Jouw taak is signalen te geven die hetzelfde zeggen. De documentatie van Google beschrijft een redirect als een sterk signaal, de canonical-tag ook als een sterk signaal en de sitemap als een zwak signaal. En ze waarschuwt uitdrukkelijk om voor dezelfde pagina geen verschillende canonieke URL's op te geven via verschillende methoden.

Precies dat hadden we gevonden op de oude versie van onze website, in de audit van 6 september 2026. Alle pagina's in de sitemap behalve de homepage stonden erin zonder slash aan het eind. De server stuurde ze met een 301 door naar de versie met slash. En de pagina met slash had een canonical-tag die terugwees naar de versie zonder slash. Drie signalen, twee richtingen. Voor Google is dat alsof je zegt „ga daarheen” en bij aankomst „eigenlijk, ga terug”.

De oplossing is niet ingewikkeld, maar moet op alle drie de plekken tegelijk gebeuren: het adres in de sitemap, het doel van de redirect en de canonical moeten dezelfde URL zijn, teken voor teken. Op de vernieuwde site hebben we alle drie gekoppeld aan één enkele regel voor het maken van adressen, zodat ze niet meer uit elkaar kunnen lopen. Daarna hebben we op de gepubliceerde site gecontroleerd dat elk adres uit de sitemap direct met 200 antwoordt, zonder redirect onderweg.

Stap 3: snelheid en Core Web Vitals

Core Web Vitals zijn drie metingen die Google gebruikt om de echte ervaring op een pagina te beschrijven. De drempels die Google aanbeveelt zijn: LCP, het moment waarop het hoofdelement verschijnt, onder 2,5 seconden; INP, hoe snel de pagina op een klik reageert, onder 200 milliseconden; CLS, hoeveel de inhoud verspringt tijdens het laden, onder 0,1. Volgens Google sluiten deze metingen aan bij wat de rankingsystemen willen belonen, samen met andere aspecten van de paginabeleving.

In een audit blijf je niet hangen bij de PageSpeed-score. Je meet op een telefoon, met een lege cache en beperkte snelheid en processor, op meerdere soorten pagina's, niet alleen op de homepage. Daarna zoek je de oorzaak van elk probleem, want een score alleen repareert niets. Een site kan goed scoren op de homepage en ernstige problemen hebben op artikelen of productpagina's. Daarom kiezen we één pagina van elk type sjabloon en meten we ze allemaal, meerdere keren, zodat we geen conclusies trekken uit één enkele meting.

Ons voorbeeld, uit september 2026: het laden ging goed, maar de inhoud versprong. Op de homepage maten we een CLS van 0,117, boven de grens van 0,1. De oorzaak was de cookiebanner, die verscheen voordat de lettertypen geladen waren en zich daarna herschikte, waardoor de tekst opschoof. Web.dev noemt precies dit soort oorzaak bij de veelvoorkomende: lettertypen die groter of kleiner worden weergegeven dan het reservelettertype en elementen die vóór bestaande inhoud aan de pagina worden toegevoegd. We hebben de banner pas laten verschijnen nadat de lettertypen geladen zijn. Gemeten op de live site na publicatie daalde de CLS naar 0,023.

Stap 4: gestructureerde gegevens, koppen en taalversies

Gestructureerde gegevens zijn code die Google expliciet vertelt wat er op de pagina staat: een bedrijf, een dienst, een artikel, veelgestelde vragen, een navigatiepad. In de audit controleer je drie dingen: of ze er zijn, of het type bij de pagina past en of de adressen erin naar echte pagina's leiden. Voor validatie raadt Google de test voor uitgebreide resultaten aan. Op onze oude site hadden de dienstpagina's alleen een algemeen schema voor een lokaal bedrijf, zonder enige beschrijving van de dienst, hoewel het commerciële pagina's waren.

Ook de structuur van de koppen hoort hierbij. Elke pagina hoort één hoofdkop te hebben, de H1, die zegt waar de pagina over gaat. Op de oude site had elke pagina er twee: de echte kop en nog een, op de hele site identiek, achtergebleven in een verborgen deel van de code. Bezoekers zagen hem nooit. De crawler wel. Het is geen ernstige fout, maar wel het soort gemengd signaal dat zich optelt bij andere en een pagina moeilijker te begrijpen maakt.

Heeft de site meerdere talen, dan controleer je ook hreflang, de tag die de versies van dezelfde pagina met elkaar verbindt. Google eist dat elke versie zichzelf en alle andere vermeldt, en als de verwijzingen niet wederzijds zijn, kunnen ze genegeerd worden. Google raadt ook een x-default-versie aan voor bezoekers bij wier taal geen enkele versie past. Op onze site in vijf talen vonden we een subtielere variant van het probleem: de Engelse pagina's hadden in hun schema een breadcrumb die naar de Roemeense adressen wees.

Stap 5: interne links en de volgorde van de controles

Het laatste deel is hoe de pagina's naar elkaar linken. Je zoekt belangrijke pagina's waar geen enkele link naartoe leidt, interne links naar adressen die doorsturen of een fout geven, en pagina's die in de sitemap ontbreken. Op de oude site werd de pagina voor afspraken wel gegenereerd en er waren links naartoe, maar hij ontbrak in de sitemap. Een klein probleem, maar precies de pagina die je mensen wilt laten vinden.

Deze controle doe je het best automatisch, over de hele site, niet pagina voor pagina, want een mens raakt na de eerste paar tientallen links vermoeid. Bij elke publicatie draaien we een script dat alle interne links volgt, ook die in de gestructureerde gegevens, en we publiceren niets als het een kapotte link vindt. Kort gezegd ziet de volgorde waarin we een technische audit doorlopen er zo uit:

• 01Indexering: het rapport Paginaindexering in Search Console, robots.txt, sitemap, 404- en soft 404-fouten.
• 02Adressen: redirects, canonicals, versies met en zonder www of slash aan het eind, parameters.
• 03Snelheid: LCP, INP en CLS gemeten op een telefoon, op meerdere paginatypen, met de oorzaak van elk probleem.
• 04Code: gevalideerde gestructureerde gegevens, één H1 per pagina, unieke titels en beschrijvingen.
• 05Talen: wederzijdse hreflang, x-default, juiste adressen in elke taal.
• 06Links: kapotte interne links, pagina's zonder inkomende links, belangrijke pagina's die in de sitemap ontbreken.

Hoe lang het duurt, wat je aan het eind krijgt en wanneer het loont

De duur hangt bijna alleen af van de omvang en complexiteit van de site. Een bedrijfssite met enkele tientallen pagina's is veel sneller gecontroleerd dan een webshop met duizenden producten, filters en URL-varianten. Toegang tot Search Console telt ook mee: zonder die toegang wordt een flink deel van de controles gokwerk, omdat je niet ziet wat Google ziet. Van buitenaf kun je de adressen, de snelheid en de code toch controleren.

Wat je aan het eind hoort te krijgen is geen score en ook geen pdf van 80 pagina's uit een tool. Het is een lijst met problemen, gesorteerd op impact, elk met drie dingen: waar het voorkomt, het bewijs, dus een screenshot, een meting of een regel uit een rapport, en de concrete oplossing. Idealiter krijg je ook een controle na de reparaties, want veel problemen lijken opgelost en zijn dat pas als je ze bevestigd ziet in Search Console.

Een technische audit loont als je je site opnieuw hebt gebouwd of verhuisd, als je een nieuwe taal hebt toegevoegd, als het organische verkeer zonder duidelijke reden daalt of als goede pagina's vastzitten op de tweede pagina van Google. Het loont niet om hem elke maand te herhalen op een kleine site die niet verandert. Daar volstaat af en toe een blik in Search Console.

Bronnen en verder lezen.

• 01Google Search Central — Understanding Core Web Vitals and Google search results
• 02Google Search Central — How to specify a canonical URL with rel="canonical" and other methods
• 03Google Search Central — Tell Google about localized versions of your page
• 04Google Search Console Help — Page indexing report
• 05Google Search Central — Breadcrumb (BreadcrumbList) structured data
• 06web.dev — Cumulative Layout Shift (CLS)

Veelgestelde vragen

Het team van The Niche SocietyAI- en software-engineers uit Boekarest · LinkedIn

gepubliceerd 2026-09-28