Como publicar um site feito no Lovable, no Claude ou no AI Studio

Para publicar um site feito no Lovable com o seu domínio, você gera a versão final do código (o “build”, que cria a pasta dist), envia esses arquivos para a pasta public_html da hospedagem, cria um arquivo .htaccess para as rotas e ativa o SSL. O mesmo caminho serve para uma página HTML feita no Claude. Já os projetos que precisam de um servidor rodando, como os do Lovable em TanStack Start e os apps do Google AI Studio que chamam o Gemini, pedem outro tipo de hospedagem.

O que é preciso para publicar um site feito no Lovable?

• Uma hospedagem com painel e acesso aos arquivos. Serve uma hospedagem compartilhada comum, como a hospedagem de pagamento único da PW Host, que usa o painel DirectAdmin.
• Um domínio, registrado à parte. O .com.br custa R$ 40 por ano no Registro.br (valor conferido em 02/10/2026). Se ainda não sabe onde registrar, veja se o Registro.br tem hospedagem e o que ele oferece.
• O código do projeto, exportado da ferramenta de IA (passo 1 abaixo).
• O Node.js instalado no computador, só para projetos do Lovable e do AI Studio, que precisam do build. A documentação do Lovable recomenda a versão 22. Uma página HTML do Claude dispensa esse passo.

Seu projeto pode ir para uma hospedagem comum?

Depende de como a ferramenta montou o projeto. Este tutorial publica o site como arquivos prontos (HTML, CSS, JavaScript e imagens), que qualquer hospedagem entrega. Se o projeto depende de um programa rodando no servidor a cada visita, só enviar os arquivos não basta. Por isso, antes de qualquer passo, descubra o tipo do seu projeto:

Ferramenta e tipo de projeto	Como saber	Dá para publicar só com os arquivos?
Lovable, React + Vite (projetos criados até 12/05/2026)	O package.json não tem @tanstack/react-start	Sim. O build gera arquivos estáticos na pasta dist
Lovable, TanStack Start (projetos criados a partir de 13/05/2026)	O package.json lista @tanstack/react-start	Não. Precisa de um host que rode a parte de servidor
Claude, página HTML	O código começa com <!DOCTYPE html> e cabe num arquivo só	Sim. Basta salvar como index.html
Claude, componente React (.jsx)	O código tem import React e export default	Sim, depois de convertido em HTML ou montado num projeto com build
Google AI Studio, app que chama o Gemini	O app usa IA ao vivo (gera texto, imagem, responde ao usuário)	Não. A chave da API precisa ficar num servidor Node.js

A data de 13/05/2026 vem da documentação do Lovable, que diz que os apps criados a partir dela usam TanStack Start e precisam de “um host que rode a parte de servidor”. Se o seu projeto é desse tipo, este tutorial não resolve: continue publicando pelo próprio Lovable ou use um serviço que rode Node.js. O mesmo vale para o app do AI Studio que conversa com o Gemini.

Passo 1: como pegar o código do projeto?

No Lovable

Há dois caminhos, segundo a documentação do Lovable:

• Sincronizar com o GitHub (em todos os planos). O Lovable mantém o código igual nos dois lados. Depois, no GitHub, use o botão Code e a opção Download ZIP para baixar o projeto.
• Download codebase (só nos planos pagos), nas configurações do projeto. Gera um arquivo .zip com o código daquele momento.

Confira se o arquivo .env veio junto. É nele que ficam as variáveis VITE_SUPABASE_URL e VITE_SUPABASE_PUBLISHABLE_KEY, que ligam o site ao banco de dados quando o projeto usa o Lovable Cloud ou o Supabase.

No Claude

O link de compartilhamento do Claude fica no endereço do próprio Claude, não no seu domínio. Pela central de ajuda da Anthropic, quem abre um artefato compartilhado precisa ter conta no Claude; a exceção são os artefatos antigos, publicados a partir de um chat com o botão Publish. Para usar o seu domínio, você precisa do código. Nos artefatos antigos (feitos num chat antes de 16/09/2026), os controles no topo do painel mostram o código e permitem copiar ou baixar o conteúdo. Nos demais, ou se o código for um componente React, peça ao próprio Claude que entregue a página como um único arquivo HTML, sem etapa de build. Salve como index.html e pule para o passo 3.

No Google AI Studio

No modo Build, o app pode ser exportado como arquivo ZIP ou ligado a um repositório do GitHub. A documentação do Google diz que, ao exportar, você precisa configurar a variável GEMINI_API_KEY no ambiente de hospedagem, porque as chamadas ao Gemini saem do código de servidor. Uma hospedagem de arquivos não tem esse ambiente. Só vale seguir o tutorial se a página não usar o Gemini nem outra função de servidor.

Passo 2: como gerar o build (a pasta dist)?

