Vibe coded, daarna gecontroleerd

7 problemen die we regelmatig zien bij AI-gebouwde websites

Het opvallendste probleem bij AI-gebouwde websites is niet dat ze eenvoudig zijn. Vaak is het omgekeerd: sommige delen zijn verrassend geavanceerd, terwijl basiscontroles rond SEO, beveiliging en beheer achterblijven. Dit zijn zeven punten die we bij een technische review daarom expliciet nalopen.

1. Metadata die elkaar tegenspreekt

Een AI-tool kan voor elke pagina netjes een title, description, Open Graph-tag en canonical genereren. Het probleem ontstaat wanneer die onderdelen niet dezelfde URL, paginanaam of inhoud beschrijven.

Voor een bezoeker ziet de pagina er normaal uit. Voor zoekmachines kunnen de signalen tegenstrijdig zijn. Controleer daarom niet alleen of metadata bestaat, maar of title, H1, canonical, sitemap en interne links hetzelfde verhaal vertellen.

2. Mooie routes, maar ook veel 404’s

Tijdens snelle iteraties veranderen slugs, navigatielinks en testpagina’s vaak. Oude paden blijven daarna soms in interne links, sitemaps, externe verwijzingen of crawlerhistoriek rondzwerven.

Een gezonde oplevering bevat daarom ook een URL-controle: welke routes bestaan, welke zijn verdwenen, welke verdienen een redirect en welke 404’s zijn gewoon normale internetruis?

3. E-mail die makkelijker te spoofen is dan nodig

Een website kan technisch uitstekend werken terwijl het domein nauwelijks is voorbereid op zakelijke e-mail. SPF, DKIM en DMARC horen niet bij het visuele ontwerp en worden daardoor gemakkelijk vergeten.

Dat maakt niet automatisch elke e-mailfraude mogelijk, maar een onvoldoende ingestelde domeinauthenticatie geeft ontvangers minder sterke signalen om legitieme en vervalste mail van elkaar te onderscheiden. Website, domein en e-mail moeten daarom samen bekeken worden.

4. Interne gedachtegang die publiek wordt meegestuurd

AI-ontwikkeling laat soms interne labels, tijdelijke tags, TODO’s, debugteksten of beschrijvende instructies achter in client-side bestanden. Alles wat de server naar de browser stuurt kan in principe door een bezoeker worden geïnspecteerd.

Dat betekent niet dat alle broncode van de server publiek is. Het betekent wel dat ontwikkelaars geen vertrouwelijke informatie, secrets of interne instructies in browsercode mogen behandelen alsof ze verborgen zijn.

5. Configuratie of secrets op de verkeerde plek

Frontend-frameworks maken sommige configuratie bewust publiek. Een environment variable die in client-side JavaScript wordt gebundeld, is geen geheim meer zodra de pagina wordt geladen.

API-sleutels, beheertokens en andere gevoelige waarden horen server-side te blijven. Na een snelle AI-build is het daarom verstandig expliciet te controleren welke configuratie uiteindelijk in de browserbundle terechtkomt.

6. Een formulier met veel UX, maar weinig misbruikbescherming

AI kan in enkele minuten een mooi intake- of contactformulier bouwen. De achterkant verdient evenveel aandacht: server-side validatie, limieten tegen geautomatiseerd misbruik, veilige foutmeldingen en alleen de gegevens verzamelen die werkelijk nodig zijn.

Een formulier dat alleen in de browser valideert kan nog steeds rechtstreeks tegen de server worden aangeroepen. Frontend-validatie helpt de gebruiker; server-side validatie beschermt de toepassing.

7. Niemand kijkt meer nadat de demo werkt

De laatste valkuil is operationeel. De site werkt bij oplevering, maar niemand volgt dependency-updates, certificaten, Search Console, foutpaden, performance of back-ups op.

Dat is precies waar een beheerde website verschilt van een eenmalige AI-demo. De interessante vraag is niet alleen of de site vandaag werkt, maar hoe snel iemand ziet dat er morgen iets verandert.

De conclusie is niet “AI is slecht”

Wij gebruiken zelf automatisering en AI omdat het ontwikkeling sneller en goedkoper maakt. De juiste conclusie is dat bouwsnelheid en kwaliteitscontrole twee aparte processen zijn.

Een sterke workflow gebruikt AI om sneller te bouwen en gebruikt daarna vaste controles om te beoordelen wat er werkelijk gepubliceerd is. De computer mag veel genereren. De kwaliteitslat moet nog altijd bewust worden beheerd.

Praktische checklist

  • ✓ Titles, H1, canonical en sitemap zijn consistent
  • ✓ Oude routes en echte 404-problemen zijn beoordeeld
  • ✓ SPF, DKIM en DMARC zijn bekeken wanneer het domein mail gebruikt
  • ✓ Geen secrets of interne gevoelige informatie staat client-side
  • ✓ Formulieren valideren ook server-side
  • ✓ Publieke code bevat geen onnodige debug- of ontwikkelteksten
  • ✓ Monitoring en onderhoud hebben een duidelijke eigenaar

Wilt u vooral dat iemand dit voor u regelt?

Vertel kort wat uw zaak doet. U krijgt eerst een voorstel; een aanvraag is nog geen bestelling.

Start mijn aanvraag →