Vibe coding SEO: AI-code is pas nuttig als Google hem kan lezen

Vibe coding is pas SEO-proof als de code niet alleen werkt, maar ook crawlbaar, indexeerbaar en onderhoudbaar blijft. Een Lovable-site die in de browser goed oogt, kan voor Google nog steeds te weinig HTML, verkeerde metadata of een broze canonical-route hebben.

Cognition’s FrontierCode maakt een vergelijkbaar punt voor AI-code: werkend is niet hetzelfde als mergewaardig. Voor LovableSEO is de vertaling duidelijk. Een AI-sitebuilder-output is pas nuttig als je hem veilig kunt publiceren, controleren en later aanpassen zonder je rankings te slopen.

Bronnen en leeswijzer

• Cognition: Introducing FrontierCode
• Cognition FrontierCode result data JSON
• SWE-bench official leaderboards
• METR: Many SWE-bench-passing PRs would not be merged
• Terminal-Bench

Waarom dit past bij LovableSEO

LovableSEO.nl richt zich op SEO voor Lovable.dev en vibe-coded sites. De recente SEO-sprint draaide om crawlbare HTML, metadata, sitemap, canonical, auditroute en de vraag waarom Lovable-sites slecht ranken. De site heeft al een production-ready vibe-coding checklist, een gids over Claude Code voor Lovable SEO en een SEO-audit tool. FrontierCode past daar als kwaliteitskader bovenop.

De tweet van Cognition zegt dat modellen vaak slordige code schrijven die werkt, maar niet onderhoudbaar is. Dat is precies wat bij AI-sitebouw mis kan gaan. Een pagina rendert in preview. De CTA werkt. De animatie ziet er goed uit. Maar Google ziet lege of magere HTML, de title is generiek, de canonical klopt niet, images missen context en de route is later moeilijk te fixen.

Wat FrontierCode toevoegt aan de discussie

Cognition beschrijft FrontierCode als benchmark voor codekwaliteit. De taken zijn volgens Cognition gebouwd met maintainers van 36 open-source repos. De benchmark kijkt naar blockercriteria en kwaliteitscriteria: behavior, regressie, mechanical cleanliness, test correctness, scope en code quality. Een oplossing die blockercriteria mist, krijgt 0.

De Diamond-score is hard: Claude Opus 4.8 via Claude Code haalt 13,4%, GPT-5.5 via Codex 6,3%, Claude Opus 4.7 5,2%. Als zelfs frontier agents laag scoren op mergewaardige code, moet je bij vibe coding extra voorzichtig zijn. De output van Lovable, Cursor of Claude Code kan bruikbaar zijn, maar je moet hem beoordelen tegen een publicatierubric.

De SEO-variant van mergewaardig

Voor Lovable-sites betekent mergewaardig meer dan nette React-code. De code moet Google helpen de pagina te vinden, crawlen, indexeren en begrijpen. Dat vraagt een andere checklist dan “ziet het er goed uit?”

1. Crawlbare content

Staat de belangrijkste tekst in de HTML die Google kan verwerken? Of ontstaat de hele pagina pas na client-side rendering? Lovable-sites kunnen er voor gebruikers prima uitzien en voor crawlers toch te leeg zijn.

2. Metadata per pagina

Elke belangrijke URL heeft een specifieke title, meta description en canonical nodig. AI-sitebuilders maken vaak generieke patronen. Voor SEO is dat onvoldoende, vooral bij commerciële of lokale pagina’s.

3. Interne links

Google moet de URL kunnen ontdekken via crawlbare links. Buttons zonder echte href, client-only navigatie of verborgen routes maken indexatie fragiel.

4. Regressie bij AI-fixes

Een agent kan een SEO-probleem fixen en tegelijk een layout, form handler of canonical breken. Test daarom niet alleen de nieuwe fix, maar ook de bestaande belangrijke routes.

5. Onderhoudbaarheid

Als je later niet begrijpt waar metadata, routing en schema worden ingesteld, wordt elke SEO-fix duur. AI-code moet niet alleen nu rankbaar zijn, maar later te beheren.

Waarom “SEO achteraf fixen” duur is

Bij vibe coding voelt SEO vaak als een stap na de launch. Eerst bouwen, daarna optimaliseren. Dat werkt slecht wanneer de fundering niet klopt. Als routes client-only zijn, metadata ontbreekt of canonicalsignalen rommelig zijn, moet je achteraf in architectuur snijden. Dat is veel duurder dan vanaf het begin publicatiecriteria in je prompt zetten.

