Technische SEO-audit: van onderzoek naar uitvoerbaar werk

Van onderzoeksvraag naar uitvoerbaar werk

Begin met de benodigde gegevens, werk door de acht onderzoeksgebieden en gebruik daarna de voorbeeldopdracht. Zoek je vooral een herhaalbare afvinklijst? Gebruik dan de afzonderlijke technische SEO-checklist.

Wat is een technische SEO-audit?

Een technische audit is een gericht onderzoek naar de werking van een website en de verwerking door zoekmachines. Je onderzoekt bijvoorbeeld of productcategorieën bereikbaar zijn, of een template de verkeerde canonical levert of waarom een aanvraagformulier op mobiel vastloopt. Een verkeersdaling bewijst op zichzelf niet dat de oorzaak technisch is.

Maak vooraf onderscheid tussen onderzoek, uitvoering en monitoring. Wie krijgt toegang tot welke omgeving? Wie beoordeelt de gewenste indexatie? Wie kan een wijziging testen en terugdraaien? Leg ook uitsluitingen vast. Een technische SEO-audit is geen volledige beveiligingsaudit, juridisch privacyonderzoek of vervanging voor een inhoudelijke beoordeling.

Plan de diepgang rond wijzigingen en risico's: een migratie, nieuwe template of herhaalbare storing kan gerichte controle vragen. Een vaste kwartaalfrequentie voor iedere website is geen universele norm. Spreek af welke controles bij iedere release horen en welke aanleiding uitgebreider onderzoek rechtvaardigt.

Welke vraag moet de audit beantwoorden?

Een bruikbare onderzoeksvraag is concreter dan “maak onze score hoger”. Bijvoorbeeld: waarom ontbreekt de nieuwe productcategorie in de navigatie, terwijl hij wel in het CMS staat? De uitkomst moet helpen een beslissing te nemen. Soms is dat herstellen; soms aanvullend onderzoek of een bewuste uitzondering laten bestaan.

Volgens Googles uitleg van het indexeringsrapport hoeft niet iedere bekende URL geïndexeerd te zijn. Vergelijk de bedoelde openbare pagina's met concrete rapportvoorbeelden. Een status als “gecrawld, momenteel niet geïndexeerd” noemt een toestand, niet automatisch de bewezen oorzaak “slechte kwaliteit”.

Begin met toegang, scope en brongegevens

Welke informatie ondersteunt welke onderzoeksvraag?

Bron	Gebruik	Beperking
CMS-inventaris en sitemap	Bedoelde pagina's en templategroepen afbakenen.	Een sitemap is niet vanzelf de complete inhoudsinventaris.
Een gerichte crawl	Statussen, links en herhaalde patronen onderzoeken.	Instellingen en startpunten bepalen wat gevonden wordt.
Search Console	Beschikbare indexatie- en zoekwaarnemingen bekijken.	Een rapport kan een eerdere toestand of beperkte voorbeelden tonen.
Browser en prestatietests	Rendering, netwerk en bediening reproduceren.	Een labomgeving is niet hetzelfde als echte bezoekers.
Releaselog en toegestane servergegevens	Veranderingen vergelijken met het ontstaan van een probleem.	Een samenloop in de tijd bewijst nog geen oorzaak.

Noteer meetdatum, omgeving, apparaat, crawlerinstellingen en ontbrekende toegang. Stem crawlsnelheid en omvang af met de beheerder, zeker op een kleine server of drukke webshop. Bewaar geen wachtwoorden of onnodige persoonsgegevens in een auditrapport. Kies tools bij de vraag; koop niet automatisch meerdere abonnementen voor een vergelijkbare score.

1. Crawlbaarheid en indexatie onderzoeken

Controleer per representatieve URL de statuscode, robotsinstructies, canonical en bereikbaarheid van hoofdinhoud. Robots.txt regelt crawltoegang, niet de beveiliging van privé-inhoud. Een crawlblokkade is geen betrouwbare verwijdering uit zoekresultaten. Voor noindex moet Google de instructie kunnen lezen.

Vergelijk de sitemap met het bedoelde publicatiebeleid. Onderzoek uitgesloten URL's per groep, niet met de opdracht om alle uitsluitingen op te heffen. Een crawler kan verweesde pagina's missen; combineer daarom een crawl met de CMS-inventaris. Ontbreekt Search Console-toegang, rapporteer indexatiestatus als niet onderzocht in plaats van een technische aanname als Google-waarneming te presenteren.

2. Routes, varianten en eindbestemmingen beoordelen

Doorloop een echte bezoekerstaak, zoals van branche-uitleg naar de passende dienst en aanvraag. Onderzoek ontbrekende routes, onduidelijke ankertekst en verwijzingen naar oude bestemmingen. De richtlijn voor crawlbare links gaat uit van herkenbare links met een href. Er is geen algemeen maximum van drie klikken of 150 links dat iedere auditbevinding beslist.

