Michele Eccher
In deze gids
Een technische SEO-audit moet vaststellen of de pagina’s die ertoe doen betrouwbaar gevonden, gecrawld, gerenderd, begrepen en geïndexeerd kunnen worden. Vervolgens onderzoek je welk systeem achter elk probleem zit. Je bepaalt de volgorde van het werk op basis van commercieel belang, omvang, zekerheid over de oorzaak en uitvoeringsrisico. Het resultaat is een plan dat je kunt testen, live zetten en controleren, niet alleen een spreadsheet met waarschuwingen.
Technische SEO-tools kunnen afwijkingen goed signaleren: een redirect, een ontbrekende canonical, een traag template of een pagina die niet in de crawl voorkomt. Ze weten niet vanzelf of die URL hoort te bestaan, commerciële waarde heeft of werkelijk de oorzaak van het zoekprobleem is. Een audit voegt die ontbrekende context toe.
Het zichtbare probleem
De oorzaak en het getroffen patroon
De impact en het risico van de wijziging
De gewenste werking op de live site
Bepaal eerst hoe de site zou moeten werken
Je kunt de huidige situatie pas beoordelen als de gewenste situatie duidelijk is. Begin bij de producten, diensten, markten en paginatypen die de website moet ondersteunen. Welke URL’s moeten indexeerbaar zijn? Welke bestaan alleen voor gebruikers of interne functies? En welke varianten horen bij een andere voorkeurs-URL, de canonical? Zonder die keuzes krijg je al snel technisch correcte aanbevelingen waar het bedrijf niets aan heeft.
Baken het commerciële belang af
Breng de paginatypen in kaart die klanten aantrekken of helpen converteren. Noteer de belangrijkste landen, talen en apparaten, de beschikbaarheid van producten, content waarvoor regelgeving geldt en platformbeperkingen die de uitvoering beïnvloeden.
Kies een representatieve URL-steekproef
Neem sterke en zwakke voorbeelden van elk belangrijk template mee, niet alleen de homepage. Voeg nieuwe en oude pagina’s, parametervarianten, redirects en bekende uitsluitingen toe. Zo kun je de beoogde werking vergelijken met wat er werkelijk gebeurt.
Leg wijzigingen en externe gebeurtenissen vast
Vergelijk verkeersveranderingen met releases, migraties, verwijderde content, aangepaste metingen, handmatige maatregelen, beveiligingsincidenten, seizoenen en grote zoekmachine-updates. Gelijktijdigheid bewijst geen oorzakelijk verband, maar helpt wel om het onderzoek af te bakenen.
Controleer welke gegevens beschikbaar zijn
Combineer Search Console, webstatistieken, crawlgegevens en de respons van de live website. Gebruik ook serverlogs, broncode, prestatiemetingen en een testomgeving als de site of het probleem daarom vraagt.
Google beschrijft zoeken als een reeks van crawlen, indexeren en resultaten tonen. In elke fase kan een pagina uitvallen of anders worden geïnterpreteerd. De officiële uitleg over de werking van Google Zoeken (Engels) biedt daarom een bruikbaar model voor je onderzoek: niet elke afwezige pagina heeft simpelweg een probleem met haar positie in de zoekresultaten.
Controleer hoe crawlers belangrijke URL’s vinden en ophalen
Ontdekken betekent dat een crawler weet dat een URL bestaat. Crawlen betekent dat hij die URL opvraagt en een bruikbare respons ontvangt. Test beide. Een pagina kan bij rechtstreeks bezoek statuscode 200 geven, maar nauwelijks vindbaar zijn doordat er geen links naartoe wijzen. Het omgekeerde komt ook voor: een website maakt miljoenen filter-URL’s vindbaar die niets te zoeken hebben in de index.
| Onderdeel | Wat onderzoek je? | Welke vraag beantwoord je? |
|---|---|---|
| HTTP-responsen | Statuscodes, redirectbestemmingen, ketens, lussen en soft 404’s | Geeft elke URL een respons die past bij de werkelijke toestand van de pagina? |
| robots.txt | Regels op de live site, toegang tot bestanden, user-agentgroepen en geblokkeerde patronen | Zijn nuttige pagina’s en bestanden crawlbaar zonder onnodige URL’s open te stellen? |
| XML-sitemaps | Canonical-URL’s, wijzigingsdatums, statuscodes en indexeerbaarheid | Beschrijven de bestanden de huidige verzameling voorkeurs-URL’s? |
| Interne vindbaarheid | HTML-links, klikdiepte, mogelijk verweesde pagina’s, paginering en verschillende weergaven van de navigatie | Kunnen crawlers belangrijke pagina’s via stabiele links bereiken? |
| URL-aanmaak | Parameters, filters, kalenders, zoekresultaten, sessie-ID’s en dubbele paden | Maakt de site meer crawlbare URL’s aan dan er nuttige bestemmingen zijn? |
| Servercapaciteit | Logs, 5xx-responsen, terugkerende vertragingen en crawlstatistieken | Blijft het platform beschikbaar wanneer crawlers het opvragen? |
Een sitemap helpt URL’s te ontdekken en geeft aan welke canonicals je verkiest, maar garandeert geen crawl of indexering. Google adviseert in de documentatie over sitemaps (Engels) om volledige canonical-URL’s te gebruiken. Vergelijk de sitemap daarom met de live website. Geldige XML zegt weinig als het bestand redirects, foutpagina’s of niet-canonieke pagina’s bevat.
Verklaar uitsluitingen en canonical-keuzes per template
Indexering is selectief. De nuttige vraag is niet: “Hoe krijgen we elke URL in de index?” Wel: “Selecteren zoekmachines consequent de pagina’s waarmee we gevonden willen worden?” Vergelijk per belangrijke URL-groep de opgegeven canonical met de canonical die Google kiest. Neem ook indexeringsinstructies, sitemapvermelding, interne links en overeenkomst tussen de pagina-inhoud mee.
Controleer robots-metatags en X-Robots-Tag-headers in de oorspronkelijke respons en het gerenderde document. Een geblokkeerde URL mag niet afhankelijk zijn van een noindex-instructie die Google door die blokkade niet kan ophalen.
Vergelijk redirectbestemmingen, canonical-verwijzingen, sitemapvermeldingen en interne links. Tegenstrijdige signalen maken de voorkeursversie onduidelijker en bemoeilijken de meting.
Onderzoek filters, printversies, locatievarianten, paginering, trackingparameters en herhaalde content. Bepaal per variant of die zelfstandig moet blijven bestaan, moet worden samengevoegd of kan verdwijnen.
Onderzoek soft 404’s, lege pagina’s, vervallen producten, templates met nauwelijks inhoud en pagina’s waarvan de nuttige content afhankelijk is van een mislukte aanvraag of een gebruikershandeling.
Een canonical geeft een voorkeur aan. Google kan een andere representatieve URL kiezen als de overige signalen daar aanleiding toe geven. De documentatie over canonicalisatie (Engels) beschrijft hoe redirects, sitemapvermeldingen, canonical-verwijzingen en andere indexeringssignalen samen bijdragen aan die keuze. Leg de hele groep vast in plaats van één tag los van de rest te corrigeren.
Vergelijk de eerste respons met de uiteindelijke pagina
Moderne websites kunnen titels, canonicals, links en hoofdinhoud via JavaScript opbouwen. Google kan JavaScript renderen, maar die extra stap kan mislukken, op een bestand wachten of een ander resultaat opleveren dan de oorspronkelijke HTML. Test het uiteindelijke DOM, de opgebouwde pagina, en de netwerkverzoeken die daarvoor nodig zijn.
Onderzoek de oorspronkelijke HTML
Controleer statuscode, titel, robots-instructie, canonical-URL, taal en hoofdinhoud voordat scripts in de browser draaien. Leg vast welke bruikbare inhoud overblijft als een script of API-aanvraag mislukt.
Onderzoek het gerenderde DOM
Vergelijk de uiteindelijke inhoud, links, metadata en gestructureerde gegevens. Zoek naar dubbele tags, een lege paginaopbouw, fouten die pas na het laden van een route verschijnen en content achter handelingen die een crawler niet uitvoert.
Test bestanden en API’s
Controleer geblokkeerde scripts, mislukte aanvragen, authenticatie, time-outs en browserfouten. De basispagina kan statuscode 200 geven, terwijl daarna alleen een foutmelding of geen indexeerbare inhoud verschijnt.
Controleer hoe links werken
Belangrijke bestemmingen moeten via crawlbare HTML-links met stabiele URL’s bereikbaar zijn. Test browserrouting, de navigatiegeschiedenis en filters. Een zichtbaar navigatie-element levert niet automatisch een vindbare link op.
In Googles handleiding voor JavaScript en SEO (Engels) zijn crawlen, renderen en indexeren afzonderlijke fasen. Google waarschuwt ook dat een noindex-instructie in de oorspronkelijke pagina ertoe kan leiden dat een latere JavaScript-wijziging niet wordt verwerkt. Test daarom de echte uitvoer; leid het gedrag van zoekmachines niet alleen af uit het gekozen framework.
Onderzoek de samenhang tussen pagina’s
De websitestructuur laat zien wat bij elkaar hoort, welke pagina’s centraal staan en hoe bezoekers van een brede vraag naar een specifiek antwoord gaan. Een technisch bereikbare pagina kan nog steeds slecht zijn verbonden met de rest van de site. Bekijk daarom ook de routes, linkteksten en functies van omliggende pagina’s.
| Onderdeel | Wat test je? | Veelvoorkomend probleem |
|---|---|---|
| Informatiehiërarchie | Secties, categorieën, boven- en onderliggende pagina’s en URL-afspraken | Het CMS bepaalt de indeling, niet de behoefte van de bezoeker. |
| Navigatie | Hoofdnavigatie, contextuele links, footer en mobiele routes | Belangrijke pagina’s verdwijnen op mobiel of na een herontwerp. |
| Interne links | Relevantie van de bestemming, context van de linktekst, plaatsing en kapotte links | Links staan alleen in automatisch aangemaakte blokken of hebben overal vage teksten. |
| Filternavigatie | Nuttige combinaties, crawlbeperkingen, canonicals en lege resultaten | Onbeperkte URL-combinaties bemoeilijken het ontdekken van pagina’s en vertroebelen rapportages. |
| Paginering en archieven | Vindbare links naar items, stabiele URL’s en de juiste weergave per pagina | Alleen de eerste reeks producten of artikelen blijft bereikbaar. |
| Internationale varianten | Volledige vertalingen, zelfverwijzende canonicals, taalalternatieven en wederzijdse verwijzingen | Taalverwijzingen leiden naar redirects of onvertaalde pagina’s. |
Beoordeel de structuur per template en gebruikersroute. Een gemiddelde klikdiepte voor de hele site kan verhullen dat één waardevolle categorie al haar contextuele links kwijt is. Ook het aantal kapotte links zegt niet of ze in een verouderd archief staan of midden in het aankoopproces. Deel de gegevens eerst op; interpreteer daarna het getal.
Houd gebruiksproblemen en beloften over posities uit elkaar
Prestaties, gestructureerde gegevens en mobiel gebruik horen bij een technische audit, maar vragen elk om een andere conclusie. Een trage interactie hindert gebruikers. Ongeldige gestructureerde gegevens kunnen verhinderen dat een pagina in aanmerking komt voor een specifieke zoekfunctie. Geen van beide bevindingen rechtvaardigt automatisch een belofte van hogere posities.
Prestaties bij echte gebruikers
Splits praktijkmetingen uit naar template en apparaat. Onderzoek de oorzaak met gecontroleerde tests en controleer na de release of het probleem voor gebruikers daadwerkelijk is verminderd.
Mobiel gebruik en toegankelijkheid
Test of dezelfde inhoud beschikbaar is, hoe de pagina op het scherm past en of knoppen, formulieren en navigatie goed werken. Volg automatische meldingen op door de betreffende handeling zelf te testen.
Gestructureerde gegevens
Toets ondersteunde markup aan de zichtbare inhoud en de toelatingsvoorwaarden. Verwijder misleidende of dubbele entiteiten in plaats van op elk template zomaar extra schema-markup te plaatsen.
De huidige Core Web Vitals van Google zijn LCP, INP en CLS: maten voor laden, reactiesnelheid en visuele stabiliteit. De officiële uitleg over Core Web Vitals (Engels) beschrijft de grenswaarden en het belang van goede prestaties voor gebruikers. Gebruik die metingen om de ervaring te bewaken. Laat een groene score je niet afleiden van ernstigere problemen met toegang, indexering of conversie.
Weeg het resultaat, de omvang en de zekerheid over de oorzaak
Wie alleen meldingen telt, geeft ruis te veel gewicht. Een betere afweging begint bij het gewenste resultaat: hoeveel waardevolle pagina’s worden geraakt, hoe sterk is het bewijs voor de oorzaak en wat kan er bij de oplossing misgaan? Beoordeel die factoren afzonderlijk en gebruik vervolgens je oordeel om de uitvoeringsvolgorde te bepalen.
| Factor | Vraag | Bewijs |
|---|---|---|
| Commercieel belang | Raakt het probleem pagina’s die zoekvraag opvangen, omzet opleveren of deel zijn van een cruciale gebruikersroute? | Paginafunctie, relevante bezoekers, conversies, assortiment en strategische prioriteit |
| Technische ernst | Blokkeert het ontdekking of indexering, of vermindert het de kwaliteit zonder die te blokkeren? | Respons, rendering, instructies, gekozen canonical en gedrag op de live site |
| Omvang | Gaat het om één URL, een herbruikbaar template of een onbeheerst URL-patroon? | Representatieve steekproeven, uitgesplitste crawlgegevens, logs en templateoverzicht |
| Zekerheid over de oorzaak | Kan het team het probleem reproduceren en koppelen aan de vermoedelijke oorzaak? | Gecontroleerde tests, voorbeelden van vóór en na de wijziging en meerdere gegevensbronnen |
| Inspanning en risico | Welke afhankelijkheden en releaserisico’s zijn er, en hoe draai je de wijziging terug? | Inschatting door ontwikkelaars, platformverantwoordelijkheid, tests en publicatieproces |
Kritiek
Een bevestigd probleem op de live site blokkeert of verwijdert belangrijke pagina’s, verstoort een migratie of bedreigt direct een grote groep waardevolle pagina’s uit hetzelfde template. Wijs meteen een verantwoordelijke aan en beperk de schade.
Hoog
Een reproduceerbaar systeemprobleem raakt een belangrijke paginagroep en de gewenste werking is duidelijk. Plan de oplossing in de eerstvolgende passende release, inclusief regressietests.
Gemiddeld
Het probleem bestaat, maar is beperkt, minder zeker of afhankelijk van een grotere productwijziging. Bewaar het bewijs en plan de oplossing samen met verwant werk.
Laag of geaccepteerd
De aantoonbare impact is klein, het gaat om een bewuste uitzondering of een veilige aanpassing kost meer dan ze oplevert. Leg de beslissing vast en bepaal bij welke signalen je opnieuw kijkt.
Beschrijf elke bevinding zo dat het team ermee aan de slag kan
De audit is klaar wanneer het team kan handelen zonder te gokken en het resultaat kan controleren zonder het onderzoek opnieuw te doen. Eén helder beschreven probleem is bruikbaarder dan tientallen rijen die dezelfde templatefout herhalen.
Gaat de audit vooraf aan een nieuw domein, CMS of andere URL-structuur? Gebruik de SEO-migratiechecklist om de bevindingen om te zetten in controles voor redirects, de testomgeving, de livegang en monitoring. Is doorlopende technische uitvoering en verantwoordelijkheid voor releases nodig? Bekijk dan onze technische SEO-dienst voordat je de taken verdeelt.
Beschrijf het gewenste resultaat
Leg uit hoe het paginatype voor gebruikers en zoekmachines moet werken. Benoem de verwachte respons, canonical, gerenderde inhoud of prestatie.
Voeg reproduceerbaar bewijs toe
Geef representatieve URL’s, commando’s of teststappen, nuttige schermafbeeldingen, de waarnemingsdatum en de gegevensbron. Houd bevestigde feiten en de vermoedelijke oorzaak uit elkaar.
Breng het getroffen patroon in kaart
Zoek de component, het template, de CMS-regel of het routinggedrag achter het probleem. Benoem bekende uitzonderingen; vraag ontwikkelaars niet om voorbeeld-URL’s één voor één te repareren.
Leg verantwoordelijkheid en releasevoorwaarden vast
Benoem het verantwoordelijke team, afhankelijkheden, acceptatiecriteria, testomgeving, voorwaarden voor terugdraaien en de release waarin de wijziging moet worden opgenomen.
Controleer de live website
Herhaal na de release dezelfde test, bekijk een representatieve steekproef en volg de relevante zoekgegevens. Sluit het probleem pas af als de gewenste werking op de live site is bevestigd.
Voeg regressiecontroles toe waar een fout kan terugkeren. Templatetests, sitemapvalidatie, bewaking van statuscodewijzigingen en crawlsteekproeven per release voorkomen vaak meer schade dan nog een volledige audit. Ook Googles bredere handleiding voor technisch SEO-onderhoud (Engels) benadrukt dat je crawlen en indexeren moet begrijpen, benodigde bestanden bereikbaar moet houden en voor elke vorm van toegangs- of indexeringscontrole het juiste middel moet kiezen.
Een goede technische SEO-audit maakt duidelijk waarom een probleem ertoe doet, waar het ontstaat, wie het kan oplossen en hoe je vaststelt dat de oplossing werkt. Zo leidt technische analyse tot veiligere releases en een betrouwbaardere basis voor vindbaarheid.
Veelgestelde vragen over een technische SEO-audit
Wat is een technische SEO-audit?
Een technische SEO-audit onderzoekt of belangrijke pagina’s betrouwbaar gevonden, gecrawld, gerenderd, begrepen, geïndexeerd en onderhouden kunnen worden. Je combineert zoekgegevens, crawlresultaten en technische informatie om te achterhalen welke templates of systemen de problemen veroorzaken. De uitkomst is een actieplan met prioriteiten en controles waarmee je de oplossingen kunt toetsen.
Hoe vaak moet je een technische SEO-audit uitvoeren?
Daar is geen vaste termijn voor. Doe een audit vóór een migratie of grote platformwijziging, na een aanzienlijke daling in verkeer of indexering, en wanneer structurele problemen zich hebben opgestapeld. Bij een stabiele site leveren gerichte monitoring en controles rond releases vaak meer op dan steeds dezelfde brede audit volgens de kalender.
Welke tools heb je nodig voor een technische SEO-audit?
Meestal heb je Google Search Console, webstatistieken, een crawler en toegang tot de live website nodig. Bij grotere of complexere sites kunnen ook serverlogs, renderingtests, prestatiegegevens, broncode, een testomgeving en product- of omzetgegevens nodig zijn. Kies de hulpmiddelen op basis van de onderzoeksvraag. Alle beschikbare rapporten exporteren maakt de diagnose zelden beter.
Betekent een hoge auditscore dat de website technisch gezond is?
Nee. Zo’n score vat veel controles samen in één getal en geeft URL’s of regels vaak een vergelijkbaar gewicht. Een site kan hoog scoren terwijl belangrijke pagina’s uit één template geblokkeerd zijn. Omgekeerd kunnen duizenden onschuldige parameter-URL’s een lage score veroorzaken. Kijk daarom naar het paginatype, het commerciële belang en het bewijs achter elke melding.
Moet je iedere technische SEO-waarschuwing oplossen?
Nee. Sommige meldingen wijzen op bewuste ontwerpkeuzes, dubbele URL’s zonder zoekwaarde of situaties die de zoekprestaties niet beïnvloeden. Grijp in als bewijs laat zien dat iets het gewenste resultaat verhindert, onnodig risico oplevert of steeds extra werk veroorzaakt. Leg geaccepteerde uitzonderingen vast, zodat ze niet bij elke audit opnieuw als onverklaard probleem verschijnen.
Garandeert een technische SEO-audit hogere posities in Google?
Nee. Een audit kan technische beperkingen wegnemen en belangrijke pagina’s beter verwerkbaar maken. Posities hangen ook af van relevantie, bruikbaarheid, concurrentie, reputatie, zoekvraag en andere signalen. Een goed auditrapport beschrijft het verwachte technische resultaat en hoe je dat controleert, zonder er een garantie op hogere posities van te maken.
Wat moet een technisch SEO-auditrapport bevatten?
Elke bevinding die om actie vraagt, bevat bewijs, de getroffen URL-patronen, de bedrijfscontext, de vermoedelijke oorzaak en de gewenste eindsituatie. Ook uitvoeringsinstructies, verantwoordelijkheden, afhankelijkheden en een controlemethode horen erbij. Het uiteindelijke plan groepeert problemen per systeem of template en maakt onderscheid tussen urgente blokkades en verbeteringen die kunnen wachten.
