Website of webapplicatie opgeleverd: acceptatiechecklist voor het MKB

Een website of webapplicatie accepteer je wanneer de afgesproken gebruikersprocessen aantoonbaar werken, belangrijke risico’s zijn beoordeeld en beheer en herstel zijn overgedragen. Een mooie demo is daarvoor niet genoeg. Gebruik een acceptatiechecklist met per onderdeel een testscenario, verwacht resultaat, bewijs, verantwoordelijke en besluit over livegang.

Voor een MKB-ondernemer is oplevering het moment waarop een bouwproject verandert in een dagelijks bedrijfsproces. Je nieuwe site moet aanvragen afleveren. Je klantportaal moet de juiste gegevens aan de juiste klant tonen. En bij een storing moet duidelijk zijn wie ingrijpt en hoe je verder kunt. Hieronder vind je een praktische acceptatiematrix, een stappenplan en een uitgewerkt fictief voorbeeld.

Redactionele checklist, bijgewerkt op 30 oktober 2026. De voorbeelden en vrijgaveregels zijn voorgestelde werkafspraken, geen juridisch advies, keurmerk of garantie op veiligheid. Wettelijke verplichtingen, technische richtlijnen en contractuele afspraken zijn verschillende dingen.

Wat is het verschil tussen oplevering, acceptatie en livegang?

Oplevering betekent hier dat het bureau de afgesproken oplossing voor beoordeling aanbiedt. Acceptatie is jouw vastgelegde besluit dat die oplossing aan de overeengekomen criteria voldoet. Livegang is de ingebruikname door echte bezoekers of klanten. De precieze juridische betekenis en gevolgen hangen af van het contract: controleer dus welke procedure, termijnen en voorwaarden je hebt afgesproken.

Deze momenten hoeven niet samen te vallen. Je kunt een testversie eerst beoordelen, fouten laten herstellen en pas daarna de productieversie vrijgeven. Andersom kan een gefaseerde livegang onderdeel van je afspraken zijn. Voorkom dat een demo automatisch als definitieve goedkeuring wordt behandeld terwijl beveiliging, overdracht of migratie nog niet is gecontroleerd.

Nog aan het begin van je project? Lees eerst de beslisboom voor een website of webapplicatie en de MKB-scorekaart voor het kiezen van een bureau. Daar bepaal je wat je nodig hebt en welk bewijs je vooraf vraagt.

Stap 1: spreek af wat ‘klaar’ betekent

Maak vóór de acceptatietest één lijst met afgesproken functies, content, koppelingen, ondersteunde apparaten en expliciete uitsluitingen. Koppel elk belangrijk bedrijfsdoel aan een concrete gebruikershandeling. ‘Het formulier werkt’ is te vaag. ‘Een bezoeker verstuurt een aanvraag en de verantwoordelijke medewerker ziet die met de juiste gegevens terug’ is toetsbaar.

• Scope: welke pagina’s, rollen en processen horen bij deze oplevering?
• Testomgeving: welke versie beoordeel je en waarin verschilt die van productie?
• Testgegevens: welke fictieve accounts en records gebruik je, zonder onnodige klantgegevens te kopiëren?
• Bewijs: wie legt testresultaten, foutmeldingen en herstelcontroles vast?
• Beslisser: wie mag accepteren, uitstellen of een uitzondering goedkeuren?
• Hercontrole: welke tests voer je opnieuw uit na een wijziging?

Een ontwerpscherm of screenshot is bruikbaar bewijs voor opmaak, maar niet voor een e-mailbezorging, gegevensscheiding of back-upherstel. Kies bewijs dat past bij het risico. Reserveer ook interne testtijd in je begroting voor website- of webapplicatiebouw.

De acceptatiechecklist: elf onderdelen vóór livegang

