Republicar um site atualizado com agente de IA deveria preservar o endereço que já está em anúncios, mensagens, favoritos e materiais comerciais. O agente prepara a nova versão, envia o pacote ao Site correto, acompanha o deploy e verifica a URL pública. Você não precisa criar outro Site nem aceitar um slug diferente para cada correção.

Essa continuidade exige um contrato simples: identificar o destino pelo ID do Site, reconstruir o pacote completo e tratar a republicação como uma nova versão do mesmo conteúdo. Pedir apenas “atualize a landing” sem informar destino, fonte e critérios de aprovação abre espaço para publicar o build errado ou criar uma cópia.

Neste guia, você vai organizar um fluxo seguro para alterações de copy, imagens, páginas e assets sem perder a URL existente.

O que muda — e o que deve permanecer igual

Uma republicação combina mudança de conteúdo com continuidade operacional.

Pode mudar:

  • HTML, CSS, JavaScript, imagens e fontes;
  • páginas e rotas do pacote;
  • copy, metadados e CTAs aprovados;
  • estrutura visual e componentes;
  • arquivos antigos que deixaram de fazer parte da versão.

Deve permanecer estável, salvo instrução explícita:

  • o Site de destino;
  • o slug e a URL pública;
  • os Custom Hostnames ligados ao Site;
  • a conta responsável;
  • o escopo autorizado da publicação.

O slug ajuda pessoas a reconhecer o endereço. Para executar operações, o agente usa o ID retornado ao criar ou listar Sites. Guarde esse identificador no handoff do projeto. Dois Sites podem ter nomes parecidos, e confiar apenas na descrição humana aumenta o risco de atualizar o destino errado.

Antes de automatizar, registre o destino

Mantenha uma ficha curta por Site:

Campo Exemplo
projeto campanha de lançamento
Site ID identificador retornado pela plataforma
slug lancamento-produto
URL endereço público atual
fonte repositório e branch autorizados
saída dist
responsável marketing de produto
última aprovação versão de copy e data

Não coloque credenciais, tokens ou segredos nessa ficha. Ela serve para resolver identidade, fonte e responsabilidade, não para transportar acesso.

Se o destino ainda não estiver documentado, peça ao agente para listar os Sites disponíveis e mostrar ID, slug e URL antes de publicar. Ele deve parar quando houver mais de uma opção plausível.

O fluxo seguro de republicação

Uma republicação confiável tem sete etapas observáveis.

1. Confirmar a alteração aprovada

Comece pela diferença esperada. “Atualizar a campanha” é amplo demais. Prefira uma lista como:

  • trocar a headline pela versão aprovada;
  • atualizar a imagem principal;
  • manter preço, formulário e links atuais;
  • remover a rota antiga /evento;
  • preservar analytics e domínio próprio.

O agente pode mostrar o diff dos arquivos ou um resumo por página. Mudanças de oferta, preço, consentimento ou destino de leads continuam sendo decisões humanas.

2. Produzir a saída atual

O agente deve partir da fonte autorizada, executar o build necessário e localizar a saída estática. O nome pode ser dist, build, out ou outro diretório definido pelo projeto.

Antes de editar, confirme:

  • index.html existe na raiz;
  • todos os assets referenciados estão presentes;
  • caminhos funcionam fora do ambiente local;
  • não há .env, código-fonte desnecessário ou segredos;
  • o conteúdo corresponde à revisão aprovada;
  • o projeto não depende de servidor ausente no pacote.

Uma pasta antiga com data recente não é prova de que o build atual foi gerado. O processo precisa ligar fonte, comando e artefato.

3. Comparar com o Site correto

Antes de enviar, peça ao agente para consultar o Site pelo ID e repetir slug e URL. Essa confirmação reduz o erro mais caro do processo: uma versão tecnicamente correta publicada no cliente ou campanha errados.

Também vale observar as páginas e os assets atuais. Se a nova versão removeu arquivos, essa diferença deve ser intencional. Não preserve conteúdo obsoleto por acidente, mas não apague rotas porque elas não apareceram na tarefa de copy.

4. Atualizar os arquivos do Site

O contrato de Publicação mantém o conteúdo estático no workspace git do Site. Use list_files e read_file para entender o estado atual; depois aplique apenas as mudanças necessárias com write_file, edit_file ou delete_file.

Para republicar um Site multipágina, preserve os arquivos que continuam válidos e remova somente o que saiu do escopo. A página inicial permanece em public/index.html.

Exemplo correto:

index.html
produto.html
obrigado.html
assets/styles.css
assets/app.js
assets/hero.webp

O diretório public/ é a descrição concreta do que deve ficar no ar. Arquivos que precisam ser removidos merecem uma ação explícita; public/index.html não pode ser removido, apenas substituído por uma nova versão.