Beoordeel URL-varianten inhoudelijk. Een canonical geeft een voorkeur bij gelijke of vergelijkbare pagina's; niet iedere variant hoort naar zichzelf te wijzen. Een canonical maakt een noindex-instructie niet automatisch ongeldig. Stel bij noodzakelijke verplaatsingen een mapping op en kies een passende permanente of tijdelijke redirect. Verkort bestaande URL's niet zonder reden.

3. Prestaties meten en de oorzaak isoleren

De Core Web Vitals beoordelen laden, reageren en stabiliteit. De goede grenswaarden zijn LCP ≤ 2,5 seconden, INP ≤ 200 milliseconden en CLS ≤ 0,1, op het 75e percentiel van beschikbare veldmetingen. Houd mobiel en desktop apart. Ontbrekende velddata is onbekend, geen geslaagd resultaat.

Gebruik labtests om een hypothese te onderzoeken: wordt het hoofdbeeld laat ontdekt, blokkeert onnodige code de interactie of verschuift inhoud na het laden? Herhaal onder vergelijkbare omstandigheden en bewaar de instellingen. Maak van een algemeen advies als “meer caching” een controleerbare wijziging voor specifieke bestanden of routes. Cache geen persoonlijke of afgeschermde inhoud alsof het een openbaar beeldbestand is.

4. Structured data tegen de inhoud controleren

Controleer markup op syntax én feiten. Komt de auteur overeen met de zichtbare persoon? Zijn datums echt? Hoort de afbeelding bij dit artikel? De structured-data-richtlijnen maken duidelijk dat correcte markup geen rich-resultgarantie is. Een validator levert dus niet de hele inhoudelijke goedkeuring.

Gebruik geen verouderde opbrengsttabel waarin FAQ-dropdowns en how-to-stappen standaard worden beloofd. Controleer welke functies nog worden ondersteund; Google heeft de FAQ-rich-resultfunctie beëindigd. Nuttige vragen kunnen gewoon voor lezers blijven staan. Verwijder gefingeerde prestaties uit zichtbare tekst én bijbehorende gegevens.

5. Mobiele inhoud en bediening testen

Bij mobile-first indexing staat de mobiele inhoud centraal. Vergelijk hoofdtekst, links en metadata met desktop. Een uitklapsectie kan passend zijn; noodzakelijke inhoud pas na een klik ophalen is een andere situatie. Leg vast wat werkelijk in de pagina aanwezig is.

Test daarnaast formulieren, navigatie, focus, grotere tekst en contactknoppen. Een pagina kan op een screenshot netjes passen terwijl een vaste balk een veld bedekt. Een brede datatabel mag een eigen toegankelijke scrollzone hebben; horizontale pagina-overloop is iets anders. Gebruik echte handelingen in plaats van uitsluitend een responsive-vinkje.

6. Verbinding en beheerrisico's afbakenen

Controleer het certificaat, de bedoelde HTTPS-route en mixed content. Onderzoek bij een browserwaarschuwing welke bron of configuratie faalt. Schakel beveiliging niet uit om een test groen te krijgen. Laat wijzigingen aan beveiligingsheaders door de beheerder beoordelen, inclusief formulieren, embeds en relevante subdomeinen.

Een header-score A of A+ is geen bewijs van volledige veiligheid. Benoem de grens van de audit en verwijs een concreet beveiligingsrisico naar de verantwoordelijke specialist. Een indexatieverbetering heeft niet automatisch voorrang boven een echt beveiligingsincident.

7. Server-HTML en gerenderde inhoud vergelijken

Vergelijk het antwoord van de server met de gerenderde pagina en beschikbare URL-inspectie. Controleer hoofdinhoud, links, fouten en benodigde bestanden. Google kan JavaScript verwerken; daar hoort geen universele vaste wachttijd bij. De frameworknaam is geen audituitkomst.

Server-rendering en statische generatie kunnen inhoud al als HTML leveren. Test vervolgens of interactie na het laden blijft werken. Gebruik geen verdwenen cache-zoekfunctie als controle en onderdruk geen renderingwaarschuwing zonder de oorzaak te begrijpen. De uitleg van technische SEO beschrijft het verschil tussen deze onderdelen.

8. Taal- en regioversies alleen waar relevant

Inventariseer welke pagina's inhoudelijke alternatieven zijn voor andere talen of landen. Controleer volgens Googles hreflang-documentatie de codes, volledige URL's en wederzijdse verwijzingen. Hreflang duidt alternatieven aan; het is geen algemene oplossing om duplicaten te verwijderen.

