Fiz meu site no Lovable. O que falta antes de mandar para o cliente?

PARTE 01 / 09

A página abriu no preview. O botão parece certo. Você está prestes a copiar o link e mandar “ficou pronto”. Antes disso, vale separar três perguntas: o que foi construído, qual versão está no endereço compartilhado e o que você realmente testou.

Você não precisa transformar cada site numa auditoria interminável. Precisa conferir o percurso que vai apresentar e localizar o que ainda depende de correção, informação ou autorização.

Este guia termina com um registro de entrega e um pedido de correção reutilizável. Os exemplos são didáticos e não descrevem defeitos universais do Lovable.

PARTE 02 / 09

Comece pelo endereço que o cliente vai abrir

Preview e endereço publicado podem representar estados diferentes. A documentação do Lovable descreve a publicação como um snapshot: alterações posteriores no projeto precisam ser publicadas para aparecer na versão ao vivo. O acesso ao projeto no editor e o acesso ao site publicado também são configurações distintas. Fonte: Lovable — publicação.

Por isso, anote o endereço final, a versão ou alteração que você espera encontrar e o contexto do teste. Abra esse endereço numa janela sem a sessão de edição. Não use apenas a confirmação da ferramenta como evidência de que o cliente encontrará o mesmo conteúdo.

Um marcador simples ajuda: uma headline revisada, uma imagem ou uma seção identificável. Compare esse elemento entre preview e endereço compartilhado. Se houver diferença, investigue a versão antes de trocar domínio, integrações ou autenticação.

No exercício, imagine que o preview mostra “Peça uma avaliação” e o publicado ainda mostra “Comprar agora”. A observação é a divergência entre as versões. A causa ainda precisa ser confirmada. Não declare que foi cache apenas porque essa é uma explicação possível.

PARTE 03 / 09

Teste primeiro o percurso que você vendeu

Qual ação a página precisa permitir? Entender uma oferta e abrir o WhatsApp? Enviar um formulário? Escolher um produto? Acessar uma área restrita?

Escolha um percurso e siga do começo ao fim. Leia o texto como alguém que não participou da construção. Clique nos destinos, volte e observe o resultado da ação.

Se a entrega é uma página de contato, abrir o canal pode ser suficiente para verificar aquele trecho técnico. Isso não demonstra mensagem enviada, atendimento respondido ou venda. Se é um formulário, a aparência do botão não demonstra o recebimento da informação no destino.

Para testar envio, prefira ambiente de teste e dados fictícios, com autorização para o fluxo. Um teste não deve disparar mensagens reais, cadastrar pessoas sem consentimento ou alterar dados de clientes por acidente.

Registre o que foi observado: “Ao selecionar a linha A, o rascunho abriu com a linha A.” Evite “WhatsApp funcionando” quando você testou apenas o endereço do link.

PARTE 04 / 09

Use os testes do Lovable sem confundi-los com o site publicado

A documentação descreve testes em navegador capazes de navegar, acionar controles, preencher campos e observar erros no preview. Ela também esclarece que esse navegador remoto testa o preview do projeto. Fonte: Lovable — browser testing.

Uma sequência prática é implementar um recorte, pedir sua verificação no preview e depois conferir separadamente o endereço publicado no seu navegador, quando a publicação estiver autorizada.

Você pode pedir:

```text
Verifique no preview o percurso de escolher um serviço e preparar
uma mensagem. Use dados fictícios e não envie a mensagem.
Observe o resultado em desktop e numa tela estreita, incluindo
voltar, trocar a seleção e navegar pelo teclado.
Registre os passos, o que aconteceu e o que não foi possível testar.
Não altere o projeto durante este primeiro diagnóstico.
```

O pedido separa investigação de correção. Depois de saber o que falhou, você pode autorizar uma mudança específica, sem abrir espaço para reescrever a página inteira.

PARTE 05 / 09

No celular, não pare no “cabe na tela”

Confira se a pessoa percebe o próximo passo e consegue acioná-lo. Um conteúdo pode não ter overflow horizontal e ainda deixar o botão escondido por outro elemento, exigir rolagem pouco evidente ou não indicar que uma seleção mudou algo.

