Voordat een AI-gebouwde website live gaat, hoort een website launch checklist te controleren wat een ontwerpvoorbeeld niet laat zien. Elke bewering moet kloppen, en de juridische pagina’s moeten passen bij de gegevens die de site verzamelt. Zoekmachines moeten de site kunnen indexeren, en in de code mag niets vertrouwelijks zichtbaar zijn. Formulieren moeten in uw inbox of CRM aankomen, en uw bedrijf moet de accounts beheren. Mist u een van deze punten, dan kan dat leads, vindbaarheid of de controle over de site kosten. Dat een AI-tool of websitebouwer de pagina’s maakt, bevestigt geen van deze punten. De checklist hieronder is bedoeld voor marketingwebsites en geeft per controle aan wanneer die klaar is. Zo ziet u wat goed staat, wat nog aangepast moet worden en wanneer een tweede review zinvol is.
TL;DR
Een website launch checklist voor een AI-gebouwde site bevestigt dat de site klaar is voordat bezoekers komen. De checklist dekt zes punten: kloppende content, de juiste juridische pagina’s, leesbaarheid voor zoekmachines, niets vertrouwelijks zichtbaar, werking op elk apparaat en accounts op naam van het bedrijf. De AI-tool bouwt de pagina’s, maar kan niet bevestigen dat wat de pagina’s zeggen en doen ook klopt.
- De 30 controles vóór livegang vallen in zes fasen van vijf. De fasen zijn (1) content en AI-hallucinaties opschonen, (2) juridische en privacypagina’s, (3) SEO en vindbaarheid in AI-zoekfuncties, (4) technische basis en security, (5) formulieren, toegankelijkheid en mobiele UX, en (6) eigendom en toegang.
- De European Accessibility Act geldt sinds 28 juni 2025 voor bepaalde private diensten, zoals e-commerce. Een site die online aan consumenten verkoopt, controleert vóór livegang of de wet van toepassing is.
- Een audit in de eerste 30 dagen na livegang loopt op dag 1, dag 7 en dag 30. Die audit controleert indexering, redirects, formulierinzendingen tegenover het CRM, cookietoestemming, chatbotantwoorden en beheerderstoegang.
- Een onafhankelijke review is zinvol als twee of meer risicosignalen gelden. Die signalen zijn persoonsgegevens buiten een contactformulier, een koppeling met een CRM-, boekings- of betaalsysteem, of maatwerkcode. Ook een AI-chatbot, mogelijke toepasselijkheid van de European Accessibility Act of een bouwer die vertrekt tellen mee.
Wat er bij een AI-gebouwde website misgaat vóór de livegang
De risico’s bij de livegang van een AI-gebouwde website zitten in wat een ontwerpvoorbeeld niet laat zien. Denk aan wat de teksten beweren, waar formulierinzendingen terechtkomen, wat zoekmachines te zien krijgen, wat de code blootgeeft en wie de accounts beheert. Het voorbeeld kan er goed uitzien terwijl de site eronder nog niet klaar is.
Vijf fouten hebben direct zakelijke gevolgen. Elke fout begint bij iets wat de tool genereerde of bij een standaardinstelling die niemand aanpaste:
- Verzonnen bewijs: testimonials, logo’s, statistieken of onderscheidingen die de tool maakte om een lay-out te vullen. Na publicatie zijn dat beweringen van uw bedrijf.
- Placeholder-bedrijfsgegevens: een voorbeeldadres of nepnummer waardoor echte aanvragen nergens aankomen.
- Ontbrekende of standaard juridische pagina’s: een privacyverklaring die tools noemt die u niet gebruikt, of helemaal geen privacyverklaring.
- Formulieren die alleen lijken te werken: de bedankmelding verschijnt, maar de inzending komt nooit in de inbox of het CRM aan.
- Accounts op andermans naam: domein, workspace van de websitebouwer of analytics in het persoonlijke account van een freelancer.
Dezelfde risico’s gelden voor elk AI-gebouwd product. Het bredere beeld staat in onze gids over AI-gebouwde producten veilig live brengen. Deze checklist gaat over marketingwebsites. Een webapplicatie met logins en opgeslagen klantgegevens heeft ook release- en rollbackcontroles nodig, die staan in de go-live checklist voor AI-apps. Drie van de vijf fouten kunt u als founder zonder technische hulp controleren: verzonnen bewijs, placeholder-gegevens en formulieren. Elke pagina lezen en elk formulier versturen is genoeg.
De website launch checklist: 30 controles vóór livegang en een audit van 30 dagen
De website launch checklist hieronder verdeelt 30 controles over zes fasen van vijf. Fase 1 tot en met 5 volgen de volgorde waarin bezoekers en zoekmachines de site tegenkomen. Fase 6, eigendom, bepaalt of u later nog iets kunt herstellen. Een korte audit op dag 1, dag 7 en dag 30 bevestigt daarna dat de live site werkt zoals de controles aannamen. Markeer elke controle als goed, aanpassen of niet van toepassing. Begin bij fase 1, want elke latere controle gaat ervan uit dat de content klopt.
1. Content en AI-hallucinaties opschonen
Een AI-hallucinatie op een website is tekst die de tool verzon en die als feit leest. Voorbeelden zijn een testimonial van een klant die niet bestaat, een statistiek zonder bron of een onderscheiding die u nooit kreeg. Elke gepubliceerde bewering is een uitspraak van uw bedrijf aan klanten. Daarom heeft elke bewering een bron nodig die u kunt laten zien.
| Controle | Wanneer is het klaar? |
|---|---|
| Placeholdertekst en afbeeldingen zonder licentie verwijderd | Geen lorem ipsum, ‘Acme’, example.com-adressen of nepnummers meer. Elke afbeelding is van uzelf, heeft een licentie of is gemaakt onder voorwaarden die u hebt gecontroleerd |
| Verzonnen bewijs verwijderd | Elke testimonial, elk klantlogo, elk projectresultaat en elke onderscheiding is echt, en u hebt toestemming om die te publiceren |
| Cijfers en beweringen gecontroleerd | Elke statistiek, prijs, regio en datum is terug te voeren op een bron die u kunt laten zien, en wat geen bron heeft, is verwijderd |
| Bedrijfsgegevens consistent | Statutaire naam, KvK-nummer, adres, telefoonnummer, e-mailadres en openingstijden zijn gelijk op elke pagina, in de footer en in uw Google Bedrijfsprofiel |
| Propositie duidelijk | De H1 op de homepage zegt wat u aanbiedt, voor wie en waarom dat ertoe doet, en elke pagina heeft één call-to-action die sales kan waarmaken |
2. Juridische en privacypagina’s
Juridische pagina’s die klaar zijn voor livegang beschrijven wat de site echt doet, niet wat een sjabloon aanneemt. Een privacyverklaring die tools noemt die u nooit installeerde, of de chatbot van vorige week mist, vertelt bezoekers niet waar hun gegevens heen gaan.
| Controle | Wanneer is het klaar? |
|---|---|
| Privacyverklaring | Beschrijft welke gegevens elk formulier, elke analysetool, chatbot en nieuwsbrief verzamelt, waarom, hoe lang ze bewaard worden en wie ze ontvangt |
| Cookiebanner en cookiebeleid | Niet-noodzakelijke cookies en tags blijven uit tot de bezoeker een keuze maakt, en het beleid noemt elke cookie die in gebruik is |
| Algemene voorwaarden | Gepubliceerd als u online verkoopt of boekingen aanneemt, en gelinkt vanuit de checkout- of boekingsstap |
| Herroepings- en retourbeleid | Gepubliceerd als u online aan consumenten verkoopt, met uitleg over het herroepingsrecht van 14 dagen en de uitzonderingen |
| Toestemming voor marketing in formulieren | Een niet-aangevinkt opt-invakje met duidelijke tekst, los van het contactverzoek zelf |
De controle op het herroepingsrecht volgt een EU-brede regel. Consumenten die online kopen, kunnen in het algemeen binnen 14 dagen zonder opgaaf van reden annuleren. Uitzonderingen zijn onder meer gepersonaliseerde of bederfelijke producten (Your Europe, retourneren en herroepingsrecht). Een site met een checkout voor consumenten heeft dit beleid nodig, terwijl een site die alleen zakelijke aanvragen verzamelt het niet nodig heeft.
Op een AI-gebouwde site verdienen twee gegevensstromen een tweede blik. De eerste zijn sjablonen van de websitebouwer die analytics of embeds laden voordat de bezoeker een keuze maakte. De tweede zijn chatbots of formulieren die inzendingen naar een externe AI-aanbieder sturen. Leg vast waar elke formulierinzending en elk chattranscript heen gaat. Controleer ook of de aanbieder die gegevens mag gebruiken om zijn modellen te trainen. Grondslagen, rechten van bezoekers en de Nederlandse invulling van de AVG (GDPR) staan in onze AVG-checklist voor websites.
3. SEO en vindbaarheid in AI-zoekfuncties
Vindbaar zijn bij de livegang betekent dat zoekmachines de live site kunnen crawlen, elke pagina begrijpen en per pagina één adres kiezen. Volgens Google zijn er geen extra eisen of speciale optimalisaties nodig om in AI Overviews of AI Mode te verschijnen. Er is ook geen speciale schema.org-markup nodig (Google Search Central, AI-functies en uw website). Dezelfde SEO-basis geldt dus voor gewone zoekresultaten en voor AI-zoekfuncties.
| Controle | Wanneer is het klaar? |
|---|---|
| Stagingblokkade verwijderd | Live pagina’s hebben geen noindex-tag, en robots.txt sluit geen pagina’s uit die gevonden moeten worden |
| Titels en beschrijvingen | Een unieke title-tag en metabeschrijving op elke belangrijke pagina, plus één H1 per pagina |
| XML-sitemap | Aangemaakt, met alleen live pagina’s, en ingediend in Google Search Console |
| Eén adres per pagina | http verwijst door naar https, de versies met en zonder www komen uit op één adres, canonical tags wijzen naar dat adres en oude URL’s hebben een 301-redirect naar de nieuwe |
| Basis-structured data | Organization- en WebSite-markup op de homepage. FAQ- of Product-markup alleen waar die content zichtbaar is. Alle markup getest in de Rich Results Test van Google |
De stagingblokkade kan de hele site verbergen. Google haalt een pagina uit de zoekresultaten zodra Googlebot de noindex-regel leest (Google Search Central, indexering blokkeren met noindex). Een noindex-instelling die uit de stagingomgeving is meegekomen, houdt elke pagina waarop die staat buiten de zoekresultaten.
Twee populaire tips voor de livegang kloppen niet helemaal. Canonical tags beschermen niet tegen een ‘straf voor dubbele content’. De documentatie van Google over canonicalisering beschrijft ze als een manier om signalen van dubbele pagina’s samen te voegen en aan te geven welke URL getoond moet worden. Structured data helpt Google een pagina te classificeren en kan die geschikt maken voor rich results. Maar de introductie van Google tot structured data belooft geen rich results, en markup is geen snelle weg naar AI-antwoorden. Instellingen voor Framer- en Webflow-sites staan in SEO voor AI-gebouwde websites.
4. Technische basis en security
De technische basis voor livegang bestaat uit drie delen. De site draait alleen via HTTPS, geeft niets vertrouwelijks bloot in de code en laat alleen uw eigen mensen toe tot de beheeromgeving. Bij een websitebouwer regelt het platform een groot deel van hosting, certificaten en updates, maar beheerderstoegang, maatwerkcode en scripts van derden blijven uw verantwoordelijkheid.
| Controle | Wanneer is het klaar? |
|---|---|
| Overal HTTPS | Elke pagina laadt via https, http verwijst daarnaar door en de browser toont geen waarschuwingen voor gemengde content |
| Geen geheimen in de paginabron | Zoeken in de paginabron en de maatwerkcode op ‘key’, ‘secret’ en ‘token’ levert geen API-sleutel, beheer-URL of databasewachtwoord op |
| Beheerderstoegang afgeschermd | Multifactorauthenticatie (MFA) op de beheeromgeving van de websitebouwer of het CMS, en ongebruikte redacteursaccounts verwijderd |
| Scripts van derden verantwoord | Elk script en elke embed heeft een eigenaar en een doel, en de rest is verwijderd |
| 404-pagina en favicon | Een eigen 404-pagina linkt terug naar de belangrijkste pagina’s, en er staat een favicon in het browsertabblad |
Een sleutel in de paginabron moet u als gelekt beschouwen, omdat iedereen die de pagina opent hem kan kopiëren. Wat u in het eerste uur doet en hoe u sleutels uit de build houdt, staat in gelekte API-keys in AI-producten.
Gebruik voor de volledige securitybasis de checklist websitebeveiliging voor het mkb. Die bevat 28 controles in zeven onderdelen. Drie prioriteiten komen eerst: de HTTPS/TLS-configuratie, MFA op beheerderstoegang en updates van het CMS, plug-ins en afhankelijkheden.
Een tweede blik op gegevensstromen en blootgestelde code?
Deze 30 controles kunt u zelf uitvoeren. Lastig om alleen te beoordelen zijn fase 2 en 4: waar persoonsgegevens heen gaan en wat de code blootgeeft. Verzamelt uw site persoonsgegevens of is hij gekoppeld aan een CRM? Dan geeft een AI-built product review u een onafhankelijk beeld van die onderdelen voordat bezoekers ze vinden.
5. Formulieren, toegankelijkheid en mobiele UX
Een bedankmelding op het scherm bewijst niet dat een aanvraag is aangekomen. Deze fase test de routes waarlangs bezoekers u bereiken. Dat geldt ook voor bezoekers met een toetsenbord, een schermlezer of een klein telefoonscherm.
| Controle | Wanneer is het klaar? |
|---|---|
| Formulier van begin tot eind getest | Elk formulier is verstuurd met geldige, lege en foutieve invoer, en elke geldige inzending staat in de echte inbox of het CRM, met de juiste melding en automatische bevestiging |
| Grenzen voor de chatbot | De chatbot kan geen prijzen, kortingen of levertijden toezeggen, randgevallen zijn getest en buiten de chat is een contactroute naar een medewerker zichtbaar |
| Labels en foutmeldingen | Elk veld heeft een zichtbaar label, niet alleen placeholdertekst, en foutmeldingen zeggen wat er moet worden aangepast en bewaren wat de bezoeker al invulde |
| Alt-tekst, contrast en toetsenbord | Informatieve afbeeldingen hebben een alt-tekst die ze beschrijft, tekst doorstaat een contrastcontrole volgens WCAG 2.1 AA en elke link en knop werkt met het toetsenbord |
| Mobiele lay-out en aanraakdoelen | Getest op minstens twee echte telefoonbreedtes: niet horizontaal scrollen, menu’s sluiten, aanraakdoelen minstens 24 bij 24 CSS-pixels |
De formuliertest vraagt een controle aan de ontvangende kant. Een websitebouwer kan een inzending op het scherm bevestigen terwijl de melding naar een oud adres, de spammap of een verbroken koppeling gaat.
De waarde voor aanraakdoelen komt uit WCAG 2.2-succescriterium 2.5.8 (niveau AA). Dat criterium stelt 24 bij 24 CSS-pixels als minimale grootte voor aanwijsdoelen, met benoemde uitzonderingen. Snelheid hoort hier alleen thuis als laatste controle op de traagste pagina. Wat AI-gebouwde sites vertraagt en wat u eerst aanpakt, staat in website sneller maken.
6. Eigendom en toegang
Eigendom bepaalt of u uw eigen website kunt herstellen tijdens een incident. Staan het domein, de workspace van de websitebouwer of analytics in het persoonlijke account van een freelancer? Dan bent u afhankelijk van iemand buiten het bedrijf. Dat geldt voor het wijzigen van een DNS-record, het terugzetten van een pagina en het verwijderen van een vertrekkende medewerker.
| Controle | Wanneer is het klaar? |
|---|---|
| Domein en DNS | Het domein staat op naam van het bedrijf, en DNS-toegang zit in een bedrijfsaccount |
| Workspace van websitebouwer of hosting | Eigendom van een bedrijfsaccount met minstens twee beheerders |
| Analytics en Search Console | Google Analytics, Search Console en de tagmanager zijn eigendom van een bedrijfsaccount |
| Back-up en versiegeschiedenis | Een export of versiegeschiedenis is bevestigd in de websitebouwer, en iemand weet hoe u die terugzet |
| Schriftelijke overdracht | Eén document beschrijft waar alles staat, wie toegang heeft en hoe u een vertrekkende medewerker verwijdert |
Een site haalt deze fase als het bedrijf de persoon die de site bouwde kan vervangen zonder ergens de toegang te verliezen.
Na de livegang: website audit checklist voor de eerste 30 dagen
Een website audit checklist voor de eerste 30 dagen bevestigt dat de live site werkt zoals de 30 controles vóór livegang aannamen. Voer de audit uit op dag 1, dag 7 en dag 30, omdat problemen met indexering, formulieren en contentwijzigingen pas na enige tijd zichtbaar worden.
| Wanneer | Controle | Waar kijkt u |
|---|---|---|
| Dag 1 | Homepage en belangrijke pagina’s zijn indexeerbaar, zonder achtergebleven noindex | Google Search Console, URL-inspectie |
| Dag 1 | Doorverwezen oude URL’s geven een 301, geen 302 of 404 | Een redirectchecker of de ontwikkelaarstools van de browser |
| Dag 1 | Analytics- en marketingtags gaan pas af na toestemming | Een schoon browservenster met de ontwikkelaarstools open |
| Dag 7 | Geen nieuwe fouten in de pagina-indexering | Google Search Console, rapport Pagina-indexering |
| Dag 7 | Elke formulierinzending heeft precies één record in het CRM | Formulierlog naast de CRM-records |
| Dag 7 | Structured data toont geen fouten | Google Search Console, verbeteringsrapporten |
| Dag 30 | Geen kapotte links na contentwijzigingen | Een linkchecker |
| Dag 30 | Chatbotantwoorden bevatten geen verkeerde toezeggingen | Een steekproef van chattranscripten |
| Dag 30 | Beheerders zijn actueel en vertrokken medewerkers zijn verwijderd | Gebruikerslijst van de websitebouwer of het CMS |
De site is stabiel als op dag 30 drie signalen kloppen. Er zijn geen nieuwe indexeringsfouten, formulierinzendingen komen één op één overeen met het CRM en de toestemmingstest slaagt nog steeds. Snelheid na de livegang bewaakt u in een aparte routine met eigen meetwaarden.
Geldt de European Accessibility Act voor uw website?
De European Accessibility Act geldt voor de website van een private onderneming als die site een dienst levert die onder de wet valt, zoals e-commerce voor consumenten. De wet geldt sinds 28 juni 2025. Voor sommige bestaande diensten loopt een overgangsperiode tot 28 juni 2030. Voor websites van de overheid geldt in plaats daarvan de Webtoegankelijkheidsrichtlijn. Beide gebruiken WCAG 2.1 niveau AA als referentiestandaard.
Verkoopt uw site online aan consumenten? Controleer dan vóór de livegang of de wet van toepassing is, niet pas na een klacht. Presenteert de site alleen uw bedrijf en verzamelt hij aanvragen, dan is de kans kleiner dat de e-commerceverplichtingen gelden. Bevestig dat wel, in plaats van een uitzondering aan te nemen. Reikwijdte, data en conformiteit staan in onze WCAG-toegankelijkheidsgids.
Wanneer zelf controleren genoeg is en wanneer u een review laat doen
Zelf controleren is genoeg voor een eenvoudige brochuresite, terwijl een onafhankelijke review zinvol is als de site gegevens, geld of toezeggingen aan klanten verwerkt. Wie de site bouwde, test de routes waarvan hij verwacht dat ze werken. Een tweede paar ogen vindt de gaten waar een bouwer het minst snel naar kijkt.
| Situatie | Zelf controleren genoeg? | Waarom |
|---|---|---|
| Brochuresite, één contactformulier naar één inbox, alleen analytics met toestemming | Ja | Weinig gegevensstromen en geen maatwerkcode om te controleren |
| Persoonsgegevens verzameld buiten een contactformulier | Review | Privacyverklaring, toestemming en gegevensstromen moeten op elkaar aansluiten |
| Gekoppeld aan een CRM-, boekings- of betaalsysteem | Review | Koppelingen kunnen falen of gegevens lekken zonder zichtbare foutmelding |
| Maatwerkcode of een geëxporteerde React/Next.js-build | Review | Code kan sleutels of beheerroutes blootgeven die een websitebouwer zou afschermen |
| Een AI-chatbot beantwoordt vragen van klanten | Review | Antwoorden worden toezeggingen die uw bedrijf moet nakomen |
| De site valt mogelijk onder de European Accessibility Act | Review | Reikwijdte en conformiteit moeten vóór livegang gecontroleerd zijn |
| De bouwer van de site vertrekt | Review | Eigendom en toegang moeten over zijn voordat de kennis vertrekt |
Gelden twee of meer van deze situaties, laat de site dan vóór de livegang controleren door iemand anders dan de bouwer. Geldt geen enkele, dan zijn de 30 controles en de audit van 30 dagen een passend niveau van controle.
Hoe Sunbytes AI-gebouwde websites vóór livegang beoordeelt
Met een website launch checklist vangt u zichtbare problemen af, maar sommige technische risico’s vragen een nadere blik. Een formulier kan in de test werken terwijl de koppeling onder bepaalde omstandigheden faalt. Maatwerkcode kan gevoelige informatie blootgeven zonder duidelijke waarschuwing. Juist zulke problemen helpt een technische review boven water te krijgen.
De AI-Built Product Review van Sunbytes onderzoekt de afgesproken technische scope: security en data, code en architectuur, kritieke workflows, deployment en onderhoudbaarheid. Software-engineers en securityspecialisten beoordelen het product samen. Zo koppelen zij technische bevindingen aan de mogelijke impact op gebruikers en bedrijfsvoering.
U ontvangt onderbouwde bevindingen en een actieplan met prioriteiten: wat vóór de livegang aandacht nodig heeft en wat kan wachten. U krijgt ook richtlijnen waarmee uw ontwikkelteam direct aan de slag kan. De review staat op zichzelf. Uw team kan de bevindingen oppakken, of Sunbytes brengt het benodigde herstelwerk apart in kaart.
Sunbytes heeft meer dan 15 jaar ervaring in softwareontwikkeling en ruim 300 opgeleverde projecten. De delivery staat onder Nederlandse leiding, met een ISO 27001-gecertificeerd managementsysteem voor informatiebeveiliging.
Twijfelt u of uw AI-gebouwde website technisch klaar is voor de livegang? Neem contact op met Sunbytes over de risico’s die u wilt laten beoordelen voordat echte gebruikers erop vertrouwen.
