Korte versie

Nieuwe Lovable-sites geven Google sinds 13 mei 2026 volledige HTML, omdat ze met server-side rendering draaien. Oudere projecten krijgen pre-rendering voor zoekmachines. In onze test op een nieuwe Lovable-site ontbraken toch een sitemap, canonieke URL's en structured data. Een AI-agent loste dat op met één bericht via de Lovable MCP-server, las de codewijziging na, publiceerde en controleerde de live site opnieuw. Keuzes over zoekwoorden, feiten over je bedrijf en je deelbeeld blijven mensenwerk.

Lovable SEO is minder een probleem dan veel gidsen beweren, maar het werk is ook niet klaar na het bouwen. Een nieuwe Lovable-site geeft Google gewoon volledige HTML. Wat er wel vaak ontbreekt, is de basis die zoekmachines helpt: een sitemap, een canonieke URL per pagina en structured data over je bedrijf. Die stukken kan een AI-agent zelf in je Lovable-project zetten.

Ik heb dat uitgeprobeerd op een nieuwe testsite in Lovable, een fictieve bakkerij in Gent. Onze agent bekeek de gepubliceerde site, stuurde Lovable één gebundelde opdracht, las de codewijziging na, publiceerde en controleerde de live HTML opnieuw. Hieronder zie je wat Google vóór en na te zien kreeg, en wat ik bewust niet aan de agent overliet.

Is Lovable goed voor SEO?

Veel artikels over Lovable SEO gaan nog uit van een oude situatie. Lovable bouwde vroeger React-apps die pas in de browser hun inhoud opbouwden. Een zoekmachine kreeg dan eerst een bijna lege pagina. Dat beeld klopt niet meer voor nieuwe projecten.

Volgens de SEO-documentatie van Lovable draaien apps die vanaf 13 mei 2026 gemaakt zijn op TanStack Start met server-side rendering. Elke aanvraag krijgt dan volledig opgebouwde HTML, voor mensen en voor crawlers. Oudere React- en Vite-projecten krijgen pre-rendering: komt een erkende crawler van Google, Bing of een AI-zoekmachine langs, dan bouwt Lovable de pagina op de server op en stuurt die HTML terug.

Onze test bevestigde dat. De testsite die Lovable voor ons bouwde, is een TanStack Start-app. Een gewone curl zonder JavaScript gaf meteen de title en de h1 van de pagina terug. Elke pagina had bovendien al een eigen title en meta description.

Leesbaar zijn is wel iets anders dan vindbaar zijn. Lovable schrijft zelf dat elk nieuw project een robots.txt krijgt, maar niet altijd een sitemap, en dat de eerste metadata algemeen is. Ook de review in Lovable beoordeelt inhoud, zoekintentie, concurrenten en backlinks volgens de documentatie niet volledig. Daar zit het echte werk.

Wat ontbrak er op een nieuwe Lovable-site?

Voor de nulmeting controleerde de agent de gepubliceerde testsite met een paar vaste curl-checks: robots.txt, sitemap.xml en per pagina de title, de canonieke URL, de Open Graph-tags en eventuele JSON-LD. Dit vond de agent:

  • Geen sitemap: /sitemap.xml gaf een 404, en robots.txt verwees nergens naar een sitemap.
  • Geen canonieke URL en geen og:url op de drie pagina’s.
  • Geen structured data. Voor een bakkerij met een adres en openingsuren is een Bakery-blok de logische keuze.
  • Hetzelfde deelbeeld op elke pagina: Lovable zet automatisch een schermafbeelding van het project in og:image.

Geen van die punten houdt Google tegen. Ze maken het Google wel moeilijker om je pagina’s snel te vinden, de juiste URL te kiezen en je bedrijfsgegevens te begrijpen. Bij een site met drie pagina’s valt dat mee. Bij een site met tientallen pagina’s, een blog of meerdere talen wordt het een echt probleem.

Hoe past een AI-agent je Lovable-site aan?

Lovable heeft een officiële MCP-server op mcp.lovable.dev. Daarmee kan een externe AI-agent, zoals onze agent Hermes, projecten lezen, berichten naar Lovable sturen, de codewijziging opvragen en publiceren. De agent past de code dus niet zelf aan, maar geeft Lovable een precieze opdracht en controleert het resultaat. Zo zag de werkwijze eruit:

  1. Nulmeting op de live siteDe agent haalt robots.txt, sitemap en de HTML van elke pagina op en noteert wat ontbreekt. Gratis leesacties eerst, zodat er geen credits verloren gaan.
  2. Eén gebundelde opdrachtAlle aanpassingen gaan in één bericht naar Lovable, met duidelijke grenzen: geen ontwerp of zichtbare tekst wijzigen, geen feiten toevoegen die niet op de site staan.
  3. De codewijziging nalezenDe agent vraagt de diff op en controleert of Lovable deed wat gevraagd was, en niets meer dan dat.
  4. Publiceren en opnieuw metenNa het publiceren draaien dezelfde checks opnieuw op de live site. Pas dan telt een aanpassing als gelukt.
  5. Indexering aanvragenOp een echte klantsite met een eigen domein volgen de sitemap in Search Console en een indexeringsaanvraag voor de gewijzigde pagina's. Voor de testsite op lovable.app deden we dat bewust niet.

