Cache Magento 2: alterações não aparecem? Descubra qual camada limpar

O cache Magento 2 pode fazer uma alteração parecer ignorada mesmo quando ela foi salva ou publicada corretamente. Preço antigo, bloco desatualizado, CSS sem mudança e configuração que não entra em vigor são sintomas parecidos, mas podem envolver camadas diferentes: cache da aplicação, Varnish, CDN, navegador, arquivos estáticos, OPcache ou dados armazenados em Redis.

Limpar tudo indiscriminadamente pode causar lentidão temporária e ainda não resolver a causa. O caminho mais eficiente é identificar qual conteúdo está desatualizado, onde ele aparece e qual camada participa da entrega.

Antes de limpar o cache Magento 2, delimite o problema

Comece confirmando o alcance da inconsistência. Faça o teste em uma janela anônima, em outro navegador e, se possível, em uma conexão diferente. Compare também a página pública com o painel administrativo.

• Somente seu navegador mostra conteúdo antigo: a causa pode estar no cache local, service worker ou extensão do navegador.
• Todos os visitantes veem a versão anterior: investigue cache do Magento, Varnish, CDN e conteúdo estático.
• Apenas uma categoria ou produto está desatualizado: verifique indexadores, regras de preço, estoque e invalidação de página.
• A alteração aparece no Admin, mas não na loja: confirme escopo de website, loja e visão de loja antes de atribuir o problema ao cache.
• O comportamento muda entre servidores: pode existir deploy incompleto, arquivos diferentes entre nós ou cache não compartilhado.

Quando o problema é especificamente um item que não aparece no catálogo, use também o checklist de produto que não aparece no Magento 2. Cache e indexação são processos relacionados, mas não são equivalentes.

As 7 camadas que podem manter conteúdo antigo

1. Cache interno da aplicação

O Magento mantém tipos de cache para configurações, layouts, blocos HTML, traduções, coleções e outros dados. Para conferir o estado de cada tipo, execute o comando pelo usuário correto da aplicação:

php bin/magento cache:status

Se você alterou uma configuração ou um bloco, prefira limpar somente os tipos relacionados. Para listar os tipos disponíveis:

php bin/magento cache:clean --help

Uma limpeza geral do conteúdo gerenciado pelo Magento pode ser feita com:

php bin/magento cache:clean

cache:clean remove entradas dos tipos habilitados sem necessariamente apagar todo o armazenamento utilizado por outras aplicações. Já cache:flush esvazia o backend de cache. Em ambientes compartilhados, isso pode afetar dados além do necessário; portanto, não deve ser o primeiro teste.

2. Full Page Cache e Varnish

Quando páginas inteiras continuam antigas, verifique se o Full Page Cache está armazenado internamente ou em um proxy como o Varnish. Uma alteração pode ter sido salva no banco, mas a resposta pública ainda estar sendo servida pelo cache de página.

Compare os cabeçalhos HTTP antes e depois da limpeza, procurando indicadores de idade, cache hit ou passagem pelo proxy:

curl -I https://www.exemplo.com.br/pagina-testada

Não desative o Varnish permanentemente apenas para contornar a inconsistência. Primeiro confirme se a invalidação chega ao proxy, se os hosts configurados estão corretos e se todos os nós usam a mesma política. Em lojas lentas, o cache pode estar mascarando outro gargalo; veja como diagnosticar a lentidão do Magento 2 antes de alterar a infraestrutura.

3. CDN ou proxy externo

Mesmo após limpar Magento e Varnish, uma CDN pode continuar entregando HTML, imagens, JavaScript ou CSS armazenados. Verifique a política de expiração e faça uma invalidação específica da URL afetada quando o serviço permitir.

Evite limpar toda a CDN por padrão. Uma purga global aumenta o volume de requisições na origem e pode piorar o tempo de resposta até o cache ser reconstruído. Também confirme se o domínio testado aponta para o ambiente correto; é comum validar uma alteração em staging e abrir, sem perceber, a URL de produção.

4. Cache do navegador

Se apenas um computador mantém a versão anterior, abra uma janela anônima, recarregue a página sem usar o cache e confira a aba Network das ferramentas do navegador. Observe o código HTTP, a URL efetivamente requisitada e se o recurso foi carregado da memória ou do disco.

Parâmetros de versionamento dos arquivos estáticos ajudam o navegador a buscar uma nova versão após o deploy. Se o HTML aponta para o arquivo novo, mas a página continua com aparência antiga, procure erros de carregamento e conflitos de JavaScript antes de repetir limpezas no servidor.

5. Conteúdo estático do tema

Mudanças em CSS, JavaScript, fontes ou arquivos do tema podem exigir uma nova publicação de conteúdo estático, dependendo do modo da aplicação e do processo de deploy. Em produção, a publicação deve fazer parte de uma implantação planejada:

