Risposta breve

Le app con codifica Vibe eseguono il rendering sul lato client, quindi i crawler vedono un <div> vuoto. Puoi risolvere il problema inserendo un Cloudflare Worker tra il tuo dominio e Lovable che restituisce l'HTML renderizzato dal server ai bot, oppure migrando il progetto in uno stack reale (Claude Code + Supabase + Vercel) prima di investire nel marketing.

Strumenti come Lovable, Bolt e v0 sono fantastici per trasmettere un'idea in un pomeriggio. Non sono eccezionali in SEO. L'intera pagina è un bundle React lato client, il che significa che Googlebot alla prima scansione vede un <div id="root" /> vuoto. Nessun contenuto. Nessuna intestazione. Nessuno schema. Nessuna classifica. Per un MVP che fa affidamento sul traffico organico, questo è un problema da anno di fondazione.

Ecco le due correzioni che utilizziamo in Start Apps Studio, ordinate dal minimo sforzo al massimo profitto.

Correzione 1: proxy SSR Cloudflare Worker

Un Cloudflare Worker si trova tra il tuo dominio e Lovable. Quando arriva una richiesta, il Worker controlla lo User-Agent: i visitatori reali vengono proxy tramite Lovable come al solito; bot (Googlebot, Bingbot, GPTBot, PerplexityBot, ClaudeBot) ottengono HTML renderizzato dal server con contenuto reale e markup dello schema completo, dallo stesso URL.

Questo non è cloaking quando è fatto correttamente. Il contenuto ricevuto dal bot deve corrispondere a ciò che l'utente vede una volta eseguito il JS. La configurazione prevede due passaggi:

  1. Aggiungi un CNAME al tuo DNS che punta il tuo dominio personalizzato su Cloudflare Worker.
  2. Incolla un prompt all'interno di Lovable in modo che il lavoratore abbia un inventario di pagine canoniche da cui eseguire il rendering del server.

Correzione 2: migrazione da Lovable con Claude Code

Il Cloudflare Worker ti fa guadagnare tempo. Ma se l'app deve essere classificata seriamente, gestire contenuti dinamici o essere mantenuta da persone tra un anno, ti consigliamo di passare a uno stack web "normale". Il modo più veloce che abbiamo visto è lasciare che Claude Code esegua la migrazione per te.

La ricetta della migrazione in 10 passaggi

  1. Sposta il tuo progetto Lovable su GitHub in modo che Claude possa lavorarci facilmente.
  2. Installa Claude Code localmente in modo che possa leggere e modificare direttamente il tuo repo.
  3. Punta Claude al tuo repo (percorso remoto o locale di GitHub).
  4. Creare un progetto Supabase per database e auth (circa cinque minuti).
  5. Chiedi a Claude di migrare il progetto lontano da Lovable con questo prompt: "Migra questo progetto Lovable in un normale stack web e organizza il repo in modo pulito."
  6. Configura l'hosting su Vercel. Il livello gratuito copre la maggior parte degli MVP.
  7. Chiedi a Claude quali variabili di ambiente e chiavi API sono necessarie; è sorprendentemente bravo a identificarle.
  8. Generare le chiavi e creare un file .env (chiavi Supabase, token API, ecc.).
  9. Chiedi a Claude di configurare la distribuzione. Può collegare il flusso di GitHub → Vercel e collegare Supabase.
  10. Correggi tutto ciò che si rompe chiedendo a Claude di eseguire il debug, un errore alla volta.

Questa configurazione risulta più flessibile della stessa Lovable. Smetti di pagare crediti per richiesta per le modifiche all'app e puoi ricorrere a modelli gratuiti per piccole modifiche, poiché Lovable utilizza già Claude sotto il cofano per la maggior parte della sua generazione.

L'ibrido Lovable + Claude

Se sei a metà progetto e non sei pronto per la migrazione, esiste un percorso intermedio convalidato da più utenti r/lovable: collega Lovable a GitHub, quindi concedi a Claude Code l'accesso allo stesso repository. Claude si trova su un livello sopra Lovable, guidandolo attraverso funzionalità complesse, debug e miglioramenti, mentre esegui SQL direttamente in Supabase per le modifiche al database (Lovable non addebita alcun costo per eseguire una query, quindi è gratuito).

Risultati: meno crediti bruciati sui componenti di blocco (gli utenti segnalano oltre 100 crediti salvati su un singolo componente), migliore gestione della logica aggrovigliata e, fondamentale per questo articolo, controllo sufficiente sull'HTML di output da poter aggiornare SSR e schema in modo incrementale.

Quale soluzione dovresti scegliere?

  • Solo sito di marketing o landing page → Cloudflare Worker SSR. Più economico, più veloce.
  • Il prodotto con contenuto dinamico che deve essere classificato → migra a Claude Code + Supabase + Vercel.
  • Metà progetto e non può ricostruire → Lovable + Claude ibrido, quindi retrofit SSR sulle pagine che contano.

Domande frequenti

Perché Google non riesce a indicizzare direttamente le pagine Lovable?

Lovable fornisce un bundle React renderizzato dal client, quindi l'HTML iniziale è un div root vuoto. La scansione di primo passaggio di Googlebot acquisisce l'HTML vuoto; potrebbe (o meno) tornare più tardi per eseguire il rendering di JavaScript. Per i nuovi domini senza autorità, il rendering di secondo passaggio spesso non viene mai attivato.

La correzione di Cloudflare Worker è considerata cloaking?

Non se il bot vede lo stesso contenuto che un utente vede alla fine una volta eseguito JS. Servire HTML pre-renderizzato ai bot è un modello SEO consolidato; diventa cloaking solo se offri contenuti diversi ai bot rispetto agli utenti.

Quanto costa la migrazione completa?

Fai da te: un weekend e un account gratuito Vercel + Supabase. Fornito da Start Apps Studio: in genere intorno a uno sprint, integrato nel nostro pacchetto MVP Production.

Posso continuare a modificare visivamente dopo la migrazione?

Perdi l'editor nel browser di Lovable, ma ottieni un normale ciclo di sviluppo e puoi portare qualsiasi strumento visivo (o un altro costruttore di intelligenza artificiale) in cima al repository. La maggior parte dei team non se ne accorge una volta che vede quanto più velocemente Claude Code esegue l'iterazione.