Onderdeel	Wat controleer je?	Welk bewijs vraag je?
1. Scope en content	Zijn afgesproken pagina’s, functies en koppelingen aanwezig? Kloppen teksten, contactgegevens en downloads?	Eisenlijst met resultaat per punt en gemotiveerde uitsluitingen.
2. Kernprocessen	Werken aanvragen, bestellen, uploaden en andere taken van begin tot eind, ook bij fouten?	Uitgevoerde scenario’s met invoer en teruggelezen resultaat.
3. Rollen en rechten	Ziet iedere klant alleen bevoegde gegevens, ook via directe links en verzoeken buiten de interface?	Testmatrix per rol, klant en gegevenssoort.
4. Beveiliging	Zijn relevante risico’s onderzocht en bevindingen hersteld of expliciet beoordeeld?	Rapport met testomvang, bevindingen en hertests.
5. Privacy	Zijn noodzakelijke gegevens, grondslagen, bewaartermijnen en leveranciersrollen vastgesteld?	Gegevensoverzicht en toepasselijke informatie en afspraken.
6. Toegankelijkheid	Zijn complete processen bruikbaar met toetsenbord en ondersteunende technologie?	Handmatig onderzoek naast automatische controles.
7. Prestaties	Zijn belangrijke pagina’s en interacties onder afgesproken omstandigheden getest?	Herhaalbare testmetingen en plan voor praktijkmetingen.
8. SEO en migratie	Kloppen openbare URL’s, redirects, interne links, canonicals en indexeringsinstellingen?	Crawlrapport, URL-mapping en sitemapcontrole.
9. Herstel en monitoring	Is een back-up teruggezet en komt een storingsmelding bij de juiste persoon terecht?	Hersteltest en gecontroleerde meldingsprocedure.
10. Overdracht	Heb je afgesproken toegang tot domein, beheer, hosting, code en documentatie?	Overdrachtslijst met gecontroleerde toegang.
11. Vrijgave en nazorg	Wie beslist over livegang, restpunten, terugdraaien en herstel?	Acceptatieverslag met eigenaar en termijn per bevinding.

Stap 2: test echte taken, inclusief wat mis kan gaan

Begin bij de taken waarvan je bedrijf afhankelijk is. Bij een bedrijfswebsite zijn dat bijvoorbeeld een offerte aanvragen, bellen op mobiel en een document downloaden. Bij een webapplicatie zijn het inloggen, gegevens wijzigen, een betaling of aanvraag verwerken en het resultaat later terugvinden.

Voer een taak helemaal uit. Een bedankmelding op de website bewijst niet dat de aanvraag in je beheeromgeving aankomt. Lees het resultaat terug op de plek waar de medewerker er daadwerkelijk mee werkt. Controleer ook of een e-mail met juiste inhoud wordt ontvangen wanneer die onderdeel van de afspraak is.

• Wat gebeurt er als een verplicht veld ontbreekt?
• Blijft eerder ingevulde informatie behouden bij een herstelbare fout?
• Wat gebeurt er bij dubbel klikken op verzenden?
• Hoe handelt het systeem een tijdelijke storing in een koppeling af?
• Wordt een niet-toegestaan bestand op de server geweigerd?
• Kan een medewerker een mislukte verwerking herkennen en herstellen?

Leg per scenario de verwachte uitkomst vast. Test niet alleen als beheerder: die heeft vaak meer rechten dan een gewone gebruiker en kan daardoor fouten in klantprocessen missen.

Stap 3: laat rechten, beveiliging en privacy controleren

Een verborgen knop is geen toegangsbeveiliging. Laat het bureau aantonen dat rechten ook worden gecontroleerd wanneer iemand een directe URL opent, een recordnummer verandert of een verzoek rechtstreeks naar de applicatie stuurt. Gebruik gecontroleerde testaccounts van verschillende fictieve klanten. Deze tests horen bij de afgesproken testomgeving en mogen geen echte klantgegevens blootleggen.

Maak beveiliging concreet met passende eisen uit de OWASP Application Security Verification Standard. Leg de gebruikte versie, geselecteerde eisen, testomvang en resultaten vast. Denk aan sessies, toegangscontrole, verwerking van invoer en bestandsuploads. Een logo, verwijzing naar OWASP of geslaagde scanner bewijst niet dat de hele applicatie veilig is.

Beoordeel privacy afzonderlijk. Welke persoonsgegevens worden verwerkt, waarom zijn ze nodig en op welke grondslag? Welke partijen ontvangen ze en hoe lang worden ze bewaard? Als een leverancier als verwerker optreedt, horen daar passende afspraken bij. De AVG vraagt onder meer dataminimalisatie en risicogerichte beveiliging; alleen een privacyverklaring publiceren is niet voldoende. Toestemming is bovendien niet de enige mogelijke grondslag.