Het bericht aan Lovable kostte in onze test 1,3 credits. Op het gratis plan van Lovable heb je er weinig, dus bundelen loont. De agent las vooraf de bestanden met de gratis leesacties van de MCP-server en stuurde pas daarna één opdracht.

De echte run: vóór, opdracht, diff en na

Hieronder staat de volledige run van 14 november 2026, letterlijk zoals de agent hem uitvoerde: de nulmeting op de gepubliceerde site, het bericht aan Lovable, het eindantwoord van Lovable, de volledige codewijziging en dezelfde checks na het publiceren. Niets is ingekort of herschreven.

Na het publiceren gaf /sitemap.xml een 200 met een geldige XML-sitemap van de drie pagina’s. In robots.txt stond de sitemap, elke pagina had een canonieke URL en een og:url die naar zichzelf wezen, en de homepage had een Bakery-blok met het adres en de openingsuren van de pagina. Maandag staat erin als gesloten met 00:00 tot 00:00, zoals Google dat in zijn richtlijnen voor lokale bedrijven voorschrijft.

Wat de diff extra liet zien

De diff nalezen is geen formaliteit. Lovable deed meer dan gevraagd. Het voegde per pagina ook og:type en twitter:card toe, schreef een regel bij in het eigen AGENTS.md-bestand, maakte een roadmap.md aan en zette er een testbestand bij. De sitemap komt bovendien niet uit een vaste lijst, maar uit de routes van de app. Een nieuwe pagina komt er dus vanzelf in, zolang ze in de code als publiek gemarkeerd staat.

Hier is dat allemaal onschuldig, en de test op de openingsuren is zelfs nuttig. Op een klantsite wil je zulke extra’s wel zien voor je publiceert. Daarom leest de agent elke diff na en noteert wat er buiten de opdracht viel.

Wat doet de agent en wat blijft mensenwerk?

Een agent is sterk in werk dat terugkomt: checks draaien, bevindingen ordenen, één heldere opdracht schrijven, de wijziging controleren en opnieuw meten. Dat is het werk dat bij Lovable-sites vaak blijft liggen, omdat de site er af uitziet zodra ze gebouwd is.

Andere keuzes laat ik bewust niet aan de agent over:

  • Welke zoekwoorden en pagina’s ertoe doen. Dat vraagt kennis van je klanten en je aanbod.
  • Of de feiten kloppen. De agent gebruikte alleen gegevens die al op de site stonden. Op een echte site moet iemand bevestigen dat adres en openingsuren juist zijn.
  • Het deelbeeld. In de test bleef og:image een automatische schermafbeelding. Een goed beeld per pagina is ontwerpwerk.
  • De teksten en de beslissing om te publiceren.

Dat is ook hoe onze SEO AI-agent werkt bij klanten: de agent bereidt voor en voert uit binnen duidelijke grenzen, alles staat gedocumenteerd, en wij controleren wat er live gaat.

Lovable-review of een agent van buitenaf?

Lovable heeft zelf een SEO- en AI-zoekreview op het tabblad SEO & AI in Analytics. Die controleert onder meer sitemap, robots.txt, metadata, structured data en canonieke URL’s, en kan de meeste problemen met één klik laten oplossen. Voor veel kleine sites is dat een prima start. Een externe agent voegt vooral iets toe als je meer wilt dan een technische check.

OnderdeelSEO-review in LovableExterne AI-agent via MCP
Technische checksSitemap, robots.txt, metadata, structured data, canonieke URL'sDezelfde basis, met eigen checks op de live HTML
AanpassingenTry to fix per bevinding of voor alles samenEén gebundelde opdracht met grenzen, daarna diff nalezen
Inhoud en zoekintentieNiet volledig, volgens de eigen documentatieOp basis van Search Console-data en zoekwoordonderzoek
OpvolgingEen nieuwe scan wanneer je dat zelf startVaste cyclus: meten, aanpassen, opnieuw meten
Wie beslistJij, in de editorJij of wij, na een gedocumenteerd voorstel

Gebruik de review van Lovable dus zeker. Wil je dat iemand je zoekverkeer over tijd volgt, je teksten op zoekintentie afstemt en elke aanpassing documenteert, dan is een agent met menselijke controle de volgende stap. Komt je site uit een AI-ontwerp en wil je ze naar een eigen, snelle site laten omzetten, kijk dan naar van AI-ontwerp naar werkende website.

Hoe laat je een Lovable-site indexeren in Google?

Een sitemap helpt pas als Google ze ook leest. Zet je Lovable-site daarom op een eigen domein. Lovable schrijft zelf dat een adres op lovable.app goed is voor demo’s en tests, maar dat je vindbaarheid op een eigen domein opbouwt.

  1. Koppel je eigen domein in Lovable en stel het in als hoofddomein.
  2. Verifieer dat domein in Google Search Console. Lovable heeft daar een eigen koppeling voor.
  3. Dien je sitemap in en controleer of alle publieke pagina’s erin staan.
  4. Vraag met de URL-inspectie indexering aan voor je belangrijkste pagina’s.
  5. Meet na een maand opnieuw welke pagina’s geïndexeerd zijn en op welke zoekopdrachten ze verschijnen.

Wie dat ritme wil volhouden zonder elke maand alles zelf te doen, vindt in mijn gids over SEO automatiseren met AI hoe zo’n cyclus met een agent in elkaar zit.