Technische SEO-audit: zo pak je het stap voor stap aan

Kort antwoord: een technische SEO-audit is een controle van alles wat bepaalt of Google je website kan crawlen, indexeren en goed kan weergeven. Je loopt negen onderdelen na: crawlen, indexering, statuscodes, snelheid, Core Web Vitals, mobiel, structuur en interne links, hreflang en structured data. Met Google Search Console, PageSpeed Insights en een crawler zoals Screaming Frog kom je al ver. Wat je overhoudt is geen rapport vol waarschuwingen, maar een korte lijst problemen op volgorde van impact.

Wat is een technische SEO-audit?

Een technische SEO-audit kijkt naar de techniek onder je content. Hoe antwoordt de server? Welke pagina's mag en kan Google ophalen? Welke versie van een pagina geldt als hoofdversie? Hoe snel en stabiel laden de pagina's, ook op een telefoon? En begrijpt een zoekmachine in welke taal een pagina is en waar die over gaat?

Teksten beoordelen en backlinks analyseren hoort er niet bij, al raken de onderwerpen elkaar. De reden om techniek apart te bekijken is simpel: als Google een pagina niet kan crawlen of indexeren, telt de beste tekst niet mee. En technische fouten zie je als bezoeker meestal niet. Denk aan een noindex-tag die na de livegang is blijven staan, een redirect die op een 404 uitkomt of een sitemap vol oude URL's.

Een goede audit levert drie dingen op: de bevindingen, per bevinding de URL's of sjablonen die het raakt, en een volgorde om ze aan te pakken.

Welke tools heb je nodig?

Voor de meeste websites volstaan vier tools, waarvan drie gratis.

• Google Search Console is de enige bron die laat zien hoe Google zelf je site ziet. Je gebruikt vooral het rapport Pagina-indexering, de URL-inspectie, het rapport Core Web Vitals, het HTTPS-rapport en het sitemaprapport. Nog niet ingericht? Lees dan eerst onze uitleg over Google Search Console.
• Een crawler zoals Screaming Frog SEO Spider. Die loopt je site af zoals een zoekmachine en toont per URL de statuscode, title, canonical, meta robots, interne links en klikdiepte. De gratis versie crawlt tot 500 URL's per crawl (bron: Screaming Frog), genoeg voor veel mkb-sites. De site-audits in Semrush of Ahrefs doen vergelijkbaar werk.
• PageSpeed Insights geeft twee soorten gegevens: veldgegevens van echte Chrome-gebruikers uit het Chrome User Experience Report over de afgelopen 28 dagen, en labgegevens uit een gesimuleerde test op één apparaat met vaste netwerkinstellingen (Google for Developers).
• De Rich Results Test van Google, om structured data te controleren.

Zet de export van je crawl in een spreadsheet met één kolom per controlepunt. Dan kun je straks filteren op sjabloon of sectie en zie je snel of een probleem één pagina raakt of honderd.

Stap 1–3: crawlen, indexering en statuscodes

Stap 1: crawlen

Start de crawler op je homepage en vergelijk drie getallen: hoeveel URL's de crawler via links vindt, hoeveel er in je sitemap staan en hoeveel Search Console als geïndexeerd toont. Grote verschillen vertellen je iets. Staan er pagina's in de sitemap die de crawler niet bereikt, dan zijn ze waarschijnlijk niet intern gelinkt. Vindt de crawler duizenden URL's met parameters die nergens in de sitemap staan, dan heb je een duplicatenprobleem.

Open daarna je robots.txt. Volgens Google is dat bestand vooral bedoeld om crawlerverkeer te beheren, zodat je server niet overbelast raakt. Het is geen manier om een pagina uit Google te houden: een geblokkeerde URL kan nog steeds in de zoekresultaten verschijnen, alleen zonder beschrijving. Wil je een pagina echt niet in Google, gebruik dan noindex of een wachtwoord (Google Search Central). Controleer ook dat geen Disallow-regel een belangrijke sectie of de CSS- en JavaScript-bestanden blokkeert.