O código que a ferramenta de IA entrega é o “código-fonte”. O navegador não abre esse código direto: antes, ele precisa ser compilado num conjunto de arquivos prontos, que é o build. Com o Node.js instalado, descompacte o projeto, abra o terminal dentro da pasta dele e rode:

npm install
npm run build

O primeiro comando baixa as dependências. O segundo cria a pasta dist, que é o que vai para a hospedagem. Três cuidados:

• As variáveis que começam com VITE_ entram no build na hora em que ele é gerado. Se você mudar o .env, gere o build de novo.
• Tudo o que está numa variável VITE_ fica visível para quem abrir o site. A chave publicável do Supabase foi feita para isso. Uma chave secreta (do Gemini, da OpenAI, de pagamento) nunca deve ir para lá.
• Antes do build, crie o .htaccess do passo 4 dentro da pasta public do projeto. O Vite copia o conteúdo dessa pasta para a raiz da dist, então o arquivo vai junto em todos os builds.

Passo 3: como enviar os arquivos pelo Gerenciador de Arquivos?

No painel DirectAdmin, o caminho é este:

1. No computador, entre na pasta dist e compacte o conteúdo dela num arquivo .zip (o index.html e a pasta assets, não a pasta dist inteira).
2. No painel, abra o Gerenciador de Arquivos e entre em domains/seudominio.com.br/public_html.
3. Se houver uma página padrão do painel (um index.html de boas-vindas), apague ou renomeie.
4. Envie o .zip e use a opção de extrair o arquivo nessa mesma pasta. Depois apague o .zip.
5. Confira o resultado: o index.html precisa estar direto dentro de public_html. Se ficou em public_html/dist/index.html, mova os arquivos uma pasta acima.

Se preferir, envie os arquivos por FTP com um programa como o FileZilla, usando os dados de acesso da sua conta. O destino é o mesmo: a pasta public_html do domínio.

Passo 4: o que pôr no .htaccess para as páginas não darem 404?

Um site feito em React troca de página no próprio navegador. O endereço /contato, por exemplo, não existe como arquivo no servidor. Quem clica num link dentro do site não percebe nada, mas quem abre seudominio.com.br/contato direto, ou atualiza a página, recebe um erro 404. A solução é mandar o servidor entregar o index.html sempre que o arquivo pedido não existir. É a regra que a documentação do Lovable indica para servidores compatíveis com o Apache:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.html$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.html [L]

Na prática: se o arquivo existe (uma imagem, um script), o servidor entrega o arquivo. Se não existe, entrega o index.html, e o React mostra a página certa. Salve as linhas num arquivo chamado .htaccess, com o ponto no começo, dentro de public_html. Se você seguiu a dica do passo 2, ele já está lá.

Na PW Host o servidor é LiteSpeed, e a documentação da LiteSpeed diz que o motor de reescrita dele segue a especificação do Apache. Por isso as mesmas linhas funcionam sem ajuste. Para testar, abra uma página interna do site pelo endereço completo e aperte F5.

Passo 5: como ligar o domínio e ativar o SSL?

• Aponte o domínio para a hospedagem. No registrador, troque os nameservers ou o DNS conforme os dados que a hospedagem passou na ativação. A mudança pode levar algumas horas para valer em toda a internet.
• Se o domínio estava ligado ao Lovable, tire de lá os registros do Lovable: o registro A com o IP 185.158.133.1 e o TXT _lovable (o que guarda o valor lovable_verify=). Senão, parte dos visitantes continua indo para o servidor do Lovable.
• Ative o certificado SSL no painel. O certificado só é emitido quando o domínio já aponta para o servidor, então faça isso depois da propagação.
• Se o site tem login (Lovable Cloud, Supabase, Google), acrescente o novo endereço na lista de URLs de redirecionamento permitidas do provedor de login. Sem isso, o login volta para o endereço antigo ou dá erro.

E o banco de dados, o login e a IA do site?

A hospedagem passa a entregar a parte visual do site (a interface). O que roda nos bastidores continua onde estava:

• Lovable Cloud ou Supabase: o banco de dados, o login e as funções continuam lá. A documentação do Lovable descreve esse arranjo (a interface num host externo, o back-end no Cloud) e avisa que o uso do Cloud continua consumindo os créditos do seu workspace no Lovable. Mudar o back-end de lugar é outra migração, manual, e quem estava logado precisa entrar de novo.
• Chamadas a uma IA (Gemini, OpenAI): precisam de um servidor que guarde a chave. Colocar a chave no código do navegador expõe a chave a qualquer visitante.
• Formulários: num site estático, o formulário precisa de um serviço que receba os dados (o próprio back-end do projeto ou uma ferramenta de formulários). O arquivo HTML sozinho não envia e-mail.

Deu erro depois de publicar: o que pode ser?

