Stel je technische SEO-audit in 9 stappen in

Een technische SEO-audit begint niet met een geopende tool of een PDF van 80 pagina’s die niemand leest. Hij begint met een ongemakkelijke vraag: wat weerhoudt Google ervan om je bedrijfswebsite correct te crawlen, renderen en indexeren? Als je die vraag niet met data kunt beantwoorden, heb je een takenlijst, geen audit.

Dit artikel beschrijft de exacte configuratiereeks die ik toepas in B2B-projecten met honderden of duizenden URL’s, geordend op afhankelijkheden: elke stap levert de data op die de volgende stap voedt. Als je de volgorde overslaat, verzamel je uiteindelijk statistieken die je niet kunt interpreteren.

Stap 0: bepaal de scope voordat je een tool aanraakt

In een bedrijf met meerdere bedrijfsonderdelen is de duurste fout het auditen van “het hele domein”. Voordat je iets configureert, bakende dit af:

• Inbegrepen subdomeinen: blog, webshop, klantportaal, help center. Beslis of het besloten gedeelte meegaat (meestal niet, maar het is verstandig dit te documenteren).
• Talen en regionale versies: als je /es/, /mx/ en /ar/ hebt, vereist elk daarvan een eigen hreflang-controle.
• Stakeholders: wie de templatewijzigingen goedkeurt, zit meestal in IT, niet in marketing. Identificeer die persoon in deze fase, anders loopt de rest van het proces vast.

Een praktijkgeval: een bedrijf in industriële dienstverlening met 4 talen ontdekte in de scopefase dat hun help center op een subdomein stond met een ander CMS en zonder toegang tot logs. Dat veranderde de methodologie van de rest van de audit volledig: zonder logs moest de crawlanalyse gebaseerd worden op steekproeven uit Search Console en op crawls met de user-agent van Googlebot.

Stap 1: configureer de toegang tot de brongegevens

Zonder deze basis is elke audit speculatief. Je hebt minimaal het volgende nodig:

Search Console

Verifieer eigendom per URL-prefix waar je kunt (dit maakt segmentering per submap mogelijk) en houd de domeineigenschap als back-up. Controleer of de gebruiker die je gaat inzetten volledige rechten heeft, niet beperkte: beperkte rechten verbergen prestatie- en indexgegevens die je later nodig hebt.

Analytics

Als je GA4 gebruikt, zorg er dan voor dat de webdatastream minstens 90 dagen actief is. Met minder historie is elke vergelijking van organisch verkeer voor/na een technische wijziging ruis. Stel een segment voor organisch verkeer in dat interne verwijzingsdomeinen en campagne-parameters die de attributie vervuilen uitsluit.

Serverlogs

Vraag toegang tot de access-bestanden (Apache of Nginx) van minimaal 30 dagen. Volgens de officiële documentatie van Google over crawlen is loganalyse de enige bron die met zekerheid laat zien welke URL’s Googlebot daadwerkelijk bezoekt, tegenover de URL’s waarvan jij denkt dat hij ze bezoekt.

Toegang tot het CMS en de repository

Je moet de headertemplates, de redirectregels en het robots.txt-bestand kunnen lezen. Als je geen toegang hebt tot de repository, vraag het technische team dan om de configuratie van .htaccess of van de redirect-middleware te exporteren.

Stap 2: bereid de crawler nauwkeurig voor

De configuratie van de crawler bepaalt de kwaliteit van alle latere bevindingen. Instellingen die het verschil maken:

• User-agent: gebruik die van Googlebot om het mobiele crawlen te simuleren (Googlebot Smartphone). Veel inhoudsverschillen komen alleen met die agent naar boven.
• JavaScript-rendering: activeer dit alleen als je website het nodig heeft. Bij websites met veel dynamische content jaagt rendering de crawltijd op en kan het de credits van de tool uitputten. In een project met 12.000 URL’s dwong het activeren van volledige rendering ons om de crawl op te splitsen in segmenten per sectie.
• Snelheidslimiet: overschrijd niet 2-3 verzoeken per seconde in productie zonder IT te waarschuwen. Een agressieve crawl kan de WAF activeren en de resultaten vertekenen met 403-fouten.
• Authenticatie: als er content achter een login staat die relevant is voor SEO (bijvoorbeeld productpagina’s met verborgen prijzen), configureer dan cookies of authenticatieheaders.

Sla de crawlconfiguratie op. Je hebt die identiek nodig om resultaten na de wijzigingen te vergelijken.

Stap 3: valideer de crawlgezondheid met robots.txt en sitemaps

Voordat je iets anders bekijkt, bevestig je dat Google je URL’s kan bereiken:

1. Controleer robots.txt regel voor regel. Zoek naar blokkades van CSS/JS-bronnen (die breken de rendering) en van parameters die wél unieke content genereren.
2. Controleer dat de XML-sitemap alleen canonieke URL’s bevat, met status 200 en niet geblokkeerd. Een sitemap met redirects of 404’s is een teken van verwaarlozing dat Google geleidelijk negeert.
3. Controleer in Search Console → Sitemaps dat het bestand zonder fouten wordt verwerkt en dat de ontdekte URL’s overeenkomen met wat je verwacht.
4. Gebruik de URL-inspectietool voor de 10 belangrijkste pagina’s per bedrijfsonderdeel en bevestig “De URL staat in Google” en dat de gecrawlde versie de canonieke is.

Eerlijke beperking: als je website meer dan 50.000 URL’s heeft, schaalt handmatige inspectie niet. Prioriteer in dat geval inspectie per template (één representatieve URL per type) en vul aan met het rapport “Pagina’s” van Search Console.

Stap 4: breng statuscodes en redirects in kaart

