Site não mostra as mudanças: os 4 caches que seguram a versão antiga

Primeiro: onde a versão antiga aparece?

A pergunta que resolve metade dos casos é quem ainda vê a versão velha:

O teste mais rápido é abrir a página numa janela anônima e no celular, fora do Wi-Fi. Se lá aparece a versão nova, o cache é seu. Se não aparece em lugar nenhum, o problema está no servidor.

No navegador: cache e service worker

O navegador guarda HTML, CSS e imagens pra abrir mais rápido. Se o servidor mandou o HTML com um Cache-Control longo, o navegador nem pergunta de novo por um tempo.

• Recarregar sem cache: Ctrl+Shift+R no Windows e no Linux, Cmd+Shift+R no Mac.
• Com o DevTools aberto (F12), na aba Network, marque "Disable cache" e recarregue. Enquanto o DevTools estiver aberto, nada vem do cache.
• Service worker. Sites com PWA ou modo offline guardam páginas num service worker, que ignora o recarregamento comum. No DevTools, abra Application › Service workers e clique em Unregister, depois recarregue.

Se só você via a versão antiga, acabou aqui. Os visitantes que já tinham aberto o site podem ver a versão velha pelo mesmo motivo, até o cache deles expirar. Pra evitar isso nas próximas vezes, sirva o HTML com Cache-Control: no-cache (o navegador guarda, mas confere com o servidor antes de usar) e deixe o cache longo só pros arquivos com hash no nome, como app.3f9a1c.js.

Na CDN e na hospedagem

Se ninguém vê a mudança, olhe os cabeçalhos da resposta:

curl -sI https://seusite.com.br/ | grep -iE "cache-control|age|cf-cache-status|x-vercel-cache|x-cache"

• cf-cache-status: HIT (Cloudflare), x-vercel-cache: HIT (Vercel) ou x-cache: Hit (CloudFront e outras) dizem que a resposta saiu do cache da CDN, não do servidor.
• age mostra há quantos segundos aquela cópia está guardada. Um número alto, junto com conteúdo velho, fecha o diagnóstico.

O que fazer em cada caso:

• Cloudflare: no painel, em Caching › Configuration, use Purge Cache. Dá pra limpar só as URLs que mudaram em vez do site inteiro.
• Vercel e Netlify: cada deploy publica uma versão nova do site, com cache próprio. Se a mudança não aparece, o mais comum é o deploy de produção não ter terminado, ter falhado no build ou ter ido só pra um preview. Confira no painel qual deploy está ligado ao domínio. Na Vercel, dá pra limpar o cache sem fazer deploy em CDN › Caches › Purge cache, dentro do projeto.
• WordPress: plugins de cache (WP Rocket, W3 Total Cache, LiteSpeed Cache) e o cache da própria hospedagem guardam páginas prontas. Limpe o cache do plugin e, se a hospedagem tiver um, o dela também.
• Mudou de hospedagem ou de DNS? Até a mudança propagar, parte das pessoas ainda cai no servidor antigo. Rode dig +short seusite.com.br e confira se o endereço é o da hospedagem nova.

No Google: título e descrição antigos

O Google não lê o seu site ao vivo. Ele mostra a versão que guardou na última vez que rastreou a página. Mudou o título, a descrição ou o texto? O resultado só muda depois do próximo rastreamento.

1. Confira se o Google consegue ver a versão nova. Na Inspeção de URL do Search Console, rode o teste ao vivo e abra "Ver página testada". Se ali ainda aparece o conteúdo antigo, o problema é de cache no servidor, não do Google.
2. Peça a indexação no mesmo lugar. O Google diz que o rastreamento pode levar de alguns dias a algumas semanas, e que pedir várias vezes pra mesma URL não acelera nada.
3. Muitas páginas mudaram? Atualize o <lastmod> delas no sitemap. É o sinal que o Google usa pra achar o que é novo. Mais sobre isso no guia de sitemap XML.

Um detalhe que confunde muita gente: mesmo depois do rastreamento, o Google pode não usar o seu <title> e a sua meta description. Ele monta o título do resultado a partir de várias fontes da página, como o <h1> e os links que apontam pra ela, e escolhe o trecho da descrição de acordo com a busca. Títulos curtos, específicos e iguais ao assunto da página são os que ele mais respeita.

E se a página nem aparece no Google, o problema é outro: veja como colocar o site no Google ou, se ela estava lá e sumiu, as causas de um site sumir do Google.

No WhatsApp, Facebook e LinkedIn

O card com imagem, título e descrição que aparece quando alguém compartilha um link vem das tags Open Graph (og:title, og:description, og:image). As redes guardam esse card por um tempo.

• Facebook e Instagram: o Depurador de compartilhamento (developers.facebook.com/tools/debug) mostra o que o robô leu e tem o botão pra coletar de novo.
• LinkedIn: o Post Inspector (linkedin.com/post-inspector) faz o mesmo.
• WhatsApp: não tem ferramenta pública. Uma saída comum é compartilhar a URL com um parâmetro novo, como ?v=2, que o WhatsApp trata como outro link.

Se a imagem nova não aparece em nenhuma rede, confira se o og:image usa o endereço completo, com https://, e se a imagem abre direto no navegador.

Checklist

1. A janela anônima mostra a versão nova? Se sim, era o cache do seu navegador.
2. O deploy de produção terminou e está ligado ao domínio certo.
3. O curl -sI não mostra HIT com um age alto. Se mostra, limpe o cache da CDN.
4. O HTML sai com Cache-Control: no-cache ou um tempo curto; cache longo só em arquivos com hash.
5. O teste ao vivo da Inspeção de URL mostra a versão nova, e a indexação foi pedida.
6. O <lastmod> do sitemap mudou nas páginas alteradas.

Uma mudança que não aparece é chata. Uma mudança que aparece e quebra algo pro Google, como um noindex ou um canonical trocado no mesmo deploy, é pior e ninguém vê. A varredura grátis da Varrida lê o site como o Googlebot e mostra o que ele enxerga agora.