Kijk dan naar je XML-sitemap. Zet er alleen de canonieke URL's in die je in de zoekresultaten wilt zien, als volledige absolute URL's. Eén sitemap mag maximaal 50.000 URL's of 50 MB ongecomprimeerd bevatten. Google negeert de velden priority en changefreq en gebruikt lastmod alleen als die consequent klopt (Google Search Central). Dien de sitemap in via Search Console of verwijs ernaar met een Sitemap-regel in robots.txt.

Stap 2: indexering

Open in Search Console het rapport Pagina-indexering. Google zegt daar zelf dat je niet moet verwachten dat elke URL op je site geïndexeerd wordt. Het doel is dat de canonieke versie van elke belangrijke pagina in de index staat (Search Console Help). Loop de redenen voor niet-geïndexeerde pagina's door en zoek naar belangrijke pagina's in die lijst: pagina's met een noindex-tag, pagina's die robots.txt blokkeert, soft 404's en duplicaten waarvoor Google een andere canonieke versie heeft gekozen dan jij bedoelde.

Controleer daarna de canonicals. Een permanente redirect en een rel="canonical" zijn voor Google sterke signalen, opname in de sitemap is een zwak signaal. Gebruik robots.txt niet om een canonieke versie aan te wijzen, en noindex ook niet: daarmee blokkeer je de pagina helemaal (Google Search Central). In je crawl moet elke canonical naar zichzelf of naar de juiste hoofdversie wijzen, nooit naar een redirect of een 404. Voor je tien belangrijkste pagina's kijk je met de URL-inspectie welke canonical Google echt gekozen heeft.

Stap 3: statuscodes

Filter je crawl op statuscode. Zo gaat Google met de belangrijkste codes om (Google Search Central):

Googlebot volgt standaard maximaal tien redirects achter elkaar, maar elke extra stap is onnodig. Link intern altijd direct naar de eind-URL, zeker na een migratie. Controleer tot slot HTTPS: elke pagina hoort via https te laden, http-adressen horen door te sturen en er mogen geen afbeeldingen of scripts via http geladen worden. Google noemt veilige weergave als onderdeel van de pagina-ervaring en heeft er in Search Console een HTTPS-rapport voor (Google Search Central).

Stap 4–6: snelheid, Core Web Vitals en mobiel

Stap 4: snelheid

Test niet alleen je homepage. Kies per sjabloon een representatieve pagina, bijvoorbeeld een dienstpagina, een categoriepagina, een productpagina en een blogartikel, en haal ze door PageSpeed Insights. Gebruik de labgegevens om oorzaken te vinden en de veldgegevens om te zien wat bezoekers echt ervaren. De gebruikelijke boosdoeners zijn te grote afbeeldingen, veel JavaScript, scripts van derden zoals chatwidgets en trackers, en een trage serverrespons.

Stap 5: Core Web Vitals

Google hanteert drie grenzen: LCP binnen 2,5 seconden, INP van 200 milliseconden of minder en CLS van 0,1 of minder, gemeten op het 75e percentiel van de paginabezoeken, apart voor mobiel en desktop (web.dev). Het rapport Core Web Vitals in Search Console geeft het overzicht voor je hele site. Google bevestigt dat Core Web Vitals door de rankingsystemen worden gebruikt, maar ook dat goede scores geen topposities garanderen (Google Search Central). Wil je per meting weten wat je kunt verbeteren, lees dan ons artikel Core Web Vitals uitgelegd.

Stap 6: mobiel

Google gebruikt de mobiele versie van je site, gecrawld met de smartphone-crawler, voor indexering en ranking (Google Search Central). Wat niet op mobiel staat, telt dus niet mee. Controleer of mobiel dezelfde hoofdinhoud heeft als desktop, dezelfde structured data en dezelfde meta robots-tags. Laad belangrijke inhoud niet pas in na een klik of tik, want die laadt Google mogelijk niet. Stel in je crawler een smartphone-user-agent in en vergelijk de uitkomst met een desktopcrawl.

Stap 7–9: structuur, interne links, hreflang en structured data

