Website-audit: eerste stappen voor een bruikbaar overzicht (2026)

Een bruikbare website-audit geeft eerst antwoord op één vraag: wat wil je controleren en welke verandering mag je veilig voorstellen? Begin met een beperkte route, noteer de huidige situatie en wijzig tijdens de audit nog niets.

Stappenplan

1. Kies doel en bereik

Kies bijvoorbeeld bereikbaarheid, formulierroute, snelheid of een redesign. Noteer de homepage, twee belangrijke instappagina's en de contactpagina. Gebruik de livegangchecklist als de audit naar een publicatie leidt.

Formuleer het doel als een vraag die je met waarnemingen kunt beantwoorden. Bijvoorbeeld: “kan een bezoeker de dienst vinden en een veilig testbericht versturen?” of “verwijzen oude belangrijke URL's naar een passende bestemming?” Zet er een grens bij: welke pagina's, apparaten en periode vallen binnen deze eerste ronde? Zonder die grens groeit een audit snel uit tot losse opmerkingen waar niemand een besluit op kan nemen.

Gebruik website-offertes vergelijken zonder prijzen wanneer de audit later een externe opdracht kan worden: daarmee zet je doel, scope en acceptatie vóór de uitvoering naast elkaar.

2. Leg de huidige toestand vast

Test in een gewone browser of de gekozen pagina's laden, links werken en een testformulier de afgesproken bestemming bereikt. MDN legt uit hoe HTTP-statuscodes verschillende serverreacties aanduiden; een status alleen bewijst geen oorzaak.

Leg per route vast wat je deed en wat je zag. Open de URL, volg een relevante link, controleer de zichtbare inhoud en gebruik voor een formulier uitsluitend een veilig testbericht. Noteer browser, tijdstip en fouttekst wanneer iets afwijkt. Een serverantwoord is een technisch signaal; vergelijk het daarom met wat de bezoeker ziet. Een pagina kan bijvoorbeeld technisch laden en toch een onbruikbare navigatie of verkeerd contactadres tonen.

3. Kies bewijs per onderwerp

Voor snelheid kun je veld- en labgegevens onderscheiden met de Web Vitals-uitleg. Voor toegankelijkheid begin je bij de eerste toegankelijkheidscheck, niet bij een claim dat een site conform is.

Gebruik voor een snelheidsvraag vervolgens de eerste Core Web Vitals-controle, zodat je meetbron, gebruikerspad en hertest in dezelfde volgorde vastlegt.

Kies voor elk onderwerp een passende vorm van bewijs. Bij snelheid noteer je bron, URL en testopzet in plaats van één losse score. Bij toegankelijkheid loop je een taak met toetsenbord en een formulierfoutpad na. Bij redirects controleer je oude URL, bestemming en zichtbare bedoeling. Bij inhoud kijk je of titel, koppen en linktekst de vraag op de pagina nog beantwoorden. Zo voorkom je dat één toolrapport als conclusie voor alle onderdelen wordt gebruikt.

4. Maak een volgorde en eigenaar

Zet per bevinding neer: wat zie je, welke route raakt het, wie beslist en hoe controleer je een wijziging. Link een technische wijziging aan DNS zonder uitval of aan de relevante platformdocumentatie.

Maak een kleine prioriteitenlijst. Beschrijf de observatie zonder oorzaak te gokken, bijvoorbeeld “testbericht geeft bevestiging maar komt niet aan” of “oude URL eindigt op een niet-passende pagina”. Noteer vervolgens impact op de gekozen route, vermoedelijke eigenaar, voorgestelde volgende controle en een herstelgrens. Vermijd adviezen als “optimaliseer alles” of “maak de site sneller”; zij zeggen niet wie wat wanneer kan verifiëren.

Besliskader: wat moet als eerste?

Geef blokkades voor een bezoeker voorrang: een niet bereikbare pagina, browserwaarschuwing, kapotte navigatie, fout formulier of ontbrekende essentiële informatie. Daarna komen afwijkingen die het begrip of de betrouwbaarheid van een belangrijke route verminderen. Een kleine tekst- of opmaakverbetering is pas aan de beurt wanneer het kernpad werkt. Baseer de volgorde op de afgesproken doelroute, niet op het aantal meldingen dat een scanner produceert.

Gebruik groen, oranje en rood als besluitvorm. Groen: de route werkt zoals omschreven en er is geen wijziging nodig. Oranje: je hebt een concrete verbetering met eigenaar en hertest, maar de bezoeker kan de taak nog uitvoeren. Rood: een kernactie is geblokkeerd, persoonsgegevens kunnen in een onveilige test terechtkomen, HTTPS waarschuwt of een verandering raakt DNS of productie zonder herstelplan. Bij rood stop je met verdere wijzigingen en leg je de oorzaak eerst afgebakend voor aan de eigenaar.

Herstel en hertest

Een audit zelf wijzigt niets. Als je een bevinding omzet in werk, kies dan één herstelbare aanpassing en noteer het verwachte effect. Test na de wijziging dezelfde route én een route die mogelijk mee geraakt is. Bij een formulier controleer je bijvoorbeeld invoer, foutmelding, bevestiging en ontvangst. Bij een redirect controleer je zowel de oude URL als de nieuwe bestemming. Gebruik de contactformuliercontrole en de livegangchecklist voor die hertest.

Als de audit uitwijst dat vooral structuur en vormgeving veranderen, gebruik dan redesign zonder verkeersverlies om URL-keuzes, inhoudelijke intentie en een herstelroute vóór de publicatie te ordenen.

Leg het resultaat beknopt vast: datum, scope, gecontroleerde routes, observaties, besluiten, eigenaar en open punten. Bewaar geen inloggegevens, tokens, complete bezoekersdata of gevoelige screenshots in het auditbestand. Plan een volgende ronde alleen wanneer een wijziging, nieuwe pagina of veranderde afhankelijkheid daar aanleiding toe geeft. Daarmee blijft de audit een bruikbaar overzicht en geen eenmalige lijst zonder vervolg.

Praktijkcheck voor een auditronde

Begin een auditronde met dezelfde korte set vragen voor elke route: opent de pagina, is het doel duidelijk, werkt de volgende actie, komt een veilig testbericht aan en is er een onverwachte fout? Noteer de uitkomst direct naast URL en tijdstip. Deze vaste volgorde maakt resultaten vergelijkbaar en voorkomt dat je alleen de opvallendste pagina's bekijkt. Als een route buiten scope valt, schrijf je dat expliciet op in plaats van hem stilzwijgend als goed te beschouwen.

Bespreek de bevindingen daarna met de eigenaar van de route. Vraag welke wijziging haalbaar is, welk risico die kan raken en hoe je de uitkomst controleert. Een audit wordt pas bruikbaar wanneer een observatie kan leiden tot een afgebakende beslissing. Zonder eigenaar of herstelgrens blijft het een signaal, geen uitvoerbaar verbeterpunt.

Veelgemaakte fouten

• Een audit en reparatie door elkaar halen. Verzamel eerst bewijs en kies daarna één wijziging.
• Alleen één testbrowser gebruiken. Controleer het afgesproken gebruikerspad op een tweede apparaat of browser.
• Een toolscore als eindconclusie nemen. Lees wat de meting wel en niet meet.
• Geen contactroute testen. Een site kan laden terwijl een aanvraag niet aankomt.
• Zonder herstelgrens aanbevelen. Benoem wat je terugdraait als een wijziging afwijkt.

Officiële bronnen

MDN HTTP-statuscodes · web.dev over Web Vitals

Wil je de audit laten omzetten naar een afgebakend plan, stel je vraag via WhatsApp.