Website-audit in 2026: de complete checklist voor SEO, Core Web Vitals, toegankelijkheid en beveiliging

In 2026 moet een audit in lagen worden uitgevoerd. Google baseert zichtbaarheid nog steeds op technische fundamenten en content die in de eerste plaats voor mensen is gemaakt, al kunnen resultaten ook in AI-gestuurde functies verschijnen. Core Web Vitals moeten met echte gebruikersdata worden beoordeeld, toegankelijkheid kan niet met alleen een scanner worden bevestigd en beveiliging vraagt om meer dan een SSL-certificaat.

Deze gids behandelt het volledige proces: indexering en SEO, LCP, INP en CLS, WCAG 2.2, beveiligingsheaders, formulieren, analytics en de juiste volgorde van verbeteringen.

TL;DR: begin met kritieke problemen: uitval, blokkades voor indexering, verkeerde redirects, HTTPS-problemen en kwetsbaarheden. Verbeter daarna Core Web Vitals, de toegankelijkheid van belangrijke gebruikerspaden, content en interne links. Een score van 100/100 in één tool vervangt geen Search Console-data, tests op echte apparaten of handmatige controle.

Normen, drempelwaarden en bronnen zijn voor het laatst gecontroleerd op 23 juli 2026.

De belangrijkste onderdelen van de audit

Onderdeel	Wat controleren	Hoe een goed resultaat eruitziet	Prioriteit
Indexering	robots.txt, noindex, sitemap, canonical, HTTP-statuscodes	belangrijke pagina’s zijn bereikbaar en indexeerbaar, duplicaten zijn samengevoegd	kritiek
SEO en content	zoekintentie, titels, koppen, interne links, structured data	elke belangrijke pagina heeft een duidelijk doel en unieke waarde	hoog
Prestaties	LCP, INP, CLS, TTFB, JavaScript, afbeeldingen, lettertypen	CWV vallen bij het 75e percentiel in de categorie ‘goed’	hoog
Toegankelijkheid	toetsenbord, focus, semantiek, contrast, formulieren, schermlezers	belangrijke paden voldoen aan WCAG 2.2 AA	hoog
Beveiliging	HTTPS, headers, cookies, afhankelijkheden, autorisatie, back-ups	geen kritieke kwetsbaarheden of onnodige blootstelling	kritiek
UX en conversie	mobiel, formulieren, navigatie, fouten, vertrouwen	gebruiker rondt de hoofdtaak zonder onnodige frictie af	hoog
Meting	Search Console, analytics, logs, monitoring	data is volledig, privacyvriendelijk en bruikbaar	middel

Wat omvat een website-audit werkelijk?

Een complete audit combineert minstens zes perspectieven:

1. Technische SEO - kan een crawler de website openen, renderen, links volgen en de juiste canonieke URL herkennen?
2. Contentkwaliteit - beantwoordt de pagina een echte behoefte, heeft zij een logische structuur en voorkomt zij onnodige duplicatie?
3. Prestaties - hoe snel verschijnt de hoofdcontent, hoe snel reageert de pagina en verschuift de lay-out tijdens het laden?
4. Toegankelijkheid - is de dienst bruikbaar met toetsenbord, schermlezer en zoom, zonder uitsluitend op kleur te vertrouwen?
5. Beveiliging en privacy - zijn communicatie, sessies, formulieren, afhankelijkheden en gebruikersgegevens voldoende beschermd?
6. UX en bedrijfsdoelen - begrijpen bezoekers het aanbod en kunnen zij de belangrijkste actie zonder onnodige stappen uitvoeren?

Automatische tools zijn een goed begin, maar kunnen niet alles beoordelen. Lighthouse kan een deel van de prestatie- en toegankelijkheidsproblemen vinden, maar niet bepalen of een aanbod begrijpelijk is, een formulier aansluit op de behoefte van de klant of een foutmelding echt helpt om verder te gaan.

Voor je begint: bepaal de scope en URL-steekproef

De meest voorkomende fout is alleen de homepage scannen. In de praktijk moet je representatieve paginatypen testen:

• homepage,
• belangrijkste dienst- of productpagina,
• artikel of handleiding,
• categorie of overzicht,
• contactformulier, registratie of checkout,
• zoekresultatenpagina,
• taalversie,
• 404-pagina en andere foutstatussen,
• afgeschermde pagina, indien van toepassing.

Voor een kleine website kan een steekproef van enkele of een tiental URL’s voldoende zijn. Bij een webshop, portaal of applicatie moet je templates beoordelen in plaats van willekeurige URL’s. Als één producttemplate een verkeerde canonical heeft of een zwaar script laadt, kan het probleem duizenden pagina’s raken.

Verzamel vooraf:

• toegang tot Google Search Console en analytics,
• een lijst met de belangrijkste bedrijfsdoelen,
• sitemap en belangrijkste templates,
• informatie over wijzigingen, migraties en verkeersdalingen,
• foutmonitoring en serverlogs,
• apparaten en browsers die klanten het vaakst gebruiken.

1. Audit van technische SEO en indexering

Controleer HTTP-statuscodes en domeinvarianten

Elke belangrijke URL moet de juiste status teruggeven:

• 200 voor een werkende pagina,
• 301 of 308 voor een permanente redirect,
• 404 of 410 voor verwijderde content,
• 5xx alleen bij een echte serverfout, niet als permanente toestand.

Controleer http/https, www/non-www, afsluitende slashes en hoofdletters. Alle varianten moeten naar één consistente versie leiden. Vermijd redirectketens en situaties waarin veel oude URL’s zonder inhoudelijke relatie naar de homepage worden gestuurd.

Controleer robots.txt, noindex en toegang tot bronnen

Het bestand robots.txt regelt crawling op het niveau van ophalen, maar verwijdert een pagina niet uit zoekresultaten. Een geblokkeerde URL kan nog steeds in de index verschijnen als Google haar via andere bronnen kent. Gebruik voor uitsluiting bijvoorbeeld noindex, wachtwoordbeveiliging of verwijdering van de resource.

Controleer of:

• belangrijke secties niet per ongeluk zijn geblokkeerd,
• de testomgeving echt is afgeschermd en niet alleen in robots.txt verborgen,
• Google CSS, JavaScript en afbeeldingen voor rendering kan ophalen,
• de sitemap op de juiste locatie staat en alleen canonieke pagina’s bevat,
• geen noindex is achtergebleven na publicatie.

Beoordeel canonicals en duplicaten

Een canonieke URL geeft de voorkeursversie van dubbele of sterk gelijkende content aan. Google beschouwt canonicalisatie als een sterk signaal, maar kan een andere URL kiezen als de overige signalen tegenstrijdig zijn.

Controleer de samenhang tussen:

• rel="canonical",
• redirects,
• interne links,
• XML-sitemaps,
• taalversies,
• protocol en host.

Een canonical hoort doorgaans naar een werkende URL met status 200 te wijzen, niet naar een foutpagina, redirect of URL met noindex.

Controleer JavaScript-rendering

Google verwerkt JavaScript-applicaties in fasen: crawlen, renderen en indexeren. Content die client-side wordt gegenereerd kan later worden verwerkt dan direct beschikbaar HTML. Kritieke informatie en links mogen daarom niet afhangen van een kwetsbaar script.

Controleer bij SPA’s en hybride diensten:

• HTML dat vóór JavaScript-uitvoering beschikbaar is,
• links als echte <a href>-elementen,
• afhandeling van statuscodes,
• metadata per URL,
• gedrag bij directe toegang tot een subpagina,
• hydration-fouten en mislukte API-aanvragen,
• indexeerbaarheid van paginering en infinite scroll.

Controleer taalversies

Op een meertalige website hoort elke versie een eigen stabiele URL te hebben. Controleer:

• geldige hreflang-attributen,
• wederzijdse verwijzingen tussen versies,
• optioneel x-default,
• een canonical naar dezelfde taalversie,
• geen automatische redirects die crawlers blokkeren,
• vertaalde titels, beschrijvingen, content en navigatie.

Checklist technische SEO