Gebruik de privacycheck voor CRM-data als aanvullende uitleg over gegevensstromen. Beoordeel cookies en vergelijkbare technieken apart: niet iedere website heeft dezelfde toestemmingseisen of automatisch een cookiebanner nodig.

Stap 4: controleer toegankelijkheid en prestaties met de juiste methode

Spreek bijvoorbeeld WCAG 2.2 niveau AA af als kwaliteitsdoel, met een passende onderzoeksomvang. Een automatische test helpt fouten vinden, maar bewijst geen volledige conformiteit. Controleer complete processen: de aanvraag moet ook na het eerste scherm met toetsenbord en ondersteunende technologie bruikbaar blijven. Let op zichtbare focus, veldlabels, foutmeldingen, contrast en begrijpelijke bediening.

Wettelijke toegankelijkheidseisen gelden niet zonder meer op dezelfde manier voor ieder MKB-bedrijf. Sinds 28 juni 2025 gelden voorschriften voor bepaalde producten en diensten, waaronder webwinkels. Beoordeel de toepasselijkheid en eventuele uitzonderingen voor jouw situatie. Een afgesproken WCAG-versie is niet automatisch de exacte wettelijke norm voor iedere website.

Voor prestaties zijn de aanbevolen Core Web Vitals-doelen van Google: LCP maximaal 2,5 seconden, INP maximaal 200 milliseconden en CLS maximaal 0,1. De beoordeling van echte gebruikerservaring gebeurt op het 75e percentiel, apart voor mobiel en desktop. Dit zijn prestatierichtlijnen, geen wettelijke eisen.

Een nieuwe site heeft soms nog onvoldoende praktijkgegevens. Leg dan vast welke herhaalbare labtests je vóór livegang gebruikt en hoe je daarna echte gebruikersmetingen volgt. Een hoge Lighthouse-score is geen volledige acceptatietest. Een snelle homepage zegt ook weinig over een zwaar klantdashboard.

Stap 5: bescherm vindbaarheid én privégegevens

Controleer openbare pagina’s op juiste titels, beschrijvingen, canonicals, interne links en sitemapvermelding. Verwijder onbedoelde indexeringsblokkades van de productieversie. Bij veranderde URL’s maak je een mapping naar inhoudelijk passende nieuwe bestemmingen en permanente server-side redirects. Controleer de complete keten, niet alleen of er ergens een redirect bestaat.

Google adviseert bij een verhuizing met URL-wijzigingen redirects doorgaans minstens één jaar te behouden. Monitor de overgang met Search Console. Een correcte migratie verkleint risico’s, maar garandeert geen gelijkblijvende posities of onmiddellijke indexering. Lees ook over WordPress migreren naar Lovable en de SEO-audit met AI.

Privégegevens bescherm je met authenticatie en autorisatie, niet met robots.txt of noindex. Een portaal kan afgeschermde klantonderdelen hebben én openbare hulppagina’s die wel vindbaar moeten zijn. Beoordeel die twee groepen apart. Een bestand dat zonder controle via een openbare link bereikbaar is, wordt niet veilig doordat je het uit de sitemap laat.

Fictief voorbeeld: een klantportaal voor een onderhoudsbedrijf

Voorbeeld Onderhoud is een verzonnen bedrijf. Onderstaande scenario’s en beslissingen zijn illustratief, geen klantcase. Het bedrijf laat een portaal bouwen waarin klanten storingen melden, foto’s uploaden en werkbonnen bekijken. Medewerkers verwerken meldingen; beheerders beheren accounts.