php bin/magento setup:static-content:deploy -f pt_BR

Ajuste os idiomas ao projeto. Não apague diretórios inteiros diretamente em produção sem conhecer a estratégia de deploy, permissões e uso de múltiplos servidores. Uma remoção incompleta pode deixar páginas sem estilo ou nós entregando versões diferentes do mesmo arquivo.

6. PHP OPcache e processos persistentes

Uma alteração em código PHP pode não entrar em vigor se processos persistentes continuarem usando bytecode antigo. Nesse caso, limpar apenas o cache do Magento não resolve. Verifique a configuração do OPcache e o procedimento de recarga do PHP-FPM adotado pela infraestrutura.

Reiniciar serviços durante horário de pico sem coordenação pode interromper requisições. Prefira uma recarga controlada, valide a sintaxe da configuração e acompanhe logs e disponibilidade. Se o deploy resultar em falha geral, consulte o roteiro para investigar erro 500 no Magento 2.

7. Redis, Valkey e separação de bancos

Redis ou Valkey podem armazenar cache, sessões e Full Page Cache. Limpar o banco ou a instância errada pode derrubar sessões de clientes e carrinhos sem atualizar o conteúdo esperado.

Antes de usar comandos diretamente no serviço, examine o app/etc/env.php e identifique host, porta, banco lógico, prefixos e finalidade de cada conexão. Cache e sessões devem ser tratados separadamente. Em uma migração de backend, siga um plano específico para não interromper carrinhos e logins, como explicado no guia de migração de Redis para Valkey.

Uma ordem segura para encontrar a camada desatualizada

1. Registre a URL, o conteúdo esperado e o horário exato da alteração.
2. Confirme o escopo correto no Admin e se a mudança realmente foi salva.
3. Teste em janela anônima e compare os cabeçalhos HTTP.
4. Limpe somente o tipo de cache Magento relacionado à alteração.
5. Valide Full Page Cache, Varnish e CDN, nessa ordem.
6. Para tema ou código, confira o deploy de arquivos estáticos e o OPcache.
7. Se houver múltiplos servidores, teste cada nó e compare artefatos e configurações.
8. Consulte os logs antes de executar uma segunda mudança.

Depois de cada ação, teste novamente a mesma URL. Alterar várias camadas de uma vez impede descobrir qual delas causou o problema e dificulta evitar a reincidência.

O que não fazer durante o diagnóstico

• Não executar cache:flush repetidamente sem identificar o backend utilizado.
• Não apagar sessões para tentar corrigir preço, layout ou configuração.
• Não remover diretórios gerados sem um processo de publicação e reversão.
• Não desativar todos os caches em produção por tempo indeterminado.
• Não reindexar o catálogo inteiro quando o sintoma envolve apenas CSS ou JavaScript.
• Não reiniciar banco, Redis, Varnish e PHP ao mesmo tempo.

Se a alteração reaparece e volta a sumir, investigue automações. Deploys, importações, sincronizações com ERP, tarefas agendadas e configurações gerenciadas por infraestrutura podem restaurar arquivos ou dados antigos.

Conclusão

Resolver um problema de cache Magento 2 não significa apagar tudo até a página mudar. É necessário separar cache da aplicação, página completa, CDN, navegador, conteúdo estático, OPcache e armazenamento de dados. Essa abordagem reduz impacto na loja e revela onde a invalidação ou o deploy precisa ser corrigido.

Se a loja continua entregando versões diferentes ou a limpeza afeta sessões e performance, uma análise técnica do ambiente pode localizar a camada responsável e definir um procedimento seguro de manutenção. A equipe do SuporteMagento.com.br pode ajudar no diagnóstico pelo canal de atendimento.

Perguntas frequentes sobre cache Magento 2

Qual é a diferença entre cache:clean e cache:flush?

cache:clean limpa os tipos de cache gerenciados pelo Magento. cache:flush esvazia o armazenamento de cache utilizado pela aplicação e pode atingir outros dados quando o backend é compartilhado. Por isso, a limpeza deve ser priorizada.

Limpar o cache do Magento apaga carrinhos?

Normalmente, limpar apenas os tipos de cache da aplicação não deve apagar carrinhos. O risco aumenta quando sessões compartilham a mesma instância ou banco de Redis ou Valkey e é feito um flush direto no serviço.

Por que o CSS continua antigo depois de limpar o cache?

O arquivo pode estar armazenado no navegador ou na CDN, ou o conteúdo estático pode não ter sido publicado no deploy. Verifique a URL do recurso, seu código HTTP e o versionamento antes de apagar diretórios.

É preciso reindexar depois de toda alteração?

Não. Reindexação é relevante para dados processados pelos indexadores, como partes do catálogo e preços. Mudanças em layout, CSS, JavaScript e diversas configurações exigem outros procedimentos.