Como o Lovable acelerou o nosso próprio site, e o que continuou sendo trabalho nosso

O Lovable encurtou muito o tempo entre decidir e ver funcionando no nosso próprio site. O que ele não fez foi garantir que o site fosse lido por buscadores e crawlers de IA, que o analytics registrasse visitas de verdade e que as versões em inglês e espanhol mostrassem conteúdo em inglês e espanhol. Isso foi trabalho nosso, e parte dele só apareceu meses depois do lançamento.

Este é o relato de como usamos a ferramenta, com os problemas incluídos. Serve para quem está avaliando construtores de aplicações com IA para o site da empresa, uma landing page ou um produto interno.

Por que usamos o Lovable

Construímos sites, plataformas e sistemas para clientes. Quando chegou a hora de reconstruir o nosso, com identidade visual nova e conteúdo que refletisse o que a Cortex IQ faz, o projeto tinha o destino clássico de projeto interno: sempre ficava para a semana seguinte.

O Lovable é um construtor de aplicações web em que você descreve o que quer em linguagem natural e um agente escreve e edita o código. A ferramenta se chamava GPT Engineer antes de mudar de nome (Lovable), e é por isso que, no histórico do nosso repositório, os commits gerados por ela aparecem assinados por "gpt-engineer-app[bot]".

O código resultante é um projeto React comum: Vite, TypeScript, Tailwind CSS e componentes shadcn/ui, com banco de dados e funções de backend via Supabase, oferecido dentro da plataforma como Lovable Cloud. Não é uma caixa-preta. O projeto sincroniza com o GitHub nos dois sentidos (Lovable Docs), então dá para abrir o código em qualquer editor e trabalhar nele fora da ferramenta.

O que construímos

O escopo não era de landing page: páginas institucionais, páginas de serviço, páginas de oferta montadas a partir de um único template alimentado por dados, cases, blog, formulários que gravam no banco e disparam e-mail, banner de cookies que só libera o Google Analytics 4 depois do consentimento e três idiomas (português, inglês e espanhol).

A abordagem que funcionou foi tratar o Lovable como um desenvolvedor rápido que precisa de briefing preciso. Cada pedido dizia a stack, os tokens de cor exatos, a hierarquia de componentes, o padrão de formulários e as regras de internacionalização. Quanto mais contexto explícito, menos retrabalho.

Onde precisamos intervir no lançamento

Três pontos exigiram alguém com a mão no código ou reescrevendo o pedido:

1. Identidade visual de uma oferta. Uma das páginas de oferta saiu com um tema visual diferente do resto do site. Corrigimos com um prompt de override detalhado. Lição: se a identidade é específica, ela precisa estar escrita no pedido, não implícita.
2. Arquivos para buscadores. Gerar o sitemap a partir dos arquivos de conteúdo exigiu código escrito à mão. Tarefas que dependem do processo de build ainda ficam melhores com um desenvolvedor.
3. Conflitos de dependência. Versões incompatíveis entre bibliotecas quebraram o build mais de uma vez. É o ritmo do ecossistema JavaScript, não um defeito da ferramenta, mas alguém precisa perceber antes de publicar.

O que apareceu depois do lançamento

Esta seção foi acrescentada em setembro de 2026, com o site alguns meses no ar. É a parte mais útil do relato, porque são problemas que não aparecem no preview.

O conteúdo estava em português para todo mundo. As páginas de ofertas, de cases e da RÜNARA mostravam o texto em português mesmo quando a URL era /en-us ou /es-es. O menu trocava de idioma, o conteúdo principal não. Nada quebrava visualmente, por isso passou despercebido até uma revisão arquivo por arquivo.

