Vibe coding

## Wat is vibe coding? **Vibe coding** is het praktijkgericht uitbrengen van apps door **features te beschrijven aan AI-codehulpmiddelen** zoals Cursor of Claude Code, en die tools vervolgens (een groot deel van) de implementatie te laten genereren. In de praktijk betekent dit dat een oprichter, marketeer of productbouwer prompts schrijft zoals “bouw een pricing-pagina”, “maak een onboarding-flow” of “koppel dit formulier aan een database”, waarna de AI code, structuur en vaak ook een deel van het design oplevert. Die definitie is belangrijk, omdat vibe coding niet simpelweg “AI gebruiken in development” is. De kern is dat **natuurlijke taal het grootste deel van het bouwproces aanstuurt**. De mens stelt nog steeds doelen, beoordeelt outputs, test gedrag en beslist wat er live gaat, maar de AI doet een groot deel van het programmeerwerk. Ik heb hetzelfde patroon herhaaldelijk gezien bij early-stage builds: de eerste versie die door AI is gegenereerd, ziet er in de browser vaak al “af” uit lang voordat het daadwerkelijk klaar is voor zoekverkeer. Dat is de praktische kloof die deze term probeert te benoemen voor oprichters en SEO-teams. De snelheid is echt. De verborgen opschoonwerkzaamheden zijn ook echt. Voor SEO-teams en teams die groei aansturen vanuit de oprichter is de aantrekkingskracht duidelijk: je kunt MVP’s, landingspagina’s, interne tools en lichte applicaties veel sneller opzetten dan met een traditioneel engineering-workflow. De trade-off is minder absoluut dan sommige samenvattingen doen vermoeden. **Sommige AI-gegenereerde projecten zijn meteen zoekvriendelijk; andere niet.** De uitkomst hangt sterk af van het gekozen framework, de prompt en of iemand de gerenderde output controleert vóór de launch. Daarom moet vibe coding in een SEO-context het best worden begrepen als **snelle AI-ondersteunde app-ontwikkeling plus expliciete SEO-hardening**. Als je een JavaScript-zware app zonder server-side rendering, indexeerbare metadata en goed crawlbare discoverypaden live zet, kan het zijn dat zoekmachines je content zwakker of trager begrijpen. Google kan JavaScript renderen, maar in de eigen documentatie van Google worden rendering, links en metadata nog steeds benadrukt als implementatiepunten—niet als details om te negeren. ## Waarom vibe coding populair is Vibe coding is gegroeid omdat het de praktische drempel verlaagt tussen een idee en een werkend product. Vaak kan een niet-ingenieur al snel een prototype bereiken door uitkomsten te beschrijven in plaats van elke functie handmatig te schrijven. Een ervaren engineer kan het gebruiken om repeterende taken te versnellen, zoals scaffolding, tests, UI-generatie en integratiewerk. Veelvoorkomende use cases zijn: - startup MVP’s - interne SEO-tools - dashboards voor content-werkstromen - leadgeneratie-microsites - light-weight klantportalen - experimentpagina’s voor vraagvalidatie In de praktijk is het grootste voordeel meestal niet dat AI altijd betere code schrijft. Het is dat het **de tijd tussen plannen en testen comprimeert**. Teams kunnen aanbiedingen, messaging en workflows eerder valideren. Dat is een sterk operationeel voordeel, zelfs als de gegenereerde code nog steeds opgeschoond moet worden. Vanuit het perspectief van de oprichter is dit waarom vibe coding zo overtuigend voelt: het verandert “we zouden dit ooit moeten testen” in “we kunnen deze week iets live zetten.” In mijn ervaring is die tijdscompressie het echte product—not de nieuwigheid van het prompten zelf. ## Waar SEO-problemen ontstaan in vibe-coded apps Het grootste SEO-issue is dat veel AI-gegenereerde projecten **uiteindelijk op een client-rendered SPA kunnen lijken**, vooral wanneer de prompt focust op snelheid, interactiviteit of een snelle front-end demo. Dat betekent niet dat elke AI-tool automatisch altijd een SPA oplevert, en het betekent ook niet dat elke SPA automatisch onzichtbaar is voor zoekmachines. Het betekent dat de standaardoutput gecontroleerd verdient te worden. Een client-rendered SPA laadt meestal eerst een JavaScript-shell en injecteert vervolgens paginacontent nadat scripts zijn uitgevoerd. Moderne zoekmachines, vooral Google, kunnen JavaScript renderen, maar Google legt ook uit dat JavaScript-rendering gepaard kan gaan met extra verwerking. Het praktische risico is daarom meestal **minder betrouwbaarheid of een tragere interpretatie**, niet “zoekmachines kunnen het nooit lezen.” Het terugkerende, echte faalpatroon in de praktijk is simpel: een oprichter opent de app, klikt wat rond, ziet verzorgde schermen en gaat ervan uit dat de technische basis klopt. Daarna checkt iemand de ruwe HTML en ziet een root-div, generieke metadata en routewijzigingen die voor gebruikers prima werken, maar zwakker zijn voor discoverability. Dit is geen exclusief AI-probleem, maar AI kan het wel makkelijker maken om dat probleem sneller te shippen. Typische problemen zijn: ### 1. Lege initiële HTML Als de paginabroncode weinig meer bevat dan een root-div en script-tags, kunnen crawlers de belangrijkste content niet meteen zien. Dit kan fragieler zijn bij nieuwe pagina’s, zwakkere sites of pagina’s die afhangen van client-side fetches. ### 2. Ontbrekende of dubbele title-tags en meta descriptions AI-gebouwde SPA’s missen soms metadata die specifiek is voor routes. Als elke route dezelfde generieke title krijgt, krijgen zoekmachines zwakkere paginasignalen en zien gebruikers mogelijk slechte snippets. ### 3. Geen server-side rendering of prerendering Als content pas verschijnt nadat JavaScript is uitgevoerd, kunnen sommige crawlers en social scrapers het missen. SSR, static generation of prerendering zorgt meestal voor een betrouwbaardere, content-first respons voor bots en gebruikers. ### 4. Gebroken interne linking Sommige gegenereerde apps gebruiken JavaScript-events in plaats van crawlable anchor-links. Als bots paden niet makkelijk kunnen volgen, kan discoverability daaronder lijden. ### 5. Ontbrekende XML-sitemaps Bij nieuw gegenereerde sites met veel dynamische routes kan een sitemap helpen om URLs betrouwbaarder te laten vinden door zoekmachines. ### 6. Zwakke canonical-afhandeling AI-tools kunnen duplicaten in routes, varianten via query-parameters of preview-URL’s genereren zonder correcte canonical-tags. ## Zo maak je vibe coding SEO-veilig Vibe coding is niet anti-SEO. Je hebt alleen een scherpere definitie van “done” nodig. Voor apps en websites die op zoekverkeer gericht zijn, voeg je deze eisen toe in de prompt, in de architectuur en in de QA-checklist. ### Gebruik SSR, SSG of prerendering Voor content die moet ranken, kies je bij voorkeur: - **SSR** voor dynamische pagina’s die actuele data nodig hebben - **SSG** voor stabiele marketingpagina’s en documentatie - **prerendering** voor JavaScript-routes die anders “dunne” HTML zouden opleveren Frameworks zoals Next.js, Nuxt en vergelijkbare server-capable stacks zijn vaak een veiligere start dan pure client-side setups. “Veiliger” is hier het juiste woord: ze garanderen niet meteen sterke SEO op zichzelf, maar ze maken goede output makkelijker te produceren. ### Genereer unieke metadata per URL Elke belangrijke pagina moet zijn eigen: - title tag - meta description - canonical URL - social tags zoals Open Graph (waar relevant) hebben. Als de site templates gebruikt, laat de AI dan metadata-regels genereren die gekoppeld zijn aan route-level content. ### Publiceer XML-sitemaps en houd ze actueel Een vibe-coded site zou automatisch XML-sitemaps moeten maken en bijwerken wanneer routes veranderen. Dit is vooral nuttig voor snel bewegende MVP’s waarbij pagina’s snel worden toegevoegd. ### Houd links crawlbaar Gebruik waar mogelijk standaard HTML-anchorlinks voor navigatie. Vermijd om voor belangrijke discoverability-paden volledig te leunen op button-clicks en JavaScript-handlers. ### Voeg structured data toe waar passend Als de pagina duidelijk een artikel, product, softwareapplicatie, organisatie, FAQ of een breadcrumb trail voorstelt, kan structured data helpen om de pagina consistenter te laten interpreteren door zoekmachines. Schema.org is de gangbare woordenlijst. ### Test zowel gerenderde als ruwe HTML Bouw niet alleen op de browser. Vergelijk: - wat gebruikers zien - wat “view source” toont - wat inspection tools voor zoekdoeleinden rapporteren Als de broncode grotendeels leeg is maar de browser “af” oogt, is dat een signaal om je rendering-strategie te controleren. Het is geen bewijs dat de pagina faalt, maar wel een teken om te verifiëren in plaats van aan te nemen. Een praktische gewoonte die ik aanraad is om “view source” te behandelen als onderdeel van de launch-review, niet als een taak voor alleen specialisten. Je hoeft niet elke regel code te lezen. Je moet alleen bevestigen dat belangrijke pagina-content en metadata in een logische vorm aanwezig zijn. ## Een praktische vibe coding-workflow voor oprichters en SEO-teams Een bruikbare workflow is: 1. **Definieer het doel in plain English.** Voorbeeld: “Bouw een landingspagina en app-dashboard voor een SEO content-audit tool.” 2. **Specificeer SEO-eisen in dezelfde prompt.** Voorbeeld: “Gebruik SSR, route-level metadata, canonical tags, XML sitemap, robots.txt en semantische HTML.” 3. **Kies een SEO-capabel framework.** Vraag de AI om een framework te gebruiken dat server rendering of static generation ondersteunt. 4. **Review gegenereerde code op architectuur, niet alleen op uiterlijk.** Snelle demo’s kunnen zwakke rendering verbergen. 5. **Valideer output met zoekdocumentatie en inspection tools.** Google Search Central-documentatie is voor veel implementatievragen een belangrijk startpunt. 6. **Ship, monitor en iterereer.** Let op crawlbaarheid, indexering, snippets en paginagedrag. Deze workflow behoudt het snelheidsvoordeel van vibe coding, terwijl de veelvoorkomende faalmodus “lijkt goed voor mensen, onduidelijk voor zoekmachines” wordt verminderd. ## Wanneer vibe coding het beste werkt Vibe coding is vooral effectief wanneer: - de scope van het product smal is - het team snel een prototype nodig heeft - de pagina’s op herhaalbare templates zijn gebaseerd - de bouwer prompts en outputs kritisch kan beoordelen - SEO-eisen vroeg bekend zijn Het is minder betrouwbaar wanneer teams aannemen dat AI-gegenereerde code standaard productie-ready is. Complexe authenticatie, security, performance en grootschalige information architecture vragen nog steeds om ervaren review. In mijn ogen is het sterkste use case niet het vervangen van engineering. Het is het verkorten van de route naar een testbare versie, terwijl een ervaren reviewer in de loop blijft voor alles wat publiek is, schaalbaar moet zijn of afhankelijk is van zoekverkeer. ## Vibe coding versus traditionele development Traditionele development start meestal met architectuur, specificaties en handmatige implementatie. Vibe coding start dichter bij **intentie en iteratie**. Dat maakt het krachtig voor discovery en MVP’s. Maar snelheid kan het risico stroomafwaarts verschuiven als teams rendering-strategie, toegankelijkheid, testing en zoek-eisen overslaan. Een eerlijke manier om ernaar te kijken is dit: vibe coding kan de bouwtijd comprimeren, maar het **verwijdert niet de noodzaak voor technische keuzes**. Het verandert alleen wanneer en hoe die keuzes zichtbaar worden. ## De SEO-conclusie De zoek-specifieke les is eenvoudig: **een vibe-coded app kan ranken, maar ranken hangt af van de output—niet van het feit dat AI heeft geholpen bij het bouwen**. Als je AI-tool een client-heavy SPA maakt, behandel SSR, prerendering, metadata, structured data en sitemaps dan als kernvereisten van het product in plaats van optionele polish. Dan is de beste definitie om in gedachten te houden: vibe coding is een snelle manier om software te bouwen vanuit prompts, en bij SEO-gerichte ervaringen hangt succes meestal af van het combineren van die snelheid met **server-rendered of anderszins indexeerbare content, duidelijke metadata en een crawlbare sitestructuur**. Als je dat doet, wordt vibe coding een praktische groeihandleiding in plaats van een vermijdbaar SEO-risico.