O que aparece	Causa mais comum	O que fazer
Página em branco	A pasta dist foi enviada inteira, ou o site está numa subpasta	Deixe o index.html direto em public_html. Em subpasta, ajuste a opção base do Vite e gere o build de novo
Erro 404 ao atualizar uma página interna	Falta o .htaccess, ou ele foi salvo com outro nome	Confira o nome (com o ponto no começo) e as linhas do passo 4
Ainda aparece o site antigo ou a página do Lovable	DNS ainda em propagação, ou sobrou o registro A do Lovable	Espere algumas horas e confira os registros do domínio
“Não seguro” no navegador	O SSL ainda não foi emitido	Ative o certificado no painel depois que o domínio apontar para o servidor
Login não funciona	O novo domínio não está nas URLs de redirecionamento	Acrescente o endereço no provedor de login
As mudanças feitas no Lovable não aparecem	A hospedagem não recebe as alterações sozinha	Baixe o código de novo, gere o build e reenvie os arquivos

Quando a hospedagem comum não é o melhor caminho?

Publicar na própria hospedagem dá controle sobre o endereço e os arquivos, mas cobra tempo a cada mudança e não serve para todo projeto:

• Cada alteração vira um novo envio. No Lovable, publicar a versão nova é um clique. Na sua hospedagem, é refazer o build e subir os arquivos. Para quem muda o site toda semana, isso pesa.
• Se o endereço da plataforma basta, não precisa de nada disso. O Lovable publica num subdomínio lovable.app em todos os planos, e publicar pela janela Publish não gasta créditos, segundo a documentação (o app no ar e o back-end no Cloud consomem créditos conforme o uso). O plano pago só entra quando você quer o domínio próprio dentro do Lovable.
• Apps com servidor ficam de fora deste tutorial. TanStack Start, app do AI Studio com Gemini e qualquer projeto que precise de um processo Node.js ligado não funcionam só com os arquivos enviados.
• O código é responsabilidade sua. O suporte de uma hospedagem cuida do servidor, do painel, do DNS e do SSL. Corrigir um erro no código gerado pela IA não entra nesse suporte.

Por outro lado, se o seu site de IA é uma landing page ou um site institucional que muda pouco, a hospedagem própria faz sentido, e você pode hospedar vários na mesma conta. O guia de hospedagem para landing page aprofunda esse caso.

E na PW Host, como fica?

Na PW Host, o site estático do passo 3 vai para a pasta public_html pelo Gerenciador de Arquivos do DirectAdmin ou por FTP, o servidor LiteSpeed lê o .htaccess e o SSL é grátis. Dá para hospedar mais de um site na mesma conta, sem limite fixo de domínios, dentro do uso justo e dos limites de cada conta (até 5 núcleos de CPU e 3 GB de RAM). O plano é de pagamento único, sem mensalidade de hospedagem.

O que não está incluído: o domínio, a criação do site e a publicação feita por nós. O suporte atende servidor, painel, DNS, SSL, e-mail e acesso, mas não cria, programa nem corrige sites (Termos, item 10). Se você não quiser fazer o build e o envio, a publicação pode ser contratada à parte, sob orçamento, com a Agência Portal Web, marca da Digital DS (item 3.6 dos Termos e Políticas).

Perguntas frequentes

---

Fontes

• Lovable, “Deploying and hosting outside Lovable”: tipos de projeto, data de 13/05/2026, build, dist, regra de reescrita, variáveis VITE_ e back-end. Conferido em 02/10/2026.
• Lovable, “Publish your Lovable project” e “Launch your site on a custom domain”: publicação em lovable.app em todos os planos e sem gasto de créditos, domínio próprio nos planos pagos e registros A e TXT. Conferido em 02/10/2026.
• Anthropic, “Share artifacts”: link no endereço do Claude, conta exigida para abrir um artefato compartilhado e botão Publish dos artefatos antigos. “What are artifacts and how do I use them?”: artefatos antigos são os feitos num chat antes de 16/09/2026, com controles para ver, copiar e baixar o código. Conferido em 02/10/2026.
• Google AI for Developers, “Build apps in Google AI Studio” (atualizado em 20/08/2026) e “Develop full-stack apps in Google AI Studio”. Conferido em 02/10/2026.
• Vite, “Static Asset Handling”: a pasta public é copiada para a raiz da dist. Conferido em 02/10/2026.
• LiteSpeed, documentação de Rewrite: o motor de reescrita segue a especificação do Apache. Conferido em 02/10/2026.
• Registro.br, “Sobre domínios”: “Quanto custa registrar um domínio”, R$ 40 por ano. Conferido em 02/10/2026.
• PW Host, Termos e Políticas, versão 1.1 (Termos de Uso, itens 3.6 e 10). Conferido em 02/10/2026.

Texto da Equipe PW Host, escrito com apoio de IA e revisado pela equipe. Documentação das ferramentas conferida em 02/10/2026; os menus e as regras das plataformas de IA mudam com frequência.