O analytics não registrava visitas. O código carregava o Google Analytics por injeção dinâmica de script depois do consentimento. A camada de dados mostrava os eventos corretos, mas nenhuma requisição chegava de fato ao Google. Resolvemos trocando para a tag estática no HTML, com a configuração ainda condicionada ao consentimento, o mesmo padrão que já funcionava em outros dois sites nossos hospedados no Lovable. Também descobrimos que a navegação entre páginas, por ser uma aplicação de página única, não gerava page_view, e passamos a registrar cada troca de rota.

Crawlers de IA viam uma página vazia. Esse foi o mais sério. O site era renderizado inteiramente no navegador: as 84 URLs do sitemap entregavam o mesmo HTML vazio, e o conteúdo só aparecia depois de o JavaScript rodar. O Google renderiza JavaScript numa etapa posterior ao rastreamento (Google Search Central), mas uma análise da Vercel mostrou que nenhum dos grandes crawlers de IA, incluindo GPTBot e ClaudeBot, executa JavaScript (Vercel, 2024). Para quem quer ser citado por ChatGPT, Claude ou Perplexity, isso equivale a não ter site. A correção foi uma etapa de pré-renderização no build, que gera HTML estático com conteúdo, título e dados estruturados para cada rota.

O código local ficou 23 commits atrás. Como o Lovable e o GitHub sincronizam pela branch principal, edições feitas direto no editor do Lovable e edições feitas localmente divergiram. A reconciliação exigiu resolver conflitos arquivo por arquivo. Hoje a regra é simples: cada mudança nasce num lugar só, e quem vai começar sincroniza antes.

Nenhum desses problemas é exclusivo do Lovable. São problemas comuns de qualquer aplicação de página única feita com pressa. A diferença é que a velocidade da ferramenta faz você chegar a eles mais rápido e, às vezes, publicar antes de perceber.

O que faríamos diferente desde o primeiro dia

Com o que sabemos hoje, três decisões teriam vindo antes da primeira tela.

1. Pré-renderização ou renderização no servidor desde o início. Corrigir depois exigiu mexer no build, no roteamento e em partes do código que acessavam recursos do navegador no carregamento. Seria mais barato ter nascido assim.
2. Uma regra escrita sobre onde as mudanças acontecem. A divergência de 23 commits exigiu uma reconciliação arquivo por arquivo que um combinado de duas linhas teria evitado.
3. Um teste automático simples no build que abre cada rota em cada idioma e confere se o conteúdo principal está no idioma certo. Os bugs de idioma teriam sido pegos no primeiro dia, e não meses depois.

Nenhuma dessas decisões depende da ferramenta escolhida. Todas dependem de alguém fazer as perguntas certas antes de pedir a primeira tela.

Checklist antes de publicar um site feito com IA

• Abra o código-fonte da página (não o inspetor do navegador) e confira se o texto principal está no HTML. Se não estiver, crawlers de IA não vão ler.
• Troque o idioma na URL e leia o conteúdo, não só o menu.
• Aceite os cookies e confira no relatório em tempo real do GA4 se a visita aparece. Depois recuse e confirme que nada é enviado.
• Navegue entre três páginas e veja se cada uma gera uma visualização.
• Cole o link de cada página importante no LinkedIn ou no WhatsApp e confira título, descrição e imagem.
• Valide o sitemap: toda URL listada deve existir e ter conteúdo no idioma declarado.
• Decida onde as mudanças acontecem, no editor do Lovable ou no repositório, e deixe isso escrito.

Para quem vale a pena

Vale para quem sabe exatamente o que quer construir, tem alguém capaz de ler o código gerado e tem um design system minimamente definido para servir de âncora. Sem clareza de escopo, qualquer ferramenta produz o resultado errado mais rápido. Sem alguém técnico revisando, os problemas acima só aparecem quando o tráfego não vem.

A divisão que ficou para nós é a mesma que defendemos com clientes: a ferramenta gera, as pessoas decidem, verificam e respondem pelo que vai ao ar. Se estiver avaliando esse caminho para o site ou um produto da sua empresa, veja os projetos que já entregamos e como trabalhamos com apps e produtos digitais.