5. Iniciar o deploy versionado

Depois de salvar os arquivos, o agente chama deploy e guarda o identificador da operação. Em seguida usa deploy_status até chegar a um estado final.

O passo a passo de conexão está em Configuração.

6. Acompanhar até o estado final

“Arquivos salvos” ainda não significa “site atualizado”. O agente deve acompanhar o deploy até um estado final.

O fluxo passa por preparação, envio da versão, prontidão para ativação e ativação. No fim, o resultado é sucesso ou uma falha que precisa ser preservada no relatório. A versão pública só deve ser anunciada depois do sucesso.

Esse modelo reduz a janela de inconsistência: o novo conteúdo é preparado como uma versão antes de assumir o lugar da versão ativa. O artigo sobre os bastidores da publicação por agente explica essa transição em mais detalhes.

7. Abrir a URL e provar a atualização

Verifique a URL real, não apenas o retorno da operação. Confira:

  • headline ou elemento que identifica a nova versão;
  • páginas e assets afetados;
  • CTA e destino do formulário;
  • links internos;
  • responsividade básica;
  • título e descrição;
  • ausência de placeholders;
  • domínio próprio, quando fizer parte do escopo.

Em mudanças críticas, registre uma evidência específica. “Página abriu” é insuficiente quando a tarefa era corrigir preço, formulário ou rota.

Um prompt pronto para republicar

Adapte este pedido ao projeto:

Use o MCP do Site no Ar para republicar a versão aprovada deste projeto.


Destino:
- Site ID: [id registrado]
- slug esperado: [slug]
- URL esperada: [url]


Fonte e pacote:
- use a branch atual autorizada;
- gere novamente a saída estática;
- confirme index.html na raiz;
- não envie código-fonte, dependências, .env ou segredos;
- prepare um pacote completo, incluindo os assets atuais.


Antes do deploy, mostre o Site encontrado, os arquivos alterados e os checks.
Não crie outro Site, não troque o slug e não altere Custom Hostnames.
Pare se o destino, o build ou a remoção de alguma rota estiverem ambíguos.


Depois de salvar os arquivos, acompanhe o deploy até o estado final. Abra a URL e
verifique [headline], [CTA], [rotas] e [assets]. No handoff, informe o
deploy, a URL preservada, os checks e qualquer pendência.

Esse prompt separa autorização de execução. O agente recebe liberdade para concluir o fluxo técnico, mas não para escolher outro destino ou ampliar a mudança.

Republicação automática não é publicação sem revisão

Existem atualizações que podem seguir um contrato previamente aprovado, como correções de conteúdo já revisadas ou uma troca programada de banner. Outras exigem checkpoint humano:

  • mudança de preço ou condição comercial;
  • nova promessa de resultado;
  • inclusão de depoimento ou marca de cliente;
  • alteração de formulário e tratamento de dados;
  • remoção de página ainda divulgada;
  • troca de domínio ou destino;
  • publicação em conta de outro cliente.

Automação responsável define quando continuar e quando parar. Ela não tenta transformar uma decisão de marketing em detalhe de infraestrutura.

Como evitar conteúdo antigo no ar

Quando a URL ainda mostra a versão anterior, investigue uma variável por vez:

  1. confirme que a fonte autorizada contém a mudança;
  2. gere novamente o build;
  3. inspecione o arquivo dentro do pacote;
  4. confirme Site ID, slug e URL;
  5. confira o estado final do deploy;
  6. abra a URL pública em uma nova verificação;
  7. compare o elemento esperado com a resposta real.

Não crie outro slug para “destravar”. Isso pode esconder a causa e dividir o tráfego entre endereços.

O handoff mínimo de cada atualização

Peça uma resposta final com:

  • Site ID, slug e URL;
  • fonte e pasta publicável;
  • resumo das mudanças;
  • identificador e estado final do deploy;
  • rotas e elementos verificados;
  • arquivos removidos, se houver;
  • decisões que ficaram pendentes.

Esse registro permite que outra pessoa ou outro agente continue o trabalho sem adivinhar qual versão está ativa.

Atualize o conteúdo, preserve a referência

Republicar bem significa trocar a versão ativa sem perder o endereço que o público já conhece. O agente reduz a sequência manual de build, upload, espera e conferência, mas o ganho real vem da continuidade: Site identificado, pacote reproduzível, deploy acompanhado e URL testada.

Comece com uma alteração pequena e verificável. Conecte o agente pela Configuração, escolha um Site existente e peça uma republicação com uma evidência concreta. Depois que destino, checks e handoff estiverem estáveis, o mesmo contrato pode sustentar atualizações frequentes sem multiplicar URLs nem esconder o que mudou.