Uma publicação ruim de site estático quase sempre começa pequena. Uma página fica em branco. O CSS não carrega. Uma imagem vira 404. Um PDF aponta para o arquivo errado. Uma landing page entra no ar com uma oferta antiga.
O problema cresce quando a equipe tenta consertar produção enquanto o link já está sendo aberto.
Para um site estático, o caminho mais seguro costuma ser: restaurar primeiro a última versão que funcionava, depois investigar a versão quebrada sem deixar visitantes presos nela.
Rollback é para impacto real no link público
Nem todo erro pede rollback. Se o problema é uma frase pequena ou um acento faltando, um novo upload corrigido pode resolver.
Rollback vira a primeira opção quando a versão pública atual está claramente pior que a anterior.
| Problema | Por que restaurar ajuda |
|---|---|
| Página em branco | Visitantes voltam a ver uma versão funcional enquanto você analisa o build. |
| CSS, imagens ou fontes ausentes | A versão anterior costuma ter caminhos de assets mais confiáveis. |
| Rotas quebradas | Deep links, QR codes e URLs de campanha podem voltar a funcionar rápido. |
| Texto de campanha errado | A oferta aprovada volta enquanto a nova versão é corrigida. |
| Export de IA incompleto | Placeholders, links inventados e seções inacabadas saem da versão ao vivo. |
| PDF ou download incorreto | O link público deixa de apontar para um arquivo ruim ou ausente. |
A regra é operacional: se a versão atual prejudica acesso, confiança, revisão de cliente ou conversão, restaure primeiro.
Por que sites estáticos aceitam bem restauração
Um site estático pode ser tratado como um conjunto completo de arquivos: HTML, CSS, JavaScript, imagens, fontes, PDFs e outros assets.
Isso permite publicar por versões, não editar uma pasta viva. Quando cada publicação sobrescreve arquivos no mesmo lugar, um erro pode misturar HTML antigo, JavaScript novo, imagens ausentes e cache de navegador. Com versões de deploy, cada publicação representa um estado completo.
| Camada | O que deve ficar preservado | Por que importa |
|---|---|---|
| Saída de build | Os arquivos exatos daquela versão | O site anterior não precisa ser reconstruído de memória. |
| Registro de deploy | Qual versão estava ativa e quando | A equipe pode escolher um estado verificado. |
| Mapeamento de domínio | Qual versão serve a URL pública | A recuperação pode ser troca de versão ativa. |
| Contexto | Quem publicou e o que mudou | A investigação começa depois de conter o problema. |
Cloudflare Pages descreve rollbacks como voltar um projeto para um deployment de produção anterior. Vercel usa Instant Rollback para apontar domínios de produção para um deployment anterior. Netlify permite publicar um deploy anterior como produção. A interface muda, mas o padrão é o mesmo: a versão anterior precisa continuar disponível como alvo publicável.
Evite reconstruir o site antigo no meio do incidente
Se rollback significa procurar um ZIP antigo, rodar build local, enviar tudo de novo e torcer para bater, isso é mais um redeploy de emergência do que uma restauração real.
Pode funcionar, mas cria risco no pior momento:
- O código antigo pode não corresponder ao build publicado.
- Dependências podem ter mudado.
- Variáveis e configurações de build podem não ser iguais.
- Alguém pode escolher a pasta errada.
- O novo upload pode criar outro estado quebrado.
O caminho mais limpo é manter deploys bem-sucedidos disponíveis e mudar qual versão está ativa.
Uma decisão curta, sem debate infinito
Rollback não deveria virar uma discussão filosófica. Use poucas perguntas.
| Pergunta | Se sim | Se não |
|---|---|---|
| O site ao vivo está quebrado para visitantes reais? | Restaure uma versão estável. | Corrigir para frente talvez baste. |
| É só um texto menor? | Considere enviar uma correção. | Continue avaliando impacto. |
| A versão anterior foi verificada? | Use como destino. | Procure o último estado realmente aprovado. |
| A mudança dependia de API ou dados externos? | Verifique compatibilidade. | A restauração estática tende a bastar. |
| Existe campanha, cliente, turma ou lançamento ativo? | Contenha o impacto público primeiro. | Você pode ter mais tempo para depurar. |
O objetivo não é provar que rollback sempre vence. É evitar que uma versão ruim continue pública enquanto todo mundo tenta adivinhar.
O que revisar logo depois
Rollback só termina quando a experiência pública volta a funcionar.
- Abra a página inicial em uma janela privada.
- Teste as rotas importantes e links profundos.
- Verifique CSS, JavaScript, imagens, fontes, PDFs e downloads.
- Teste domínio personalizado e URL de prévia, se ambos existirem.
- Confirme que HTTPS continua válido para o hostname.
- Veja visitas recentes ou logs, se disponíveis.
- Avise a equipe qual versão está ativa agora.
Se o problema apareceu junto de mudanças de domínio, revise DNS e SSL. Restaurar arquivos não corrige um CNAME errado nem um certificado ainda pendente. Para isso, use a consulta DNS e o verificador SSL.
O que rollback não resolve
Rollback restaura o estado da entrega estática. Ele não desfaz automaticamente tudo ao redor do site.
| Dependência | Limite da restauração |
|---|---|
| APIs externas | A versão anterior pode esperar uma resposta que já mudou. |
| Bancos de dados | Restaurar arquivos estáticos não desfaz migrações nem dados gravados. |
| CMS ou conteúdo externo | Um build antigo pode continuar lendo conteúdo novo. |
| Scripts de terceiros | Uma falha de fornecedor pode afetar versão antiga e nova. |
| DNS ou certificados | Configuração de domínio segue outro caminho. |
| Cache do navegador | Alguns visitantes podem manter assets por algum tempo. |
Essa fronteira precisa ficar clara. Rollback é forte para incidentes de frontend, rotas, assets e conteúdo publicado. Não substitui um plano de incidente para APIs, dados e serviços externos.
Upload pelo navegador, Git e CLI: a mesma ideia
O site pode chegar à produção por caminhos diferentes. A lógica de recuperação continua parecida.
Upload pelo navegador
É comum em pastas HTML, exports de IA, portfólios, PDFs, páginas pontuais e prévias de cliente. O risco é a versão anterior existir só no computador de alguém.
Deploys versionados ajudam porque o estado anterior fica no projeto, não apenas em uma pasta de downloads.
Publicação por Git
Git ajuda, mas um commit não é necessariamente o artefato entregue aos visitantes. Um rebuild posterior pode sair diferente se dependências, variáveis ou configurações mudaram.
Em sites estáticos, manter o deployment bem-sucedido também importa.
Deploy via CLI
CLI torna o processo mais repetível. Não o torna infalível. Um build válido ainda pode publicar rota quebrada, asset mal referenciado ou conteúdo que ninguém aprovou.
Como o DeployPages entra nesse modelo
O DeployPages publica versões estáticas em vez de obrigar você a editar uma pasta ao vivo.
Você pode começar com upload pelo navegador para obter o primeiro link público e continuar no mesmo projeto quando o site fica mais sério. Quando atualizações começam a importar, entram restaurar versão anterior, estatísticas, domínios personalizados, proteção por senha e deploy via CLI.
A ideia é simples: toda mudança importante deveria deixar um caminho de volta. Se uma nova publicação quebra a URL pública, a equipe não deveria reconstruir o site de ontem enquanto visitantes esperam.
Playbook mínimo para o próximo lançamento
| Etapa | Responsável | Pronto quando |
|---|---|---|
| Nomear a versão | Quem publica | A equipe sabe o que mudou. |
| Revisar a prévia | Revisor | Início, rotas, assets e mobile funcionam. |
| Manter versão anterior disponível | Dono do projeto | Existe um estado estável para restaurar. |
| Publicar | Quem publica | A URL pública serve a versão correta. |
| Observar primeiros sinais | Owner | Estatísticas, logs e testes manuais não mostram falhas óbvias. |
| Restaurar se necessário | Pessoa com permissão | A URL pública volta para um estado verificado. |
| Depurar depois | Builder | A versão quebrada é corrigida sem pressão pública. |
O playbook é simples de propósito. Isso ajuda quando uma página pública está quebrada.
Quando rollback deixa de ser opcional
Para uma prévia descartável, talvez não seja indispensável.
Ele fica importante quando:
- o site já usa domínio personalizado;
- cliente, recrutador, professor ou campanha já tem o link;
- mais de uma pessoa pode publicar;
- erro afeta reputação, receita, candidatura ou suporte;
- você trabalha com exports de IA ou arquivos recebidos de terceiros;
- cópias manuais em ZIP já não são confiáveis.
Nesse ponto, rollback não é luxo. É o que permite atualizar sem tratar cada publicação como um caminho sem volta.