Stap 7: structuur en interne links

Google volgt in principe alleen <a>-elementen met een href. Links die alleen via een onclick of een span werken, zijn niet aan te raden. Elke pagina die je belangrijk vindt, hoort een link te hebben vanaf minstens één andere pagina op je site, met een ankertekst die beschrijft waar de link naartoe gaat in plaats van "klik hier" (Google Search Central).

• Weespagina's: URL's die wel in de sitemap staan maar geen interne links krijgen.
• Klikdiepte: pagina's die belangrijk zijn voor je omzet maar pas na veel klikken bereikbaar zijn.
• Interne links naar redirects en 404's: pas ze aan zodat ze direct naar de eind-URL gaan.
• Duplicaten: filters en parameters, varianten met en zonder www of slash aan het eind.
• URL-structuur: leesbare, consistente paden die passen bij de opbouw van je menu.

Stap 8: hreflang

Heb je meerdere taal- of landversies, dan controleer je hreflang. De regels van Google: elke versie verwijst naar zichzelf en naar alle andere versies, anders kunnen de tags genegeerd worden. URL's moeten volledig zijn, inclusief https. De taalcode volgt ISO 639-1, eventueel met een regiocode volgens ISO 3166-1 Alpha 2, maar nooit alleen een landcode: nl-BE mag, BE niet. Met x-default wijs je een standaardpagina aan. HTML-tags, HTTP-headers en de sitemap zijn voor Google gelijkwaardige methodes (Google Search Central). Laat hreflang verder alleen naar indexeerbare, canonieke pagina's met status 200 wijzen. Meer uitleg vind je in Wat is hreflang?

Stap 9: structured data

Structured data is een gestandaardiseerd formaat om informatie over een pagina door te geven en de inhoud te classificeren. Google raadt JSON-LD aan, maar zegt ook dat opmaak die niet aan de richtlijnen voldoet niet in aanmerking komt voor rich results. Test tijdens het bouwen met de Rich Results Test en volg na livegang de rapporten in Search Console (Google Search Central). Kijk daarnaast of de opmaak klopt met wat er zichtbaar op de pagina staat.

Hoe prioriteer je de bevindingen?

Een crawler geeft al snel honderden meldingen. Wie die van boven naar beneden afwerkt, is weken bezig met details. Sorteer liever in vier groepen:

1. Blokkerend: belangrijke pagina's die niet in de index kunnen komen door noindex, een robots.txt-blokkade, serverfouten of een verkeerde canonical.
2. Breed: fouten in een sjabloon die veel pagina's tegelijk raken, zoals ontbrekende canonicals op alle productpagina's, een trage LCP op elke categoriepagina of een redirectketen in het menu.
3. Specifiek: losse kapotte links, een paar trage pagina's, een hreflang-fout op één taalversie.
4. Cosmetisch: meldingen zonder merkbaar effect, zoals een title die een paar tekens te lang is.

Noteer per bevinding hoeveel belangrijke pagina's het raakt, hoeveel werk het is en wie het oplost: developer, contentbeheerder of hosting. Jaag niet op een perfecte score in een tool, want die score is een middel. Controleer na elke fix met de URL-inspectie en een nieuwe crawl of het probleem echt weg is.

Geen tijd of geen developer in huis? Bij een SEO-audit lopen wij deze stappen voor je door en krijg je een lijst met wat eerst moet.

Hoe vaak moet je een audit doen?

Er is geen officiële norm. Dit is wat wij aanraden:

• Een volledige audit aan het begin van je SEO-werk en daarna één tot twee keer per jaar voor een site die weinig verandert.
• Altijd vóór en direct na grote wijzigingen: een redesign, een nieuw CMS, een domeinwissel of een nieuwe taalversie. Zie ook onze checklist voor een website-migratie.
• Elke maand een korte check in Search Console: pagina-indexering, Core Web Vitals en HTTPS. Zet ook de e-mailmeldingen aan.
• Webshops en grote sites met dagelijks nieuwe of verdwijnende pagina's hebben baat bij een geplande crawl elke maand.