• Belangrijke URL’s geven 200.
• Redirects zijn enkelvoudig en logisch.
• Er zijn geen onbedoelde robots.txt-blokkades.
• Productie bevat geen onbedoelde noindex.
• De XML-sitemap bevat alleen canonieke URL’s.
• Canonicals, links en sitemap zijn consistent.
• JavaScript verbergt geen kritieke content voor crawlers.
• 404-pagina’s geven echt status 404.
• Taalversies gebruiken correcte hreflang.
• Parameters en filters veroorzaken geen massale duplicatie.

2. Audit van content en on-page SEO

Elke pagina moet één hoofddoel hebben

Titel, H1, introductie, hoofdtekst en call-to-action moeten dezelfde intentie dienen. Als één pagina tegelijk een dienst wil verkopen, basisbegrippen wil uitleggen en op een reeks ongerelateerde zoekopdrachten wil scoren, doet zij meestal geen van die taken goed.

Controleer:

• of de title uniek en beschrijvend is,
• of de H1 de inhoud weerspiegelt,
• of het zoekresultaat uitnodigt tot klikken zonder overdreven beloften,
• of H2- en H3-koppen een logische structuur vormen,
• of het antwoord vroeg verschijnt en niet na een lange inleiding,
• of het artikel ervaring, voorbeelden en bronnen toont,
• of de update-datum bij een echte inhoudelijke wijziging hoort.

Google beveelt behulpzame, betrouwbare content aan die primair voor mensen is gemaakt, niet pagina’s die uitsluitend rankings proberen te manipuleren.

Interne links moeten structuur creëren

Goede interne links helpen de gebruiker verder en tonen zoekmachines de relatie tussen onderwerpen. Gebruik beschrijvende ankerteksten in plaats van veel generieke ‘klik hier’-links.

Logische vervolgstappen vanuit dit artikel zijn:

• Websitestatuscontrole van POLPROG,
• Core Web Vitals in de praktijk,
• Webstrategie,
• Prestaties,
• Beveiliging,
• Een bedrijfswebsite plannen die leads genereert.

Zoek ook naar verweesde pagina’s waar geen interne link naartoe leidt.

Afbeeldingen, structured data en Open Graph

Afbeeldingen moeten betekenisvolle bestandsnamen, passende afmetingen en alternatieve tekst hebben wanneer ze informatie overbrengen. Een decoratieve afbeelding hoort meestal een lege alt="" te gebruiken. Google ondersteunt onder meer JPEG, PNG, WebP, SVG en AVIF.

Controleer:

• width en height om lay-outverschuivingen te beperken,
• srcset en sizes,
• compressie en bestandsformaat,
• lazy loading onder de eerste viewport,
• alternatieve tekst,
• structured data die overeenkomt met zichtbare content,
• og:title, og:description, og:image en og:url.

Gebruik voor praktische controle de Afbeeldingsconverter en -optimalisator en de Open Graph-voorvertoning.

SEO in AI-gestuurde zoekervaringen

Google geeft aan dat voor AI-functies in Search nog steeds dezelfde SEO-basispraktijken gelden. Er zijn geen speciale bestanden of nieuwe markeringen nodig alleen om in AI Overviews of AI Mode te verschijnen. De pagina moet indexeerbaar zijn en aan de normale Search-vereisten voldoen.

De meest verstandige aanpak is:

• duidelijke, volledige antwoorden publiceren,
• bronnen en praktische voorbeelden gebruiken,
• snel veranderende informatie actualiseren,
• massaal geproduceerde, herhalende content vermijden,
• semantische structuur en interne links onderhouden,
• verkeer en zoekopdrachten in Search Console volgen.

3. Core Web Vitals en prestaties

Actuele drempelwaarden

Core Web Vitals bestaan uit drie meetwaarden. De beoordeling moet gebeuren op het 75e percentiel van echte bezoeken, apart voor mobiel en desktop.

Meetwaarde	Wat wordt gemeten	Goed	Verbetering nodig	Slecht
LCP	moment waarop het grootste content-element verschijnt	≤ 2,5 s	2,5-4,0 s	> 4,0 s
INP	reactievertraging bij interacties	≤ 200 ms	200-500 ms	> 500 ms
CLS	visuele stabiliteit van de lay-out	≤ 0,1	0,1-0,25	> 0,25

