O que significa não tocar em servidor

Criar uma landing page com Claude Code já é uma parte bem acelerada do trabalho. Você descreve a oferta, passa referências, pede a estrutura e deixa o agente criar HTML, CSS, JavaScript e imagens auxiliares quando fizer sentido. O problema aparece quando a página pronta precisa sair do ambiente local e virar uma URL pública.

“Sem tocar em servidor” não quer dizer ignorar validação, domínio, links ou arquivos. Quer dizer que você não precisa abrir uma máquina, configurar Nginx, criar bucket manualmente ou montar um pipeline de deploy só para colocar uma landing estática no ar.

Nesse fluxo, Claude Code cria os arquivos diretamente no workspace do Site pelas tools MCP. O resultado correto é uma URL que você consegue abrir, revisar e compartilhar.

Antes de pedir para o Claude Code criar

Uma landing page fica melhor quando o agente recebe decisões de negócio, não só um pedido genérico para “fazer uma página bonita”. Antes de começar, defina:

Decisão Exemplo útil
Oferta principal “Agendamento de diagnóstico para clínicas”
Público “Donos de clínica com equipe pequena”
Ação esperada “Clicar em WhatsApp” ou “preencher formulário”
Provas e restrições “Sem números inventados, usar apenas estes cases”
Saída técnica “index.html, CSS e assets estáticos”
Critério para publicar “Build sem erro e home carregando pela URL final”

Se o MCP ainda não estiver pronto no Claude Code, configure primeiro pela documentação de configuração ou pelo guia de Claude Code. Isso evita descobrir no fim do trabalho que ainda falta login.

Prompt para gerar a landing

Comece com um pedido fechado o suficiente para o agente construir a primeira versão sem inventar o contexto:

Crie uma landing page estática para a oferta abaixo.


Oferta: [descreva a oferta]
Público: [descreva o público]
Ação principal: [CTA]
Tom: direto, confiável e brasileiro


Regras:
- Gere uma versão estática, publicável como HTML/CSS/JS.
- Use index.html como página principal.
- Não invente estatísticas, depoimentos ou logos.
- Se precisar de copy que eu não forneci, marque como sugestão editável.
- Ao final, diga qual pasta deve ser publicada.

Esse prompt separa criação de publicação. Primeiro você quer uma página coerente, com hierarquia, responsividade e arquivos organizados. Só depois faz sentido pedir o publish.

Prepare a pasta publicável

Quando a primeira versão estiver pronta, peça para o Claude Code conferir a saída. Em projetos simples, a pasta pode ser a própria raiz dos arquivos estáticos. Em frameworks, normalmente será dist, build ou outro diretório gerado pelo comando de build.

Use um pedido explícito:

Revise a saída publicável da landing.
Confirme onde está o index.html final.
Confira se CSS, JS, imagens e fontes usados pela página estão dentro da mesma pasta de publicação.
Não publique ainda.

Essa etapa reduz o erro clássico de subir só o HTML e deixar estilos ou imagens apontando para arquivos que existiam apenas no ambiente local.

Publique pelo Site no Ar

Com a pasta pronta, o pedido de publicação pode ser curto:

Use o MCP do Site no Ar para publicar a landing page.
Pasta publicável: ./dist
Slug desejado: campanha-diagnostico
Use index.html como página inicial.
Depois acompanhe o deploy e me entregue a URL final.

Troque ./dist pelo caminho real. O contrato de publicação é simples: index.html vira a home, outros arquivos .html viram rotas e CSS, JavaScript, imagens e fontes permanecem como assets no caminho enviado.

O agente usa as file tools do MCP para ler e alterar o repositório do Site. Depois publica o diretório public/ com deploy e acompanha deploy_status até o resultado final.

Verifique antes de enviar para alguém

Publicar não encerra o trabalho. Peça uma verificação objetiva:

  • a URL final abre fora do ambiente local;
  • a home carrega a partir de index.html;
  • imagens, fontes e CSS aparecem corretamente;
  • CTAs apontam para destinos reais;
  • links internos não quebram;
  • o slug publicado é o slug pedido ou uma alternativa aceita por você.

Se alguma etapa falhar, o retorno útil é o próximo passo: autenticar de novo, escolher outro slug, reenviar um asset ausente ou corrigir a build. O ganho do Site no Ar é transformar isso em uma conversa verificável, não esconder o estado do deploy.

Quando a landing deixa de ser só estática

Landing page costuma começar estática, mas nem toda landing termina assim. Formulários com backend, autenticação, pagamento, banco de dados ou APIs próprias podem exigir outro desenho. Ainda assim, vale publicar a primeira versão estática quando o objetivo é validar mensagem, compartilhar uma oferta ou coletar feedback visual.

Para páginas de campanha, páginas de espera, portfolios, demos e validação de copy, esse fluxo costuma ser suficiente: Claude Code cria os arquivos, Site no Ar publica, você revisa a URL.

O próximo passo

Se você nunca publicou com esse fluxo, comece pelo guia Como publicar um site feito no Claude Code em segundos. Se já configurou o MCP, use este artigo como checklist: briefing claro, saída estática, pasta publicável, slug, deploy e verificação.

O ponto é manter a energia do trabalho no produto e na mensagem da landing. Servidor, painel de hospedagem e upload manual não precisam virar uma tarefa paralela quando o agente já está dentro do projeto.