Teste uma tela estreita, uma tela baixa e o teclado virtual, quando houver campos. Se possível, abra no aparelho usado pelo público. Emulação ajuda a reproduzir dimensões, mas não equivale a todas as condições de um telefone físico.

Para uma falha de formulário, anote qual campo estava em foco, se o teclado cobriu a ação e se a rolagem permitiu continuar. Para uma seleção, descreva a opção escolhida e o retorno visual. “Arrumar o mobile” é amplo demais para orientar o reparo.

Não resolva um problema de composição reduzindo o texto até ficar ilegível ou escondendo o controle que a pessoa precisa usar.

PARTE 06 / 09

Publicação e busca são verificações separadas

Uma URL abrir não confirma que ela está indexada. Antes de prometer “o site já aparece no Google”, confira se a página pode ser acessada, se tem conteúdo útil e se existe alguma diretiva impedindo a indexação.

O Google explica que noindex precisa ser encontrado pelo rastreador para ser processado. Bloquear a URL em robots.txt pode impedir essa leitura. E noindex não é um controle de acesso para proteger conteúdo confidencial. Fonte: Google Search Central — noindex.

Confira também título, descrição e imagem de compartilhamento. Eles afetam o que você apresenta ao enviar o link, mas não garantem a mesma prévia em todo serviço ou atualização imediata de caches externos.

O Lovable oferece recursos de revisão de SEO e metadados. Use-os como parte da conferência, sem transformar um resultado da ferramenta numa garantia de descoberta, posição ou tráfego. Fonte: Lovable — SEO e busca com IA.

Não remova proteções de um ambiente de revisão para tentar fazê-lo aparecer na busca. A decisão de tornar uma página pública precisa ser explícita.

PARTE 07 / 09

Revise o que a IA colocou na oferta

Procure preço, prazo, depoimento, número de clientes, credencial, promessa, logotipo e imagem. Para cada afirmação relevante, identifique a fonte que autoriza o uso.

Uma frase plausível não se torna verdadeira porque ficou bem diagramada. Se o cliente não forneceu depoimentos, você não tem uma seção de depoimentos pronta: tem conteúdo que precisa ser removido ou substituído por uma prova existente.

Quando houver coleta de dados, confira o destino e o comportamento real antes de escrever declarações sobre privacidade. Não use “não armazenamos nada” só porque não criou um banco de dados na interface. Ferramentas, logs e serviços integrados também precisam entrar na avaliação correspondente.

PARTE 08 / 09

Corrija o problema observado, não o projeto inteiro

Use este formato de pedido:

```text
No endereço e na versão identificados abaixo, executei estes passos:
[passos que realmente executei].
Esperava [resultado esperado], mas encontrei [resultado observado].
A evidência disponível é [registro ou captura sem dados sensíveis].

Investigue a causa e proponha uma correção delimitada. Preserve [decisões e trechos que não devem mudar]. Após a correção autorizada, repita o percurso e confira os estados próximos. Não publique outra versão nem altere sistemas externos sem minha autorização.

```

Os campos indicam o que você deve preencher. Não os envie como se fossem dados já conhecidos. Se ainda não sabe reproduzir o problema, peça ajuda para investigá-lo em vez de preencher a lacuna com uma causa imaginada.

Depois do reparo, teste novamente. Uma alteração de layout pode corrigir um botão e modificar a navegação ao redor dele.

PARTE 09 / 09

Mande o link com um estado de entrega claro

Um encerramento útil para o cliente pode ser:

Segue a versão para revisão. O percurso de escolher o serviço e abrir o rascunho de contato foi testado em desktop e no mobile emulado. Falta confirmar a condição de prazo que está separada no registro. A publicação final depende dessa confirmação e do seu aceite.

Esse é um exemplo de mensagem, não uma descrição do seu teste. Adapte ao que realmente aconteceu. Quando já tiver testado o aparelho físico, registre-o. Quando não tiver, não esconda a diferença.

Use o Registro de entrega e correção desta leitura para reunir endereço, versão, percurso, resultado e pendências. Isso permite apresentar o trabalho sem chamar tudo de pronto por conveniência nem desvalorizar o que já está concluído.

Para aprofundar a qualidade da página, continue no guia sobre a primeira versão genérica. Para uma conferência de aceite, use o protocolo de revisão.