Exporteer uit de crawl alle URL’s met een status anders dan 200 en classificeer ze:

• 301/302: controleer dat redirectketens niet meer dan één sprong bevatten en identificeer lussen. Een veelvoorkomend patroon bij bedrijven na migraties: /producto → /producto/ → /es/producto/ → 404. Elke sprong verliest signaal en voegt latentie toe.
• 404/410: kruis de lijst met Search Console om URL’s te detecteren die nog externe links ontvangen. Dat zijn degenen die een redirect of herstel nodig hebben, niet degenen die simpelweg bestaan.
• 5xx: als ze in de crawl verschijnen, stop. Een instabiele server maakt elke andere analyse ongeldig.

Documenteer elke redirect met zijn bron, bestemming en reden. Dat register is wat IT in staat stelt de wijzigingen zonder interpretatie uit te voeren.

Stap 5: los canonicals en duplicaten op

Configureer de controle in drie lagen:

1. Verklaarde canonicals: vergelijk de rel=canonical-tag met de uiteindelijke URL na redirects. Een canonical die naar een geredirecte URL wijst, is een veelvoorkomende fout in CMS’en met slecht geconfigureerde SEO-plugins.
2. Parameters: identificeer degenen die duplicaten genereren (sortering, filters, paginering) en kies tussen canonical, noindex of blokkering. Let op: een URL met canonical blokkeren in robots.txt verhindert dat Google die canonical leest.
3. URL-varianten: hoofdletters, trailing slash, http/https, www/niet-www. Forceer één enkele versie met redirects op serverniveau, niet vanuit het CMS.

Dit werkt niet in alle gevallen hetzelfde: bij ecommerce met facetfilters lost de canonical op zichzelf het probleem niet op als de filters interne links ontvangen. Daar heb je bovendien controle over interne linking nodig en soms voorwaardelijke rendering van de filterlinks.

Stap 6: audit de rendering en JavaScript

Vergelijk de initiële HTML met de gerenderde DOM in de kerntemplates. Zoek naar:

• Hoofdcontent die pas verschijnt na het uitvoeren van JavaScript (hoog risico als er geen server-side rendering is).
• Interne links gegenereerd door JS die de crawler zonder rendering niet ontdekt.
• Metadata (title, canonical, hreflang) geïnjecteerd door JS en die mogelijk niet in de geserveerde HTML terechtkomt.

Volgens de officiële documentatie over rendering kan Google JavaScript uitvoeren, maar met een beperkt crawlbudget en zonder garantie dat alle scripts worden uitgevoerd. De praktische conclusie: als een link of een canonical alleen na JS bestaat, behandel die dan als onbetrouwbaar.

Stap 7: meet Core Web Vitals met velddata

Blijf niet bij Lighthouse. Configureer de controle met echte data:

1. Exporteer het Core Web Vitals-rapport van Search Console per apparaattype en URL-groepering.
2. Identificeer welke templates LCP, INP of CLS niet halen, niet welke losse pagina’s.
3. Prioriteer op impact: een productpaginatemplate met duizenden URL’s en slechte LCP weegt zwaarder dan de homepage.

Belangrijke nuance: velddata hebben latentie (28 dagen in het Search Console-rapport). Als je net afbeeldingen hebt geoptimaliseerd, verwacht de verandering dan niet in dezelfde week te zien. En als je verkeer laag is, zijn er mogelijk niet genoeg steekproeven om een specifieke template te beoordelen; combineer in dat geval lab- en velddata, en zeg dat in het rapport.

Stap 8: consolideer het rapport en prioriteer op afhankelijkheden

Het eindproduct is geen lijst met fouten. Het is een uitvoeringsreeks met afhankelijkheden:

• Blokkerend: 5xx, robots.txt die bronnen blokkeert, kapotte redirects. Zonder dit doet de rest er niet toe.
• Structureel: canonicals, duplicaten, architectuur van interne links.
• Prestatie: Core Web Vitals per template.
• Verbeteringen: gestructureerde data, hreflang, optimalisatie van afbeeldingen.

Elke taak moet de getroffen URL of template vermelden, het verantwoordelijke team en hoe de wijziging wordt geverifieerd (bijvoorbeeld “recrawl van de 200 URL’s van template X en vergelijking van statuscodes”).

Configuratiefouten die ik steeds weer zie terugkomen

• Auditen met de desktop-user-agent op websites waar mobiel andere content serveert. De bevindingen komen niet overeen met wat Google indexeert.
• Vertrouwen op de dekking van Search Console zonder kruisverwijzing met logs. Er zijn gecrawlde URL’s die nooit in de rapporten verschijnen en andere die als “uitgesloten” verschijnen zonder duidelijke reden.
• robots.txt en canonicals tegelijk wijzigen. Als iets verslechtert, weet je niet wat het veroorzaakte. Eén wijziging per iteratie, met geregistreerde datum.
• Het klantportaal negeren in robots.txt en maanden later ontdekken dat Googlebot crawlbudget verbruikt aan sessie-URL’s.

Wat deze methodologie niet dekt

Een technische audit lost geen probleem met zoekintentie of contentkwaliteit op. Als je website correct crawlt en indexeert maar de pagina’s niet beantwoorden aan wat de gebruiker zoekt, zijn de technische data schoon en blijft het verkeer vlak. Hij vervangt ook geen controle van toxische links of domeinautoriteit: dat zijn verschillende disciplines die elkaar aanvullen, niet overlappen.

En een laatste waarschuwing: geen enkele audit garandeert verbeteringen in posities. Wat hij garandeert, is dat je meetbare obstakels wegneemt. De rest hangt af van factoren die je niet vanaf de server beheert.