Scenario	Verwacht resultaat	Acceptatiebesluit bij afwijking
Klant A verandert het werkbonnummer naar een record van klant B.	Geen toegang tot gegevens of bijlagen van klant B, ook niet via een direct verzoek.	Ongeoorloofde toegang blokkeert livegang; herstel en hertest zijn nodig.
Een klant verstuurt een melding zonder verplicht veld.	Een begrijpelijke foutmelding bij het juiste veld; overige invoer blijft staan.	Impact op het kernproces bepalen en aantoonbaar herstellen.
De klant doorloopt de melding alleen met het toetsenbord.	Alle bediening is bereikbaar, focus is zichtbaar en er is geen toetsenbordval.	Beoordelen tegen afgesproken toegankelijkheidscriteria.
Een klant uploadt een niet-toegestaan bestand.	De server weigert het bestand volgens de afgesproken uploadregels.	Beveiligingsrisico beoordelen vóór vrijgave.
Een account wordt ingetrokken.	Toegang wordt geblokkeerd; bestaande sessies volgen het vastgelegde intrekkingsbeleid.	Afwijking herstellen en verschillende toegangspaden hertesten.
Een back-up wordt teruggezet in een veilige herstelomgeving.	De afgesproken gegevens zijn terug en het meldproces werkt weer binnen de overeengekomen hersteltijd.	Zonder bewezen herstel geen akkoord op dit onderdeel.

Tijdens de eerste ronde blijkt klant A een bijlage van klant B te kunnen downloaden. De opdrachtgever geeft daarom geen vrijgave. Het bureau herstelt de controle op bestandstoegang en test vervolgens alle vergelijkbare downloads, niet alleen die ene bijlage. Daarna herhalen klant en bureau de relevante scenario’s. Een kleine opmaakafwijking kan eventueel op de restpuntenlijst, mits die geen wezenlijk gebruiks- of toegankelijkheidsprobleem veroorzaakt.

Stap 6: bewijs herstel en rond de overdracht af

‘Er zijn back-ups’ is geen herstelbewijs. Vraag wanneer voor het laatst een back-up is teruggezet, welke onderdelen daarbij zijn gecontroleerd en hoe lang dat duurde. Maak onderscheid tussen het afgesproken maximale gegevensverlies en de afgesproken tijd om weer te kunnen werken. Kies die doelen op basis van je bedrijfsrisico, niet op basis van een willekeurig standaardgetal.

• Wie ontvangt storingsmeldingen en wie vervangt die persoon bij afwezigheid?
• Wie beheert domein, hosting, publicatie en noodzakelijke licenties?
• Welke toegang en rechten krijg je voor code en documentatie volgens het contract?
• Zijn tijdelijke accounts verwijderd en beheeraccounts passend beveiligd?
• Wie kan een vorige versie terugzetten, en wat gebeurt er met wijzigingen in gegevens?
• Zijn periodiek onderhoud, ondersteuning en verbruikskosten vastgelegd?

Test je toegang daadwerkelijk. Een lijst accountnamen zonder werkende toegang is geen complete overdracht. Ook bij bouwen met AI en vibe coding blijven kwaliteitscontrole, rechten en beheer nodig; snelheid van bouwen vervangt acceptatie niet.

Stap 7: leg het acceptatiebesluit en de nazorg vast

Een bruikbare, vooraf af te spreken vrijgaveregel is: niet live met onopgeloste fouten die kernprocessen blokkeren of ongeoorloofde toegang tot persoonsgegevens mogelijk maken. Dit is een aanbevolen werkafspraak, geen universele wettelijke standaard. Laat de contractuele acceptatieprocedure en je eigen risicobeoordeling leidend zijn.

Gebruik voor elke bevinding een status: akkoord, afgekeurd of niet van toepassing met toelichting. Noteer bij restpunten de impact, eigenaar, hersteltermijn en tijdelijke maatregel. Zet in het acceptatieverslag ook de geteste versie, bewijsstukken, vrijgegeven scope en beslisser. Een niet-getest onderdeel mag niet ongemerkt als goedgekeurd worden beschouwd.

Controleer direct na livegang nogmaals de belangrijkste processen, productie-instellingen, meldingen en openbare URL’s. Sommige problemen ontstaan pas door echte verzenddiensten, domeininstellingen of productiegegevens. Spreek af wie deze nacontrole uitvoert en wanneer je de resterende punten opnieuw bespreekt.

Wat vraag je vandaag aan je bureau?