Velddata toont de ervaring van echte gebruikers; labdata helpt een probleem te reproduceren. Verwar beide niet. Een site kan lokaal goed scoren in Lighthouse, maar een slechte INP hebben op oudere telefoons of een trage LCP in een bepaald land.

LCP verbeteren

Veelvoorkomende oorzaken:

• trage server of ontbrekende cache,
• te zware hero-afbeelding,
• LCP-resource pas via JavaScript ontdekt,
• renderblokkerende CSS en fonts,
• lange requestketens,
• zware logica vóór rendering.

Maatregelen:

• verbeter TTFB en caching,
• lever de afbeelding in de juiste afmetingen,
• gebruik moderne formaten en compressie,
• prioriteer de belangrijkste resource,
• gebruik geen lazy loading voor de LCP-afbeelding,
• beperk kritieke CSS en scripts,
• gebruik een CDN wanneer dit de route naar gebruikers werkelijk verkort.

INP verbeteren

INP verslechtert door lange taken op de main thread, te veel JavaScript, duur componentrendering en eventhandlers die te veel werk uitvoeren.

Controleer:

• taakduur in het Performance-paneel,
• scripts van derden,
• componenten die bij elke wijziging opnieuw renderen,
• grote lijsten zonder virtualisatie,
• synchrone geheugen- en DOM-bewerkingen,
• formuliervalidatie en animaties tijdens interactie.

Splits lange taken op, stel niet-kritiek werk uit en verstuur zo weinig mogelijk JavaScript.

CLS verbeteren

Veelvoorkomende bronnen van verschuivingen:

• afbeeldingen en iframes zonder afmetingen,
• advertenties zonder gereserveerde ruimte,
• cookiebanners boven content,
• laat geladen fonts,
• componenten die vóór bestaande content worden toegevoegd,
• animaties van lay-outbeïnvloedende eigenschappen.

Reserveer ruimte, gebruik stabiele placeholders en test het hele laadproces, niet alleen het eindbeeld.

Optimaliseer niet alleen voor Lighthouse

Lighthouse is een labtest onder gecontroleerde omstandigheden. Een sterk proces combineert:

• Search Console en het Core Web Vitals-rapport,
• CrUX- of RUM-data,
• Lighthouse en het Performance-paneel,
• tests op een trager apparaat,
• regressiemonitoring na publicatie.

4. Toegankelijkheidsaudit volgens WCAG 2.2

WCAG 2.2 bevat criteria die met geautomatiseerde én menselijke evaluatie worden getest. Een scanner kan volledige conformiteit niet bevestigen, omdat sommige criteria context en interactietests vereisen.

Toetsenbord en focus

Doorloop het belangrijkste pad zonder muis:

• is elk interactief element bereikbaar,
• is de focusvolgorde logisch,
• is de focusindicator duidelijk zichtbaar,
• houdt een modal de focus vast en geeft hij die terug na sluiten,
• is er geen toetsenbordval,
• kan herhaalde navigatie worden overgeslagen.

Semantiek en schermlezers

Controleer:

• één logische H1 en correcte koppenhiërarchie,
• landmarks header, nav, main en footer,
• echte knoppen en links in plaats van klikbare div-elementen,
• toegankelijke namen voor pictogrammen,
• aankondigingen van dynamische wijzigingen,
• correcte leesvolgorde,
• documenttaal in het lang-attribuut.

ARIA moet semantische HTML aanvullen, niet zonder reden vervangen.

Formulieren en fouten

Elk veld moet een zichtbare label en een programmatische koppeling met de beschrijving hebben. Een fout moet uitleggen wat gecorrigeerd moet worden en mag niet alleen door kleur worden aangegeven.

Test:

• labels en instructies,
• verplichte velden,
• autocomplete-attributen,
• tabvolgorde,
• foutmeldingen,
• foutsamenvatting na verzenden,
• gedrag bij zoom en op een smal scherm,
• tijdslimieten en de mogelijkheid tot verlengen.

Contrast, zoom en beweging

