Por que meu site ainda mostra a versão antiga?

Seu site está bem. A cópia que está na frente dele é velha.

Publicar grava uma versão nova da página no seu origin, ou seja, o servidor ou o bucket de armazenamento de onde a sua hospedagem realmente lê. Nada nesse passo garante que os seus visitantes estejam falando com o seu origin. Entre os dois existem o navegador, normalmente uma rede de distribuição de conteúdo, às vezes um service worker que o seu framework instalou e, de vez em quando, um proxy na rede do próprio visitante. Cada um guarda uma cópia e uma regra sobre por quanto tempo confiar nela, e cada um vai responder a uma requisição sem perguntar a ninguém.

A assinatura desse problema é a inconsistência. Você vê a página nova e o seu cliente não. Duas pessoas recebem versões diferentes do mesmo endereço. Uma hora depois se resolve sozinho, sem nenhum deploy. Vale aprender esse padrão, porque um lançamento realmente quebrado está quebrado para todo mundo ao mesmo tempo: se para alguns está tudo bem, pare de ler o log de build e descubra quem está respondendo à requisição. A regra que existe por baixo da primeira é a que surpreende: muitos caches não apenas guardam uma cópia até ela expirar, eles continuam servindo a cópia expirada enquanto buscam uma nova por trás. Expirada não quer dizer fora de uso, e é assim que uma página sobrevive à própria validade com uma margem enorme.

Descubra a camada antes de consertar nada

Cada passo abaixo elimina um cache, na ordem que custa menos. Desça a lista e pare no primeiro que mostrar a página nova: essa é a sua resposta, e a solução é uma purga naquela camada, não outro deploy.

1. Abra em uma janela privada. Se a versão nova aparecer ali, a cópia velha só existia no seu próprio navegador e nenhum visitante foi afetado. Recarregue forçado na janela normal e está resolvido. É o resultado mais comum e o passo mais pulado, e é por isso que o susto costuma durar mais que o problema.
2. Acrescente um parâmetro sem sentido. Carregue o mesmo endereço com algo como ?x=1 no final. Quase todos os caches compartilhados tratam isso como outra URL e vão buscá-la no origin, então uma página nova aqui significa que o seu origin está correto e que algo entre você e ele continua servindo a cópia velha no endereço limpo.
3. Abra em outra rede. Um celular no dados móveis em vez do wi-fi do escritório. Uma rede de distribuição de conteúdo guarda cópias separadas em localidades separadas, então isso separa uma borda desatualizada de algo que todos os visitantes estão recebendo, e é a única versão do teste que reflete o que um estranho realmente vê.
4. Pergunte direto ao origin. Busque a página pelo painel da sua hospedagem, por uma prévia no servidor ou por uma requisição dirigida ao origin e não ao endereço público. Se o origin está certo e a URL pública está errada, o problema vive inteiramente na entrega, e nada no seu código ou no seu build vai mudar isso.

Quando souber a camada, purgue ou invalide ali e repita o terceiro passo a partir de uma rede que você não controla. Confirmar a correção da sua própria máquina é como as pessoas acabam certas de que uma purga funcionou quando ela não funcionou.

A versão disso que nos custou uma hora

Hospedamos páginas dos nossos próprios clientes, então esse problema é nosso e não só de quem nos lê. Em 11 de setembro de 2026 encontramos uma página que tínhamos tirado do ar e que continuava sendo servida a qualquer pessoa que a abrisse, cinquenta e dois minutos depois da remoção. Tudo o que podíamos ver do nosso lado estava correto: o arquivo já não estava no armazenamento e os nossos próprios registros diziam que a página estava despublicada. A rede de distribuição de conteúdo que ficava na frente estava configurada para continuar respondendo com a última cópia boa por até um dia enquanto revalidava por trás, então apagado descrevia o nosso armazenamento e não dizia nada sobre o que um visitante recebia. Corrigimos em dois lugares de propósito: na configuração da rede, para não servir cópias expiradas de jeito nenhum, e nas próprias instruções de cache da página, de modo que o limite não dependa mais de um ajuste que um backend reconstruído restauraria silenciosamente para o padrão.

A regra que tiramos disso é a parte transferível: publicado, atualizado e apagado são afirmações sobre o seu origin. O que um visitante recebe é um fato separado, e a única forma honesta de descobrir é buscar a página como um estranho faria. A mesma camada também mudou o que conseguíamos medir. As visualizações nas páginas que hospedamos são registradas como um piso e não como um total, porque uma requisição respondida na borda nunca chega ao origin que faz a contagem, e enquanto o serviço de cópias expiradas esteve ativo, as requisições de atualização de cache da nossa própria rede eram a maior parte do que aquele contador continha, até que as excluímos pelo nome. Um cache não muda apenas o que as pessoas veem. Muda o que você consegue provar sobre o que elas viram.

Mudou também como escrevemos as duas operações. Publicar envia o arquivo primeiro e registra depois, porque a ordem inversa registra uma página no ar enquanto nada está sendo servido. Despublicar apaga o arquivo primeiro e marca o registro depois, porque a ordem inversa registra uma página como removida enquanto ela continua de pé. Quando a segunda metade falha, o estado que reportamos fica errado na direção em que é seguro errar. Perguntar qual falha você preferiria ter é a maior parte do que significa cuidar bem de um site, e é a mesma disciplina que construímos no AgentCeres, o AI Growth Officer em agentceres.com: um time de especialistas redige as páginas, as publicações e o contato, e o trabalho que sai para fora espera por padrão a aprovação de uma pessoa. Se você acabou de publicar um site pela primeira vez, as verificações de devo usar IA para criar meu site? são a outra metade desta página.