--- title: "Lovable SEO fixen: het complete stappenplan (2026)" date: 2026-06-20 author: "" featured_image: "https://lovableseo.nl/wp-content/uploads/2026/06/lov-fixen.png" categories: - name: "Lovable basics" url: "/category/lovable-basics.md" --- # Lovable SEO fixen: het complete stappenplan (2026) “Lovable SEO fixen” klinkt als één knop. Het zijn in de praktijk vijf losse problemen, in een vaste volgorde. Wie ze in de verkeerde volgorde aanpakt — eerst schema, dan pas crawlbaarheid — verbrandt weken aan werk dat Google niet eens ziet. Dit is het stappenplan dat ik aanhoud, met per stap een test die je in dertig seconden zelf doet. **De korte route:** (1) test of de ruwe HTML crawlbaar is, (2) regel rendering — SSR, prerendering of een statische contentlaag, (3) zet unieke metadata per pagina, (4) voeg sitemap, canonical en schema toe, (5) vraag indexering aan in Search Console en meet daarna pas. Sla stap 1 niet over: zonder die test fix je vaak het verkeerde probleem. ## Eerst de realiteit van 2026: wat Lovable wél en níét voor je oplost Nieuw met Lovable, of wil je eerst weten hoe het platform en het credits-model werken? Lees dan [wat Lovable is en hoe het werkt](/wat-is-lovable/). Doet je site of de editor het helemaal niet, check dan eerst of er een [Lovable-storing](/lovable-storing/) speelt — fixen heeft pas zin als de boel draait. Sinds 20 april 2026 draaien **nieuwe** Lovable-projecten op TanStack Start met server-side rendering. Dat is echt vooruitgang: routes leveren server-gerenderde HTML, en Google kan die direct lezen zonder extra tooling. Het probleem is dat de meeste mensen die “lovable seo fixen” zoeken een **bestaand** project hebben — een oudere React + Vite-build. En die krijgt geen SSR. Wat bestaande projecten wél krijgen is automatische *on-request prerendering*: een gerenderde HTML-snapshot die alleen wordt geserveerd aan **geverifieerde** zoek- en AI-crawlers (Googlebot, Bingbot, en een lijst AI-bots). Dat is de valkuil waar bijna elke generieke gids overheen stapt. Want het betekent twee dingen: - Googlebot ziet waarschijnlijk wél gerenderde content — dus “mijn site is onzichtbaar voor Google” klopt sinds 2026 vaak niet meer letterlijk. - Maar **jij**, je SEO-tool, een view-source en elke niet-geverifieerde scanner zien nog steeds de lege SPA. Je test geeft dan een vals-negatief: het lijkt kapot terwijl Google het misschien wel leest — of andersom, het lijkt goed in je browser terwijl crawlers een dunne snapshot krijgen. Conclusie: vertrouw niet op je gevoel en niet op één tool. Test gericht, met de methode hieronder, vóór je iets fixt. Lovable heeft daarnaast een ingebouwd *Services → SEO & AI search*-paneel met “Try to fix” per bevinding. Handig voor de basis (titles, descriptions), maar het lost rendering en autoriteit niet voor je op. Het blijft jouw verantwoordelijkheid om te controleren wat crawlers echt binnenkrijgen. ## Wat de huidige topresultaten beter doen De SERP voor *lovable seo* beloont geen brede SEO-uitleg. De pagina’s bovenaan doen drie concrete dingen: ze wijzen naar Lovable’s eigen SEO & AI-search review, ze geven een controleerbare rendering- of metadata-test, en ze maken duidelijk wanneer SSR, prerendering of een simpele metadatafix genoeg is. Daarom moet jouw fixplan beginnen met bewijs per URL, niet met een lijst algemene SEO-taken. - **Officiële Lovable-docs:** leggen de nadruk op live review, metadata, canonical tags, alt-tekst, indexeerbaarheid, accessibility, mobile usability en performance. - **Praktische gidsen:** winnen met copy-paste prompts, verificatiestappen en concrete volgorde. - **Communitythreads:** laten zien dat makers vooral willen weten of Google hun app echt kan lezen. Onze extra stap: combineer die drie. Test eerst wat bots zien met de [Bot Vision Inspector](/bot-vision-inspector/), draai daarna de [gratis audit](/seo-audit-tool/), en pas dan kies je tussen metadata, sitemap, canonical, prerendering of SSR. ## Stap 1 — Test of je HTML überhaupt crawlbaar is (30 seconden) Je browser laat de gehydrateerde app zien: alles werkt, alles is mooi. Maar een crawler begint bij de ruwe HTML die direct van de server komt. Het verschil meet je zo: - **De curl-test (hardste bewijs).** Draai in een terminal `curl -s https://jouwdomein.nl/ | grep -o ''`. Krijg je je echte H1 terug? Dan staat er server-side content. Krijg je niets en zie je vooral `
` met scripts? Dan is die pagina client-side rendered. - **View-source.** Open `view-source:https://jouwdomein.nl/`. Zoek (Ctrl/Cmd+F) naar een zin die je op de pagina ziet staan. Niet te vinden in de bron = niet in de HTML = afhankelijk van JavaScript. - **JavaScript uit.** Zet in DevTools JavaScript uit en herlaad. Blanco pagina = pure CSR. Belangrijk voor bestaande Lovable-sites: omdat de prerender-snapshot alleen naar geverifieerde crawlers gaat, ziet een gewone `curl` mogelijk de lege SPA terwijl Googlebot iets anders krijgt. Wil je weten wat een specifieke bot ontvangt? Test dan met een Googlebot-user-agent, of gebruik onze [Bot Vision Inspector](/bot-vision-inspector/) — die laat naast elkaar zien wat Googlebot, ChatGPT en Perplexity van je pagina binnenkrijgen. Dat haalt het giswerk eruit. Test niet alleen je homepage. De homepage is vaak het best verzorgd; de echte gaten zitten op servicepagina’s, blogposts en productpagina’s. Pak er drie verschillende routes bij. Geeft alleen de homepage tekst terug, dan heb je een indexeringsrisico op de rest van je site. ## Stap 2 — Fix de rendering (en kies de goedkoopste fix die werkt) Dit is de stap met de meeste impact en het meeste verkeerde advies. Je hoeft *niet* meteen te migreren naar een nieuw framework. Kies op basis van je situatie: - **Nieuw Lovable-project (na april 2026):** je hebt waarschijnlijk al SSR via TanStack Start. Controleer dat met de curl-test op een paar routes en ga door naar stap 3. Niets te fixen — wel te verifiëren. - **Bestaande site, weinig pagina’s (leadgen, portfolio, ~tot 50 pagina’s):** de automatische prerendering van Lovable is vaak al genoeg voor Google. Wil je het zelf in handen hebben, dan is **statische prerender bij build** (Vite, met `vite-react-ssg` of een prerender-plugin) de simpelste, gratis route. Geen runtime, geen abonnement. - **Bestaande site, veel of dynamische pagina’s:** hier loont een **prerender-service** (Prerender.io of een Lovable-specifiek alternatief vanaf ±$9/maand) of een eigen **Cloudflare Worker** die een gecachte HTML-snapshot aan crawlers serveert. Dat is goedkoper en sneller geregeld dan een complete framework-migratie. - **Content-zware site die structureel moet ranken:** overweeg echte SSR of een aparte, crawlbare contentlaag (bijvoorbeeld je blog op een eigen, server-gerenderde stack). Snapshots van losse JS dekken dynamische content slecht af. Vuistregel: begin nooit met een migratie. Los het op het laagst mogelijke niveau op — prerender vóór SSR, SSR vóór herbouw. Een halve dag prerender-config is bijna altijd een betere eerste zet dan een week framework-migratie met hydration-valkuilen. Weeg daarbij af: een gratis route (statische prerender met Vite, eventueel achter een Cloudflare Worker) heeft geen maandlasten maar wel build-onderhoud; een betaalde service kost geld maar regelt caching en bot-detectie voor je. ## Stap 3 — Zet unieke metadata per pagina (de stille dubbele-content-killer) Lovable-apps starten met één set meta-tags in `index.html`. Gevolg: elke pagina heeft dezelfde title, dezelfde description en dezelfde OG-image. Google ziet dat als thin, near-duplicate content — tien pagina’s die zich voordoen als dezelfde pagina. Zelfs met perfecte rendering rank je dan slecht. De fix in een React + Vite-build is een eigen `useSEO`-hook (of `react-helmet-async`) die per pagina `document.title`, de meta-description en de canonical zet. Roep die bovenaan elke pagina-component aan met pagina-specifieke waarden. Concreet per route nodig: - Een unieke, beschrijvende `` (±50–60 tekens, met je belangrijkste term vooraan). - Een unieke meta-description die de zoekintentie van díe pagina dekt. - Een `<link rel="canonical">` naar de definitieve URL van die pagina. - Eén duidelijke `<h1>` per pagina. Let op de prerender-volgorde: zet je metadata client-side via een hook, maar prerender je een snapshot, controleer dan dat de snapshot de *bijgewerkte* tags bevat en niet de lege defaults uit `index.html`. Dat is de meest gemiste fout: metadata die in de browser klopt, maar in de gecachte snapshot nog op de standaardwaarde staat. ## Stap 4 — Maak je URL’s expliciet: sitemap, canonical, schema Een Lovable-site zonder sitemap dwingt Google om alles via interne links te ontdekken — traag, zeker bij een nieuwe site zonder autoriteit. Regel deze drie: - **Sitemap.** Genereer een `/sitemap.xml` bij build (bijvoorbeeld met `vite-plugin-sitemap`), verwijs ernaar in `/robots.txt` met `Sitemap: https://jouwdomein.nl/sitemap.xml` en submit hem in Search Console. Herhaal na elke deploy. Volg de stappen in [de sitemap-gids](/sitemap-toevoegen-lovable/). - **Canonical.** Eén definitieve URL per pagina. Liever consequent `https://jouwdomein.nl/pricing/` dan een mix van www/non-www, slash/geen-slash of oude Lovable-preview-URL’s. Anders versnipperen je impressies in GSC over varianten. Wanneer je *noindex* in plaats van canonical moet kiezen, lees [noindex of canonical bij dubbele pagina’s](/noindex-of-canonical/). - **Schema.** Voeg minimaal `Organization` en `WebSite` op je root toe, plus per pagina-type `Article`, `Product` of `LocalBusiness`. Schema is geen rankingknop, maar het levert rich results en context. Concrete JSON-LD staat in [de schema-gids](/json-ld-schema-lovable-stap-voor-stap/); de nuance over wat schema wél en níét doet in [dit artikel](/structured-data-geen-rankingknop/). ## Stap 5 — Vraag indexering aan en meet indexering los van ranking Search Console is geen reparatieknop. De URL-inspectie is pas nuttig zodra de pagina écht crawlbaar is. Vraag dán indexering aan — voor je homepage, je belangrijkste commerciële pagina en één of twee sterke ondersteunende pagina’s. Laat dunne testpagina’s, oude previewroutes en duplicate landingpages met rust: je eerste indexeringssignaal moet schoon zijn. En haal indexering niet door elkaar met ranking. Geïndexeerd = Google heeft de pagina opgenomen. Ranken = daarna betere content, interne links, autoriteit en kloppende zoekintentie. Veel Lovable-builders blijven technische fixes stapelen terwijl de pagina inhoudelijk te dun is. Sta je op positie 10–20, dan is de volgende zet geen nieuwe sitemap maar het aanscherpen van title, intro, interne links en bewijs. Lees dan ook [waarom je Lovable-site niet rankt](/waarom-rankt-mijn-lovable-site-niet/). ## Korte antwoorden op vragen uit de SERP **Ondersteunt Lovable SEO?** Ja, nieuwe Lovable-projecten hebben betere SEO- en AI-search tooling dan oudere builds. Dat betekent niet dat elke pagina automatisch goed rankt. Je moet nog steeds per route controleren of HTML, title, description, canonical, sitemap en interne links kloppen. **Hoe doe je SEO voor Lovable?** Begin met een publieke URL-test. Staat de hoofdtekst niet in de HTML of bot-snapshot, dan los je rendering op. Staat de tekst er wel, dan werk je aan title/meta, intent-match, interne links, sitemap, schema en bewijs op de pagina. **Is SEO in 2026 dood?** Nee. Voor Lovable-sites is SEO juist praktischer geworden: Google beloont pagina’s die snel laten zien wat ze oplossen en technisch leesbaar zijn. AI-search verandert de zichtbaarheid, maar dezelfde basis blijft nodig. ## De volgorde, in één blik Crawlbaarheid testen → rendering fixen → unieke metadata → sitemap, canonical, schema → indexering aanvragen en meten. Andersom werkt niet: schema op een pagina die Google niet kan lezen is zinloos, en indexering aanvragen vóór de rendering-fix vraagt Google vooral om een halflege pagina opnieuw te bekijken. Een ervaren ontwikkelaar loopt dit in een paar dagen door; een nieuwe builder twee tot vier weken, vooral door hydration- en prerender-valkuilen. Begin hier ## Weet binnen een minuut welke stap jouw site blokkeert. De gratis audit checkt de signalen die bij Lovable-sites het vaakst misgaan: HTTP-status, title, description, H1, canonical, sitemap en schema. Daarna weet je of je bij stap 1, 2 of 4 moet beginnen. [Start de gratis audit](/seo-audit-tool/) [Bekijk wat bots zien](/bot-vision-inspector/) Nog één ding voor wie al links naar zijn Lovable-site heeft verzameld: controleer af en toe of die links er nog staan. Een verhuisde pagina of een redacteur die je link weghaalt zie je anders pas als je positie zakt. Een [gratis backlink check](https://backlinksbeheer.nl/) is genoeg om dat maandelijks bij te houden. ## Hoe je SEO repareert als je niet weet waar het misgaat De meeste mensen beginnen met aanpassen zonder eerst vast te stellen wat er stuk is. Deze volgorde voorkomt dat je een middag verkeerd zoekt. 1. **Kijk in Search Console wat de status van je URL is.** Staat er “onbekend bij Google”, dan heeft hij je pagina nooit opgehaald en heeft aanpassen geen enkele zin. 2. **Haal je pagina op zonder JavaScript.** Zie je een lege div, dan is dat je enige probleem. Alles hieronder wacht. 3. **Controleer je metadata in de bron.** Eigen title, eigen description, canonical naar jezelf, en geen noindex die er per ongeluk staat. 4. **Kijk of de pagina bereikbaar is.** Vanaf je menu, je index of een andere pagina die zelf al gevonden wordt. 5. **Pas dan naar de inhoud.** Beantwoordt de pagina de vraag, en staat dat antwoord bovenaan. Wat je op elk punt precies doet staat in de stappen hierboven op deze pagina. ## De prompt die je aan Lovable geeft Vragen om “betere SEO” levert kosmetische wijzigingen op. Wat wél werkt is per fix precies benoemen wat je wilt zien in de HTML die de server terugstuurt. Bijvoorbeeld: - *“Zet voor elke route een eigen title en meta description in de server-gerenderde HTML, gebaseerd op de paginadata, niet op een sjabloon voor de hele site.”* - *“Voeg per route een canonical toe die naar de eigen URL wijst, inclusief afsluitende slash, in de head van de server-respons.”* - *“Genereer een sitemap.xml op basis van de bestaande routes en werk hem bij bij elke build.”* - *“Laat verwijderde routes een 404-statuscode geven in plaats van een 200 met een foutmelding.”* Controleer na elke wijziging in de paginabron of het er echt staat. Een model dat zegt dat het gedaan is, heeft het niet altijd gedaan — en bij metadata zie je het verschil niet in je browser. ## Wat je overslaat Drie dingen waar veel tijd in gaat zitten en die bij een Lovable-site zelden het probleem zijn: - **Keyworddichtheid.** Bestaat niet als rankingfactor en heeft nooit bestaan. - **Alle schema-types toevoegen.** Vier volstaan; zie [JSON-LD voor Lovable](/json-ld-schema-lovable-stap-voor-stap/). - **Snelheid tot achter de komma optimaliseren** terwijl je pagina leeg binnenkomt bij Google. Een snelle lege pagina is nog steeds leeg.