Controleer contrast van tekst, pictogrammen en focusstatussen. Test bij 200% en 400% zoom, grotere tekst en een smalle viewport. Content mag geen horizontale scroll vereisen, behalve waar dat functioneel nodig is.

Animaties moeten prefers-reduced-motion respecteren. Automatisch bewegende content moet kunnen worden gepauzeerd als zij de begrijpelijkheid beïnvloedt.

Checklist toegankelijkheid

• De volledige route werkt met toetsenbord.
• Focus is zichtbaar en logisch.
• Koppen en landmarks beschrijven de structuur.
• Knoppen en links hebben begrijpelijke namen.
• Formulieren hebben labels en bruikbare fouten.
• Contrast voldoet aan WCAG 2.2 AA.
• Content werkt bij zoom en reflow.
• Informatieve afbeeldingen hebben passende alternatieve tekst.
• Beweging kan worden verminderd.
• Belangrijke taken zijn met een schermlezer getest.

5. Audit van beveiliging en privacy

HTTPS is het begin, niet het einde

De hele website moet via HTTPS werken zonder actieve mixed content. Controleer certificaatgeldigheid, vertrouwensketen, ondersteunde protocollen, automatische vernieuwing en redirect van HTTP naar HTTPS. Lighthouse markeert pagina’s zonder HTTPS, maar voert geen volledige penetratietest uit.

Controleer domein en certificaat met de DNS- en SSL-inspecteur.

Beveiligingsheaders

Headers herstellen geen kapotte autorisatie, maar beperken wel aanvalsklassen en onveilig browsergedrag. Het OWASP Secure Headers Project onderhoudt actuele aanbevelingen en voorbeelden.

Controleer minimaal:

• Content-Security-Policy,
• Strict-Transport-Security,
• X-Content-Type-Options: nosniff,
• Referrer-Policy,
• Permissions-Policy,
• bescherming tegen framing via frame-ancestors,
• veilige cookie-attributen: Secure, HttpOnly en passend SameSite.

Voer CSP stapsgewijs in: begin met Content-Security-Policy-Report-Only, analyseer rapporten en schakel daarna handhaving in. Een gekopieerde configuratie moet worden aangepast aan de werkelijk gebruikte resources.

Gebruik de Inspecteur van beveiligingsheaders voor een snelle controle.

OWASP Top 10:2025 als risicokaart

OWASP Top 10:2025 omvat onder meer gebrekkige toegangscontrole, beveiligingsmisconfiguratie, supply-chain-fouten, cryptografische fouten, injectie, onveilig ontwerp, authenticatiefouten, integriteitsproblemen, tekortschietende logging en waarschuwingen en onjuiste afhandeling van uitzonderlijke omstandigheden.

Controleer praktisch:

• of één gebruiker gegevens van een ander kan lezen of wijzigen,
• of het beheerpaneel extra bescherming heeft,
• of de API bevoegdheden server-side controleert,
• of afhankelijkheden en containerimages worden bijgewerkt,
• of geheimen buiten repository en clientcode blijven,
• of invoer wordt gevalideerd en uitvoer gecodeerd,
• of sessies verlopen en kunnen worden ingetrokken,
• of logs geen wachtwoorden, tokens of gevoelige data bevatten,
• of fouten stacktraces en infrastructuurdetails verbergen,
• of back-ups bestaan en herstel getest is.

Voor applicaties met login, betalingen of klantgegevens moet de scope op OWASP ASVS worden gebaseerd, niet alleen op een korte headerlijst.

Privacy en analytics

Controleer:

• welke scripts vóór toestemming starten,
• of formulieren alleen noodzakelijke gegevens verzamelen,
• bewaartermijnen,
• toegang van medewerkers en leveranciers,
• mogelijkheid om toestemming in te trekken,
• Consent Mode-configuratie, indien gebruikt,
• logging van IP-adressen en identifiers,
• of de privacyverklaring overeenkomt met werkelijk gedrag.

Neem niet aan dat een cookiebanner automatisch compliance garandeert. Wat telt is wat de website daadwerkelijk laadt en verstuurt.

6. UX, mobiel en conversie

