Erro 404 no Magento 2 nem sempre significa que uma página foi excluída. A resposta pode surgir por uma URL incorreta, conflito de rewrite, escopo de loja, configuração do servidor web, arquivo estático ausente ou deploy incompleto. Limpar todos os caches e recriar redirecionamentos sem diagnóstico pode esconder a pista principal e ainda produzir novos conflitos.
Antes de modificar a loja, registre a URL completa, o horário, a área afetada e como a página foi acessada. Os oito testes abaixo ajudam a identificar qual camada está gerando o 404 e qual correção faz sentido.
Erro 404 no Magento 2: delimite o sintoma primeiro
Comece verificando se o erro ocorre em uma única URL ou em um grupo de páginas. Teste a página inicial, um produto conhecido, uma categoria, o carrinho, o Admin e um arquivo estático. Também repita o acesso em janela anônima para reduzir a influência de sessão e cache do navegador.
Os resultados apontam para caminhos diferentes:
- Apenas um produto falha: investigue URL key, rewrite, associação ao site e status do item.
- Produtos e categorias falham: verifique rewrites, configuração de base URL e regras do servidor web.
- Somente o Admin retorna 404: confirme o caminho administrativo, o virtual host e eventuais regras de proxy.
- CSS, JavaScript ou imagens retornam 404: investigue conteúdo estático, permissões, CDN e processo de deploy.
- Toda a loja falha: valide o document root, as regras de reescrita e se a requisição está chegando ao ambiente correto.
Se o produto também não aparece em categorias ou na busca, siga o roteiro de diagnóstico para quando um produto não aparece no Magento 2. A ausência no catálogo pode envolver estoque, visibilidade ou indexação, e não necessariamente um defeito de URL.
1. Descubra quem está produzindo a resposta 404
O navegador mostra o código final, mas não revela imediatamente se ele foi enviado pelo Magento, Nginx, Apache, CDN, proxy ou balanceador. Consulte os cabeçalhos e o conteúdo da resposta:
curl -I https://loja.exemplo.com/pagina-testada
curl -sS -D - https://loja.exemplo.com/pagina-testada -o /tmp/resposta-404.htmlCompare a aparência e os cabeçalhos do erro com uma rota inexistente criada apenas para o teste. Uma página 404 renderizada com o tema da loja sugere que a requisição chegou à aplicação. Uma resposta genérica do servidor, proxy ou CDN indica que a falha pode ocorrer antes do Magento.
Não use somente o texto visual como prova. Temas personalizados podem alterar a página de erro, enquanto proxies podem manter uma resposta em cache.
2. Confirme a URL, o domínio e o código da loja
Copie a URL diretamente da barra do navegador e confira protocolo, domínio, subdiretório, sufixo e eventuais parâmetros. Em instalações com múltiplos sites, uma URL válida em uma visão pode não existir em outra.
Verifique também se o endereço foi gerado pelo próprio Magento, por uma integração, por um menu cadastrado manualmente ou por uma campanha externa. Links antigos podem conservar um sufixo removido, uma URL key anterior ou o código de uma loja que deixou de fazer parte do endereço.
Se o domínio aponta para mais de um ambiente, confirme que a requisição chega ao servidor esperado. Um DNS, proxy ou virtual host direcionado para a instalação errada pode produzir um 404 perfeitamente válido, porém emitido pela loja ou release incorreto.
3. Verifique o URL rewrite sem editar diretamente o banco
Para produtos, categorias e páginas que tiveram seus identificadores alterados, confira os registros de URL rewrite. No Admin, valide a URL key atual, o escopo e os redirecionamentos existentes. Procure conflitos em que o mesmo caminho foi reservado por outra entidade ou por um rewrite personalizado.
Evite começar apagando registros diretamente da tabela url_rewrite. Além do risco de remover rotas válidas, uma alteração manual pode ser recriada posteriormente ou deixar referências inconsistentes. Primeiro registre o caminho solicitado, o destino esperado, o tipo da entidade e a visão de loja.
Quando houver redirecionamento, acompanhe toda a cadeia:
curl -sS -I -L https://loja.exemplo.com/url-antigaUma URL pode responder inicialmente com 301 ou 302 e terminar em um 404. Nesse caso, a origem do problema está no destino final ou na cadeia de redirecionamentos, não necessariamente no primeiro endereço.
4. Confirme status, escopo e existência do conteúdo
Uma rota pode estar correta enquanto a entidade correspondente não está disponível naquele site. Em produtos, confira status, visibilidade, associação ao website e configuração por visão de loja. Em categorias, valide se estão ativas e vinculadas à árvore correta. Para páginas CMS, confira identificador, status e seleção das lojas.
Compare o identificador solicitado com a entidade no Admin sem alterar vários campos simultaneamente. Se a URL funcionava antes, consulte o histórico de deploy, importações e mudanças editoriais próximas ao primeiro registro da falha.
5. Teste as regras do servidor web e o document root
Quando várias rotas amigáveis retornam 404, mas arquivos específicos ainda são acessíveis, revise a configuração de reescrita do servidor web. O document root deve apontar para o diretório previsto pela arquitetura da instalação, e as regras precisam encaminhar as requisições adequadamente.
Compare a configuração em uso com a do ambiente de homologação, mas não copie arquivos cegamente. Verifique virtual host, blocos de localização, arquivos de configuração incluídos e alterações recentes. Após qualquer ajuste, valide a sintaxe antes de recarregar o serviço.
Se a resposta mudar para indisponibilidade geral, trate o novo sintoma separadamente. O guia sobre erro 503 no Magento 2 ajuda a distinguir manutenção, proxy, PHP-FPM e aplicação sem apagar evidências.
6. Inspecione logs no horário exato da falha
Repita uma única requisição controlada e consulte os logs imediatamente. Avalie os registros do servidor web, PHP, proxy e Magento. Em vez de procurar apenas pela expressão “404”, pesquise o caminho solicitado, o horário e um identificador de requisição, caso a infraestrutura utilize esse recurso.
Também confira os arquivos em var/log e relatórios em var/report, respeitando a configuração do ambiente. A ausência de registro na aplicação é uma pista: a requisição pode estar sendo encerrada antes de chegar ao Magento.
Não habilite exibição pública de erros em produção. Se for necessário aumentar o nível de registro, faça isso de forma controlada, por tempo limitado e sem expor dados de clientes, credenciais ou detalhes internos.
7. Separe erro de rota de conteúdo estático ausente
Um 404 em CSS, JavaScript, fontes ou imagens exige diagnóstico diferente. Abra as ferramentas de desenvolvimento do navegador e identifique exatamente quais recursos falham. Observe se o caminho contém versão de conteúdo estático, tema, idioma e área correta.
Confira se os arquivos esperados existem no release ativo e se o deploy estático foi concluído para os temas e idiomas utilizados. Antes de executar novamente processos demorados em produção, confirme espaço em disco, permissões, proprietário dos arquivos e integridade do release.
Se existe CDN, teste a origem separadamente e verifique se o endereço antigo foi armazenado em cache. Uma limpeza seletiva costuma ser mais segura do que invalidar todo o conteúdo sem saber qual objeto está incorreto.
8. Reproduza a correção em homologação e valide rotas críticas
Depois de localizar a causa, reproduza o cenário em um ambiente compatível. Teste a URL defeituosa e também rotas relacionadas: página inicial, categorias, produtos, busca, carrinho, checkout, conta do cliente, Admin e APIs utilizadas por integrações.
Se a solução envolver deploy, configuração do servidor ou regeneração de conteúdo, prepare backup e plano de retorno. Registre o estado anterior, os comandos executados e o resultado de cada validação. Isso reduz o risco de corrigir uma página e introduzir falhas em outras áreas.
O que evitar durante o diagnóstico
- Apagar todos os rewrites antes de identificar o registro conflitante.
- Editar diretamente o banco de dados sem backup e sem compreender a origem do dado.
- Limpar cache repetidamente como substituto para investigação.
- Trocar base URLs em produção apenas para testar uma hipótese.
- Reexecutar deploy estático sem conferir espaço, permissões e release ativo.
- Criar redirecionamento para a página inicial, ocultando uma URL quebrada.
Conclusão
O erro 404 no Magento 2 deve ser investigado da borda para a aplicação: resposta HTTP, domínio, rewrite, entidade, servidor web, logs e conteúdo estático. Essa sequência evita mudanças aleatórias e mostra se a correção pertence ao catálogo, à configuração ou ao processo de deploy.
Se a loja acumula URLs quebradas, conflitos de rewrite ou falhas após publicações, uma análise técnica do ambiente pode reduzir o tempo de indisponibilidade e preservar as evidências necessárias. A equipe do SuporteMagento.com.br pode apoiar o diagnóstico e a correção com uma abordagem controlada.
Perguntas frequentes sobre erro 404 no Magento 2
Limpar o cache corrige o erro 404 no Magento 2?
Pode resolver apenas quando uma resposta antiga está armazenada em alguma camada. Se a causa for URL incorreta, rewrite conflitante, entidade desativada, configuração do servidor ou arquivo ausente, limpar o cache não corrige a origem.
Por que somente uma página de produto retorna 404?
As causas mais comuns incluem URL key alterada, conflito de rewrite, produto fora do site acessado, status desativado ou link antigo. Compare o caminho solicitado com a configuração do produto e seus rewrites.
É seguro apagar a tabela url_rewrite?
Não é uma boa primeira medida. A exclusão indiscriminada pode remover rotas válidas e redirecionamentos importantes. Identifique o registro conflitante, faça backup e utilize o processo apropriado para a entidade afetada.
Como saber se o 404 vem do Magento ou do servidor?
Examine cabeçalhos, corpo da resposta e logs no mesmo horário. Se a requisição não aparece nos registros da aplicação, ela pode ter sido encerrada pelo servidor web, CDN, proxy ou balanceador antes de alcançar o Magento.