Vraag niet alleen: ‘Is de website klaar?’ Vraag: ‘Kunnen we samen de belangrijkste taken doorlopen, de testresultaten bekijken en vastleggen wat livegang nog blokkeert?’ Begin met je drie belangrijkste bedrijfsprocessen. Voeg rechtencontrole, herstel en overdracht toe. Daarmee maak je oplevering een controleerbaar besluit in plaats van een indruk tijdens een presentatie.

AI Marketing Bureau helpt bij het afbakenen, bouwen en controleren van websites en webapplicaties. Wil je je bouwopdracht of acceptatiecriteria bespreken? Bekijk onze diensten of laat hieronder weten welke oplossing je wilt laten beoordelen.

Veelgestelde vragen over website- en webapplicatie-acceptatie

Wanneer kan ik een website of webapplicatie accepteren?

Wanneer de afgesproken criteria aantoonbaar zijn gecontroleerd en je volgens de overeengekomen procedure een besluit kunt nemen. Leg de geteste versie, resultaten, uitzonderingen en beheerafspraken vast. Een werkende demo alleen is onvoldoende bewijs voor alle processen.

Moet alles foutloos zijn voordat de website live gaat?

Niet iedere kleine afwijking hoeft livegang te blokkeren. Spreek vooraf af welke risico’s onaanvaardbaar zijn. Fouten die kernprocessen blokkeren of ongeoorloofde toegang tot persoonsgegevens mogelijk maken, zijn sterke redenen om vrijgave uit te stellen. Beheersbare restpunten krijgen een eigenaar en hersteltermijn.

Is een Lighthouse-score van 100 voldoende voor acceptatie?

Nee. Lighthouse helpt bepaalde technische problemen vinden, maar bewijst niet dat aanvragen aankomen, klantgegevens gescheiden blijven, complete processen toegankelijk zijn of back-ups kunnen worden hersteld. Combineer passende automatische tests met handmatige en functionele controles.

Moet iedere MKB-website voldoen aan WCAG 2.2 AA?

Die algemene conclusie kun je niet trekken. Wettelijke toegankelijkheidsvoorschriften hangen af van de aangeboden producten en diensten en eventuele uitzonderingen. Je kunt WCAG 2.2 AA wel expliciet afspreken als kwaliteitsdoel. Laat de toepasselijke wettelijke eisen voor jouw situatie afzonderlijk beoordelen.

Hoe test ik of klanten elkaars gegevens kunnen zien?

Laat in een gecontroleerde testomgeving accounts van verschillende fictieve klanten gebruiken. Controleer niet alleen schermen, maar ook directe links, gewijzigde recordnummers en bestandsverzoeken. Het bureau moet aantonen dat de toegangscontrole ook buiten de zichtbare interface werkt.

Waarom is een back-up zonder hersteltest onvoldoende?

Een opgeslagen kopie bewijst niet dat de applicatie met de juiste gegevens weer kan werken. Een hersteltest laat zien welke onderdelen terugkomen, hoe lang dat duurt en welke stappen of afhankelijkheden nog ontbreken.

Wat moet ik na livegang nog controleren?

Herhaal de belangrijkste gebruikersprocessen in productie en controleer meldingen, rechten, openbare URL’s, redirects en indexeringsinstellingen. Volg storingen en praktijkmetingen en werk de restpuntenlijst af volgens de afgesproken nazorgprocedure.

Bronnen en afbakening

Onderstaande primaire bronnen onderbouwen de technische richtlijnen en privacy- en toegankelijkheidscontext. De acceptatiematrix en het fictieve voorbeeld zijn onze redactionele vertaling naar een MKB-bouwproject.

• W3C: WCAG 2.2-conformiteit — volledige processen, niveaus en menselijke beoordeling.
• Rijksoverheid: toegankelijkheid van producten en diensten — toepasselijkheid van toegankelijkheidsvoorschriften.
• OWASP ASVS — toetsbare beveiligingseisen voor webapplicaties.
• Google Search Central: verhuizing met URL-wijzigingen — redirects, migratie en monitoring.
• EUR-Lex: Algemene verordening gegevensbescherming — onder meer artikelen 5, 6, 25, 28 en 32.
• Google web.dev: Core Web Vitals — prestatiedoelen en meting bij echte gebruikers.