Een technische audit kan slagen terwijl de site haar doel niet bereikt. Doorloop de belangrijkste route als nieuwe gebruiker:

• is in het eerste scherm duidelijk wat het bedrijf doet,
• beschrijft elke CTA een concrete actie,
• is navigatie begrijpelijk zonder gokken,
• vraagt het formulier alleen noodzakelijke informatie,
• zijn fouten eenvoudig te herstellen,
• zijn telefoon en e-mail tikbaar op mobiel,
• overlappen elementen elkaar niet,
• laten pop-ups de content bruikbaar,
• zijn succesmeldingen ondubbelzinnig,
• werkt de site bij trage verbinding en mislukte aanvragen.

Test ook de 404-pagina, lege zoekresultaten, niet-beschikbare producten of diensten, verlopen sessies en mislukte betalingen. Juist uitzonderlijke situaties bepalen vaak of een gebruiker terugkomt.

Voor leadgeneratie: Een bedrijfswebsite plannen die leads genereert.

7. Meting, monitoring en datakwaliteit

Search Console laat zien hoe de site in Google Search presteert, terwijl analytics toont wat gebruikers na aankomst doen. Door beide te combineren kun je een zichtbaarheidsprobleem onderscheiden van een conversieprobleem.

Controleer:

• of de Search Console-property de juiste domeinvariant omvat,
• indexeringsfouten en handmatige maatregelen,
• zoekopdrachten, pagina’s, landen en apparaten,
• veranderingen in klikken en vertoningen na publicatie,
• volledigheid van analytics-events,
• uitsluiting van intern verkeer en bots,
• juistheid van de conversiefunnel,
• waarschuwingen voor JavaScript- en serverfouten,
• monitoring van uptime en certificaat.

Los niet alles tegelijk op zonder nulmeting. Leg de uitgangssituatie vast en publiceer wijzigingen in groepen om hun effect te meten.

Hoe lang duurt een audit?

De volgende waarden zijn praktische schattingen, geen officiële norm. De scope hangt af van aantal templates, datatoegang, technologie en risiconiveau.

Scope	Indicatieve tijd	Omvat
Snelle controle van één URL	15-30 min	status, metadata, basis-CWV, HTTPS en grote fouten
Kleine bedrijfswebsite	2-6 uur	steekproef, SEO, CWV, toegankelijkheid, beveiliging en UX
Content- of meertalige website	1-3 dagen	templates, indexering, hreflang, links, data en prioriteiten
Webshop	3-7 dagen	categorieën, producten, filters, checkout, structured data en prestaties
Webapplicatie	5-10+ dagen	rollen, autorisatie, processen, API, foutstatussen en handmatige tests
Beveiligingsaudit met hoog risico	aparte scope	threat modeling, ASVS, applicatie- en infrastructuurtests

Kosten groeien minder door het ruwe aantal URL’s dan door het aantal verschillende gedragingen. Duizend producten op één template kunnen eenvoudiger zijn dan een applicatie met tien rollen en veel statussen.

Hoe prioriteer je verbeteringen?

Gebruik een eenvoudig model: impact × bereik × risico ÷ implementatiekosten.

P0 - direct oplossen

• site of kritieke functie is niet beschikbaar,
• belangrijke secties zijn geblokkeerd voor indexering,
• datalek of omzeiling van autorisatie,
• verlopen certificaat of actieve mixed content,
• migratie veroorzaakt massale fouten en verloren URL’s,
• formulier levert aanvragen niet af.

P1 - hoge prioriteit

• slechte CWV op belangrijke templates,
• ernstige barrières bij toetsenbord en formulieren,
• verkeerde canonicals of hreflang,
• onduidelijk aanbod en moeilijke conversie,
• kritieke afhankelijkheden zonder patches,
• geen monitoring van belangrijke fouten.

P2 - inplannen in volgende cyclus

• dubbele titels en zwakke interne links,
• ontbrekende alt-teksten,
• zware afbeeldingen onder de eerste viewport,
• inconsistente structured data,
• zwakke 404- en lege statussen,
• problemen op minder populaire templates.

P3 - optimalisatie en groei