HTML, HTTP-headers en sitemap zijn gelijkwaardige methoden. Meerdere methoden zijn niet verboden, maar vragen meer onderhoud. Een x-default kan een passende terugvalpagina aanduiden; voeg hem niet blind overal toe. Heeft de site geen dergelijke alternatieven, noteer dit onderdeel als niet van toepassing met een korte reden.

Wanneer is een bevinding bruikbaar?

• De scope en betrokken URL's zijn benoemd.
• De waarneming is met datum en omstandigheden reproduceerbaar.
• Het gewenste gedrag is door de juiste eigenaar bevestigd.
• Een verklaring is onderscheiden van een bewezen oorzaak.
• Uitvoering, acceptatie en nacontrole hebben een verantwoordelijke.

Een lange export met rode regels voldoet hier niet automatisch aan. Groepeer een gedeelde templateoorzaak, maar controleer uitzonderingen. Gebruik de herhaalbare checklist als werkblad, niet als universeel keurmerk.

Voorbeeld: een categorie ontbreekt in de route

Fictieve bevinding: een nieuwe productcategorie bestaat, maar is niet bereikbaar via het categorieoverzicht. Dit is een uitgewerkt werkvoorbeeld, geen vastgestelde klantfout of gemeten rankingresultaat.

Een auditbevinding overdraagbaar maken

Veld	Ingevuld voorbeeld
Waarneming	Categorie aanwezig in CMS; de verwachte overzichtslink ontbreekt in bron-HTML en browser.
Afspraak	Inhoudseigenaar bevestigt dat de categorie openbaar en via dit overzicht bereikbaar hoort te zijn.
Onderzoek	Developer controleert de selectievoorwaarden van het categorieoverzicht; de oorzaak staat nog niet vast.
Acceptatie	Na passend herstel staat één beschrijvende link naar de juiste eindbestemming in de bedoelde route.
Nacontrole	De gepubliceerde versie en overige categorieën worden hertest; latere indexatie wordt apart gevolgd.

1. Waarnemen. Bewaar wat je werkelijk hebt getest.
2. Beoordelen. Bevestig gewenst gedrag en gevolgen.
3. Toewijzen. Maak een afgebakende opdracht met eigenaar.
4. Hertesten. Controleer de juiste versie en de afgesproken route.

Bespreek uitvoering en monitoring apart van de onderzoeksoplevering. Bij technische SEO bij Pico Yellow bepalen we scope, toegang en verantwoordelijkheden in overleg. Een vrijblijvend adviesgesprek is de start; de offerte blijft op maat.

Valkuilen in de audit zelf

De grootste fout is een waarschuwing zonder context als opdracht doorgeven. Andere valkuilen zijn privé-inhoud in een rapport opnemen, alle varianten tegelijk aanpassen, een steekproef als volledige dekking presenteren en een nieuwe crawl verwarren met bewezen bedrijfsresultaat. Vermeld ook welke onderdelen niet zijn onderzocht. Dat maakt de oplevering bruikbaarder dan een schijnbaar volledig rapport.

Veelgestelde vragen

Wat krijg ik na een technische audit?

Een afgesproken inventaris van bevindingen met bewijs, prioriteit, beperkingen en verantwoordelijkheden. Controleer vooraf of implementatie en nacontrole deel uitmaken van de opdracht.

Kan ik starten zonder Search Console?

Ja, met een technische inventaris en browsercontroles. Noem Google's indexatie- en zoekgegevens dan expliciet ontbrekend. Een eigen crawl is geen vervanging voor die gegevens.

Moet de hele website worden gecrawld?

Dat hangt af van de vraag en het risico. Begin met representatieve templates en breid gericht uit. Leg de dekking vast en stem belasting op de server af.

Is een audit ook een beveiligingsonderzoek?

Niet automatisch. Een technische SEO-audit kan verbindingsproblemen signaleren, maar een volledige beveiligingsbeoordeling vraagt een eigen scope en specialistische expertise.

Welke melding heeft altijd voorrang?

Geen enkele categorie bepaalt dat zonder context. Bereik, gebruikersgevolgen, veiligheid en risico van de ingreep bepalen samen de prioriteit.

Hoeveel kost een audit?

De omvang hangt af van templates, talen, koppelingen, toegang en diepgang. Vraag om een concrete scope en een offerte op maat, inclusief wat niet is inbegrepen.

Wanneer is een bevinding opgelost?

Wanneer de afgesproken hertest op de bedoelde gepubliceerde versie slaagt. Een melding in Google kan nog een oudere toestand beschrijven; controleer de meetdatum afzonderlijk.

Hoe vaak herhaal ik de audit?

Stem periodieke controles af op wijzigingen en risico. Leg daarnaast vast welke tests verplicht zijn bij een release en welke incidenten nieuw onderzoek starten.