Gebruik daarom FrontierCode als denkkader. Vraag niet alleen aan je AI-tool: “fix mijn SEO.” Vraag: “maak deze pagina publiceerbaar volgens crawl, index, metadata, canonical, interne links, mobile layout en rollback.” Laat de agent vervolgens uitleggen welke bestanden zijn geraakt en hoe je controleert dat bestaande pagina’s niet zijn gebroken.

Wat we nog niet zeker weten

FrontierCode is geen SEO-benchmark. De taken gaan over codekwaliteit in repositories. De vertaalslag naar LovableSEO komt van ons, niet van Cognition. Ook zijn de FrontierCode-taken prive, waardoor buitenstaanders de resultaten niet volledig kunnen reproduceren. Gebruik de benchmark dus als kwaliteitsprikkel, niet als directe SEO-bron.

Daarnaast combineert de ranking model en harness. Een Claude Code-score op FrontierCode zegt niet precies hoe Claude Code jouw Lovable-project aanpakt. Je eigen setup, prompts, repo-instructies en testcases blijven bepalend.

Praktische route voor Lovable-sites

Begin met de production-ready vibe-coding checklist. Draai daarna de SEO-audit tool op je live URL. Als je Claude Code of een andere coding agent inzet, laat hem niet alleen code aanpassen, maar ook een SEO-diff opleveren: welke titles, canonicals, routes, links en schema zijn geraakt?

Voor indexeringsproblemen hoort de gids over Lovable Google indexering oplossen de canonical owner te blijven. Dit artikel vult die gids aan door de AI-codekwaliteit erachter te behandelen.

Mijn oordeel

FrontierCode is voor LovableSEO waardevol omdat het de hype uit vibe coding haalt. AI-sitebuilders zijn geweldig voor snelheid. Snelheid zonder publicatiekwaliteit levert alleen snellere technische schuld op.

Een Lovable-site is pas klaar voor SEO wanneer Google de pagina kan lezen, de metadata klopt, de interne links werken en een volgende developer of agent de code zonder giswerk kan aanpassen. Alles daarvoor is preview, geen publicatie.

Is SEO dood nu AI de antwoorden geeft?

Nee, maar de uitkomst verschuift. Waar SEO vroeger eindigde bij een klik, eindigt het steeds vaker bij een vermelding in een antwoord. De weg ernaartoe is dezelfde gebleven: een machine moet je pagina kunnen ophalen en lezen.

Wat wel verandert, en het is geen kleinigheid: je krijgt vertoningen zonder klikken. Iemand leest je uitleg in een AI-antwoord en klikt niet door. Dat voelt als verlies, maar het is dezelfde ruil als een featured snippet. Wie erin staat wordt genoemd; wie er niet in staat bestaat niet.

De praktische conclusie voor iemand die met AI bouwt: dezelfde techniek als altijd, plus zorgen dat je uitspraken los te knippen zijn. Hoe dat werkt staat in Lovable en GEO.

Is vibe coding echt coderen, en is het riskant?

Twee vragen die vaak samen gesteld worden en die verschillende antwoorden hebben.

Is het coderen? Je schrijft de regels niet zelf, maar je bepaalt wel wat er gebouwd wordt, in welke volgorde en wanneer het goed genoeg is. Dat is het deel van softwareontwikkeling dat altijd al het moeilijkst was. Wat verdwijnt is het typen, niet het denken.

Is het riskant? Ja, op drie specifieke punten, en geen daarvan gaat over de kwaliteit van de code zelf.

• Je leest niet wat je publiceert. Een model dat “werkende” code oplevert kan tegelijk een formulier bouwen dat nergens heen stuurt, of een pagina die alleen in de browser inhoud krijgt.
• Je merkt fouten pas als iemand klaagt. Zonder een controle vooraf ontdek je een kapotte checkout via een klant, niet via een test.
• Je bouwt sneller dan je opruimt. Vijftig pagina’s in een week klinkt goed, tot Google er vijftien indexeert en de rest als dun bestempelt.

Het antwoord op alle drie is hetzelfde: een korte vaste controle voordat iets live gaat. Die staat in de production-ready checklist.

Wat SEO in code betekent

Voor wie de term tegenkomt zonder context: SEO in de codelaag gaat over drie dingen die je in de build regelt, niet in een tekstveld.

1. Rendering — komt de inhoud mee in de HTML die de server terugstuurt, of pas nadat JavaScript draait.
2. Metadata per route — krijgt elke pagina een eigen titel, omschrijving en canonical, of erven ze die van de shell.
3. Statuscodes en redirects — geeft een verwijderde pagina een echte 404 of 301, of een 200 met een foutmelding erin.

Dat zijn de drie waar een gegenereerde site het vaakst op zakt, en alle drie los je op in de code. Niet in je content.