• aanvullende structured data,
• verdere gewichtsreductie,
• experimenten met tekst en CTA’s,
• uitbreiding van content,
• opschoning van componenten en documentatie.

Herstelplan voor 30, 60 en 90 dagen

Eerste 30 dagen

Los P0-problemen, indexering, redirects, HTTPS, formulieren en risico’s op dataverlies op. Leg de nulmeting vast.

Tot dag 60

Werk aan de belangrijkste templates: Core Web Vitals, toetsenbord, formulieren, content, interne links en applicatiebeveiliging. Introduceer regressiemonitoring.

Tot dag 90

Verbeter minder kritieke templates, standaardiseer het publicatieproces, voeg geautomatiseerde controles toe aan CI en plan terugkerende audits na grote releases.

Complete checklist vóór afsluiting

SEO en indexering

• Crawlers kunnen belangrijke pagina’s en resources ophalen.
• De XML-sitemap is actueel.
• Canonicals, redirects en links zijn consistent.
• Er is geen onbedoelde noindex.
• Belangrijke pagina’s hebben unieke title, H1 en content.
• Interne links leiden naar bedrijfskritieke pagina’s.
• Taalversies gebruiken correcte hreflang.
• Structured data komt overeen met zichtbare content.
• Open Graph-metadata is compleet.

Prestaties

• LCP, INP en CLS voldoen in velddata.
• De LCP-afbeelding heeft juiste afmetingen en prioriteit.
• JavaScript blokkeert geen interacties.
• Afbeeldingen hebben afmetingen en passend formaat.
• Fonts en kritieke resources veroorzaken geen vermijdbare vertraging.
• Resultaten worden na publicatie gemonitord.

Toegankelijkheid

• De site werkt zonder muis.
• Focus is zichtbaar.
• Semantiek en koppenvolgorde zijn logisch.
• Formulieren hebben labels en bruikbare fouten.
• Contrast en reflow voldoen aan WCAG 2.2 AA.
• De interface is met een schermlezer getest.

Beveiliging en privacy

• HTTPS werkt overal en het certificaat wordt gemonitord.
• Sessiecookies hebben veilige attributen.
• Headers zijn afgestemd op de applicatie.
• Bevoegdheden worden server-side gecontroleerd.
• Afhankelijkheden en geheimen worden beheerd.
• Logs en alerts maken reactie mogelijk.
• Back-ups zijn getest.
• Trackingscripts respecteren toestemming.

UX en bedrijfsdoelen

• Het aanbod is begrijpelijk zonder de hele pagina te lezen.
• CTA’s leiden naar de bedoelde actie.
• Formulieren en checkout werken mobiel.
• Foutstatussen helpen de gebruiker herstellen.
• Events en conversies worden correct gemeten.
• Elke verbetering heeft eigenaar, prioriteit en deadline.

POLPROG Websitestatuscontrole gebruiken

Met Websitestatuscontrole kun je een audit vanuit één URL starten en SEO, prestaties, toegankelijkheid, beveiliging en best practices controleren. Tests draaien server-side en registratie is niet nodig.

Aanbevolen proces:

1. Scan de homepage en elk belangrijk template.
2. Noteer kritieke fouten en terugkerende patronen.
3. Bevestig CWV met echte gebruikersdata.
4. Test toetsenbord, formulieren en belangrijke routes handmatig.
5. Controleer afzonderlijk beveiligingsheaders, DNS en SSL en Open Graph.
6. Prioriteer de backlog op impact en risico.
7. Herhaal de test na implementatie en monitor regressies.

Conclusie

De beste website-audit in 2026 eindigt niet met een document met honderd waarschuwingen. Zij eindigt met een korte, geordende actielijst die kritieke problemen van cosmetische details scheidt, eigenaarschap toewijst en het resultaat na implementatie controleerbaar maakt.

Zorg eerst dat de website beschikbaar, indexeerbaar en veilig is. Verbeter daarna de belangrijkste gebruikerspaden, Core Web Vitals en toegankelijkheid. Optimaliseer pas daarna details. Deze volgorde levert meestal meer op dan jagen op een perfecte score in één scanner.