Erro crítico no WordPress: como diagnosticar sem piorar o problema

Ver a mensagem “houve um erro crítico neste site” é uma das situações mais tensas para quem administra um WordPress. Às vezes o site sai do ar. Às vezes o painel não abre. Em outros casos, aparece uma tela branca, um erro 500 ou um e-mail do WordPress falando em modo de recuperação.

A primeira reação costuma ser sair desativando plugins, restaurando backup antigo ou editando arquivos às pressas. É justamente aí que mora o risco: uma correção impulsiva pode esconder a causa real, apagar evidências, gerar perda de dados ou transformar um erro simples em um problema maior.

Neste guia, você vai ver uma sequência segura para diagnosticar erro crítico no WordPress: o que fazer primeiro, como usar o modo de recuperação, como isolar plugins e tema, quando ativar debug temporariamente e quando chamar a hospedagem ou um desenvolvedor.

Antes de começar: se o site é importante para vendas, leads, membros, cursos ou pedidos, faça backup completo do estado atual antes de alterar arquivos, plugins, temas, PHP, .htaccess ou banco de dados. Se você ainda não tem uma rotina confiável, veja também nosso guia de backup WordPress.

Checklist rápido: o que fazer agora

Se o site está fora do ar neste momento, siga esta ordem:

1. Respire e anote o que aconteceu antes do erro.
2. Faça backup do estado atual, se tiver acesso à hospedagem.
3. Verifique o e-mail de administração do WordPress.
4. Procure uma mensagem de modo de recuperação.
5. Se o painel abrir, desative primeiro o plugin ou tema alterado por último.
6. Se o painel não abrir, use FTP/SFTP ou gerenciador de arquivos para isolar plugins sem apagar arquivos.
7. Ative debug apenas se precisar identificar o erro técnico.
8. Não publique logs completos em fóruns, comentários ou chats.
9. Se houver sinais de invasão, trate como incidente de segurança.
10. Se envolver banco de dados, WooCommerce, assinaturas, pedidos ou restauração complexa, acione suporte técnico.

A lógica é simples: primeiro preserve o site e as evidências; depois isole a causa; só então aplique a correção.

O que significa “houve um erro crítico neste site”?

A mensagem de erro crítico no WordPress geralmente indica que o WordPress encontrou uma falha que impediu o carregamento normal da página. Em muitos casos, é um erro fatal de PHP causado por plugin, tema, incompatibilidade de versão, atualização interrompida, limite de memória, arquivo corrompido ou problema no servidor.

Mas a mensagem sozinha não diz a causa exata. Ela é um aviso genérico. Para diagnosticar, você precisa descobrir:

• qual página quebra: site público, painel, checkout, editor, login ou tudo;
• o que mudou antes do erro: plugin, tema, WordPress, PHP, snippet, cache, migração;
• se há e-mail de recuperação;
• se há log com mensagem de erro;
• se o erro desaparece ao desativar plugins ou tema;
• se a hospedagem registrou falha de PHP, memória, permissão ou banco de dados.

Por isso, o melhor caminho não é “testar qualquer coisa”. É seguir uma triagem em ordem.

Erro crítico, tela branca, erro 500 e site hackeado são a mesma coisa?

Não necessariamente. Esses sintomas podem aparecer juntos, mas não significam a mesma coisa.

Erro crítico no WordPress

É a mensagem exibida pelo WordPress quando ele detecta uma falha grave no carregamento. Dependendo do tipo de erro, da versão do WordPress e da capacidade do site de enviar e-mail, pode vir acompanhada de um e-mail para o administrador com um link de recuperação.

Tela branca WordPress

A tela branca, também chamada de “white screen of death”, é quando o site mostra uma página em branco ou quase sem informação. Segundo a documentação oficial, isso pode ser causado por erros de PHP ou banco de dados, inclusive conflitos de plugins ou temas.

Erro 500

O erro 500 é uma resposta genérica do servidor. Pode ter relação com WordPress, PHP, .htaccess, permissões, limite de memória, configuração da hospedagem ou outros fatores. Nem todo erro 500 mostra uma mensagem clara no navegador.

Erro de conexão com banco de dados

Esse caso costuma mostrar uma mensagem específica de conexão com banco. Pode envolver credenciais no wp-config.php, servidor de banco indisponível, banco corrompido ou problema da hospedagem. Não trate como simples conflito de plugin sem investigar.

Site hackeado

Um erro crítico pode acontecer em um site invadido, mas nem todo erro crítico é invasão. Suspeite de hack quando houver redirecionamentos estranhos, alerta de malware, usuários administradores desconhecidos, arquivos alterados sem explicação, spam, blacklist ou conteúdo que você não publicou. Nesse caso, siga um processo de limpeza e recuperação, como explicamos no guia de WordPress hackeado.

Antes de mexer: faça backup e registre o contexto

Mesmo que o site já esteja quebrado, tente fazer um backup do estado atual antes de alterar arquivos. Isso é importante por três motivos:

1. Você pode precisar voltar atrás.
2. Um desenvolvedor pode precisar analisar o que estava acontecendo.
3. Se houver invasão, o estado atual pode conter evidências.

O backup ideal inclui arquivos e banco de dados. Em muitas hospedagens, você consegue gerar isso pelo painel. Em outras, o backup fica no cPanel, Plesk, painel próprio, plugin de backup ou suporte da hospedagem.

Também anote:

• data e horário aproximado do erro;
• última atualização feita;
• último plugin instalado ou configurado;
• último tema ativado ou editado;
• mudança recente de PHP na hospedagem;
• restauração, migração ou alteração de cache/CDN;
• URL exata onde o erro aparece;
• se o painel /wp-admin abre ou não.

Essa anotação simples economiza tempo e reduz o risco de mexer no lugar errado.

Verifique o e-mail de modo de recuperação do WordPress

Desde o WordPress 5.2, o WordPress tem proteção para alguns erros fatais em PHP. Esse recurso melhorou o tratamento da “tela branca da morte” e incluiu o modo de recuperação, que pode pausar plugins ou temas causadores do erro para permitir acesso administrativo temporário.

Procure na caixa de entrada e no spam por mensagens do WordPress relacionadas a erro fatal, modo de recuperação ou problema técnico no site.

Atenção a dois detalhes:

• o e-mail vai para o endereço de administração configurado em Configurações → Geral, não necessariamente para o e-mail do seu usuário;
• se o site não consegue enviar e-mail, se o endereço está errado ou se a hospedagem bloqueia envios, talvez você não receba a mensagem.

Se você conseguir entrar pelo link de recuperação, o WordPress pode pausar temporariamente a extensão problemática para aquele acesso. Use essa oportunidade para desativar o plugin ou tema suspeito, fazer backup e investigar com calma.

Se o painel ainda abre: comece pelo que mudou por último

Se você consegue acessar o painel do WordPress, comece pela hipótese mais simples: algo mudou antes do erro.

Vá em Plugins → Plugins instalados e veja se houve atualização, instalação ou ativação recente. Se o erro começou depois de uma mudança específica, desative esse plugin primeiro e teste novamente.

Depois, confira:

• plugins de cache;
• plugins de segurança;
• construtores de páginas;
• plugins recém-atualizados;
• snippets de código;
• tema ativo;
• atualizações de tradução ou do WordPress;
• mudança recente de versão do PHP na hospedagem.

Evite desativar tudo de uma vez se você ainda tem acesso ao painel e consegue testar com ordem. Desativar tudo pode resolver momentaneamente, mas dificulta saber qual item causou o problema.

Se o painel não abre: desative plugins por FTP ou gerenciador de arquivos

Se o painel não abre, você pode isolar plugins pelo acesso aos arquivos do site. Esse procedimento exige cuidado, porque você estará mexendo na estrutura da instalação.

Pré-requisitos:

• backup recente ou backup do estado atual;
• acesso à hospedagem, FTP/SFTP ou gerenciador de arquivos;
• saber onde fica a instalação WordPress;
• não apagar pastas, apenas renomear temporariamente.

O caminho geral é:

1. Acesse os arquivos do site pela hospedagem, FTP ou SFTP.
2. Entre na pasta da instalação WordPress.
3. Abra a pasta wp-content.
4. Localize a pasta plugins.
5. Renomeie plugins para algo como plugins-desativados-temporariamente.
6. Teste se o site ou o painel volta a carregar.
7. Se voltar, renomeie a pasta de volta para plugins.
8. Entre no painel e reative os plugins um por um, testando entre cada ativação.

Esse método não deve ser confundido com apagar plugins. A ideia é desativar temporariamente para descobrir se algum plugin é a causa. A documentação oficial do WordPress descreve esse caminho como uma alternativa quando não há acesso às telas administrativas.

Se o site for uma loja WooCommerce, comunidade, área de membros ou plataforma de cursos, faça isso com atenção extra. Desativar plugins pode afetar checkout, pagamentos, assinaturas, acesso de alunos ou automações.

Como testar se o problema está no tema

Se desativar plugins não resolver, o tema pode estar envolvido, especialmente se o erro começou depois de:

• ativar um novo tema;
• atualizar o tema ativo;
• editar functions.php;
• instalar um tema filho;
• alterar templates;
• mudar a versão do PHP.

Se o painel abre, a forma mais simples é ir em Aparência → Temas e ativar temporariamente um tema padrão compatível com sua versão do WordPress. Depois, teste o site.

Se o painel não abre, mexer no tema via arquivos é mais sensível. Renomear a pasta do tema ativo pode fazer o WordPress tentar alternar para outro tema disponível, mas isso depende da instalação e pode gerar novos sintomas se não houver tema padrão instalado. Em site importante, prefira pedir ajuda à hospedagem ou a um desenvolvedor antes de trocar tema pelos arquivos.

Nunca edite diretamente o tema pai em produção para “testar rápido”. Se houver necessidade de alterar código, o ideal é usar staging e tema filho.

Como ativar debug WordPress temporariamente

Quando o erro não fica claro, o debug do WordPress pode ajudar a identificar a mensagem técnica. Ele deve ser usado com cuidado e por tempo limitado, principalmente em site publicado.

O arquivo envolvido é o wp-config.php, que fica na raiz da instalação WordPress e contém configurações sensíveis. Antes de editar esse arquivo, faça backup dele e confirme que você consegue restaurá-lo se algo der errado.

No wp-config.php, procure se já existem linhas com WP_DEBUG, WP_DEBUG_LOG ou WP_DEBUG_DISPLAY. Se existirem, ajuste as linhas existentes em vez de duplicar constantes. A configuração deve ficar antes da linha que diz algo como /* That's all, stop editing! Happy blogging. */.

Exemplo para diagnóstico temporário:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

O que isso faz:

• WP_DEBUG ativa o modo de debug;
• WP_DEBUG_LOG grava erros em um arquivo de log, normalmente wp-content/debug.log;
• WP_DEBUG_DISPLAY como false evita exibir erros diretamente no HTML para visitantes;
• display_errors desativado reduz o risco de expor mensagens técnicas ao público.

Use true e false sem aspas. Na configuração do PHP, valores entre aspas podem ser tratados como texto, não como booleanos.

Depois de coletar as informações necessárias, desligue o debug. Se você adicionou essas linhas apenas para a investigação, remova-as ou ajuste para algo como:

define( 'WP_DEBUG', false );

Importante: não mantenha debug ligado em produção sem motivo. Logs podem crescer, afetar performance e revelar detalhes técnicos do ambiente.

Como ler logs sem expor dados sensíveis

O log pode mostrar o arquivo, a linha e a função relacionados ao erro. Isso ajuda muito a identificar se o problema está em um plugin, tema, snippet ou incompatibilidade de PHP.

Procure por pistas como:

• nome de plugin dentro de wp-content/plugins/nome-do-plugin;
• nome do tema em wp-content/themes/nome-do-tema;
• mensagens de Fatal error;
• erros de sintaxe;
• mensagens sobre função inexistente;
• mensagens de memória insuficiente;
• incompatibilidade com versão do PHP;
• chamadas repetidas pouco antes do site cair.

Mas cuidado: não cole o log completo em comentários, fóruns, tickets públicos ou grupos. Logs podem expor caminhos internos do servidor, nomes de plugins, estrutura de pastas e outros detalhes úteis para atacantes.

Se precisar pedir ajuda, compartilhe apenas o trecho essencial e remova dados sensíveis. Em caso de dúvida, envie o log diretamente para a hospedagem ou para um profissional de confiança.

Causas comuns de erro crítico no WordPress

1. Plugin incompatível ou com bug

É uma das causas mais comuns. Pode acontecer depois de atualização do plugin, conflito com outro plugin, mudança de versão do PHP ou configuração nova.

O caminho seguro é desativar o plugin suspeito, testar, verificar atualização/correção e só reativar quando houver segurança.

2. Tema com erro

Um tema pode causar erro crítico quando tem código incompatível, template quebrado, função removida, conflito com plugin ou edição manual malfeita.

Se o erro começou após alteração de tema, investigue por esse caminho.

3. Snippet ou código personalizado

Plugins de snippets, functions.php e códigos adicionados manualmente podem quebrar o site com um erro de sintaxe pequeno. Se você adicionou código antes do erro, essa é uma hipótese forte.

4. Versão de PHP incompatível

Alguns plugins e temas exigem versões específicas de PHP. Uma atualização de PHP na hospedagem pode quebrar código antigo; uma versão antiga de PHP pode impedir plugins modernos de funcionar.

Ajuste de PHP deve ser feito com cautela, preferencialmente em staging ou com orientação da hospedagem.

5. Limite de memória

Sites com muitos plugins, construtores, WooCommerce ou operações pesadas podem atingir limite de memória. Isso pode aparecer como erro fatal no log.

Aumentar memória pode ajudar em alguns casos, mas não deve esconder um plugin mal otimizado ou problema de código.

6. Atualização interrompida

Atualização incompleta de plugin, tema ou WordPress pode deixar arquivos inconsistentes. Se o erro apareceu durante atualização, verifique também se o site ficou preso em modo de manutenção ou se arquivos foram parcialmente substituídos.

7. Cache ou CDN

Cache normalmente não causa erro fatal de PHP sozinho, mas pode manter páginas antigas, mascarar correções ou dificultar o teste. Depois de corrigir, limpe cache do plugin, servidor e CDN, se houver.

8. Problema na hospedagem

Limite de recursos, erro de servidor, permissão incorreta, falta de espaço em disco, queda de banco ou configuração de PHP podem gerar sintomas parecidos. Se nada mudou no WordPress e vários sites da mesma hospedagem apresentam problema, fale com o suporte.

O que não fazer durante um erro crítico

Evite estas ações:

• apagar plugins ou temas sem backup;
• restaurar backup antigo sem avaliar perda de pedidos, leads ou conteúdo recente;
• editar banco de dados sem conhecimento;
• mudar permissões de arquivos em massa;
• copiar soluções aleatórias de fóruns sem entender o contexto;
• deixar WP_DEBUG_DISPLAY ativo mostrando erros para visitantes;
• publicar logs completos em grupos ou comentários;
• desativar WooCommerce em loja ativa sem plano;
• trocar versão de PHP repetidamente sem registrar o que foi feito;
• culpar “hack” sem sinais concretos, ou ignorar sinais reais de invasão.

A regra é: cada ação precisa ser reversível ou registrada.

Quando chamar a hospedagem

Acione a hospedagem quando:

• você não tem acesso a FTP/SFTP ou gerenciador de arquivos;
• o painel do WordPress e o painel da hospedagem apresentam erro;
• o log indica problema de servidor, PHP, memória, permissão ou banco;
• falta espaço em disco;
• houve mudança de versão de PHP feita pelo provedor;
• o erro começou sem nenhuma alteração no WordPress;
• você precisa restaurar backup da hospedagem;
• o site está em hospedagem gerenciada e o provedor controla cache, PHP ou atualizações.

Uma boa hospedagem WordPress deve oferecer backup, logs, suporte preparado, staging e recursos de recuperação. Se esse tipo de problema é frequente, vale revisar os critérios antes de continuar acumulando risco operacional.

Quando chamar um desenvolvedor ou especialista em segurança

Chame um desenvolvedor quando:

• o log aponta erro em código personalizado;
• o tema foi alterado manualmente;
• há conflito complexo entre plugins;
• o site tem WooCommerce, membros, cursos ou integrações críticas;
• será necessário editar wp-config.php, .htaccess, templates ou banco com segurança;
• você não consegue isolar a causa sem quebrar outra parte do site.

Chame um especialista em segurança quando houver:

• redirecionamentos para sites suspeitos;
• arquivos desconhecidos;
• usuários administradores que você não criou;
• alertas de malware;
• blacklist do Google ou navegador;
• spam saindo do servidor;
• alterações não autorizadas em conteúdo ou código.

Nesse cenário, o problema não é apenas “tirar o erro da tela”. É limpar a causa, fechar a brecha e evitar reinfecção. Veja também o guia de segurança WordPress.

WP-CLI pode ajudar?

WP-CLI pode ajudar usuários técnicos a listar plugins, verificar temas, consultar versões e executar diagnósticos quando o painel não abre. Mas ele exige acesso SSH e cuidado, porque alguns comandos alteram diretamente arquivos, banco de dados e configurações.

Para o público geral, WP-CLI não é obrigatório para resolver erro crítico. Se você já usa SSH e sabe o que está fazendo, veja nosso guia sobre WP-CLI em hospedagem WordPress antes de executar comandos em produção.

Como evitar que o erro crítico volte

Nem todo erro pode ser evitado, mas boas práticas reduzem bastante o risco:

• mantenha backup automático e externo;
• teste restauração de backup periodicamente;
• use staging para mudanças importantes;
• atualize plugins, temas e WordPress com rotina;
• evite plugins abandonados ou de origem duvidosa;
• não edite tema pai diretamente;
• documente plugins críticos;
• mantenha o e-mail de administração correto;
• monitore alertas da hospedagem;
• use PHP compatível com seus plugins e tema;
• remova snippets antigos que ninguém entende;
• mantenha cache e CDN documentados;
• proteja o painel com boas práticas de segurança.

Erro crítico costuma ser menos traumático quando você já tem backup, acesso à hospedagem, staging e um processo de atualização.

FAQ sobre erro crítico no WordPress

O que causa erro crítico no WordPress?

As causas mais comuns são erro fatal de PHP, conflito de plugin, erro no tema, snippet quebrado, incompatibilidade com versão de PHP, limite de memória, atualização interrompida ou problema da hospedagem. O log é o melhor caminho para confirmar.

Posso apagar o plugin que causou o erro?

Evite apagar como primeira medida. Na maioria dos casos, é melhor desativar ou renomear temporariamente a pasta do plugin para preservar arquivos e configurações. Apagar sem backup pode dificultar a recuperação.

O modo de recuperação sempre aparece?

Não. Ele depende do tipo de erro, da capacidade do WordPress de enviar e-mail e do endereço de administração estar correto. Se o e-mail não chega, você ainda pode precisar diagnosticar por FTP, painel da hospedagem ou logs.

Onde fica o debug.log do WordPress?

Quando WP_DEBUG e WP_DEBUG_LOG estão ativos, o log normalmente fica em wp-content/debug.log. Em algumas configurações, o caminho pode ser diferente. Hospedagens também podem ter logs próprios no painel.

Devo deixar WP_DEBUG ligado?

Não como prática permanente em site publicado. Use temporariamente para diagnóstico e desligue depois. Em produção, evite exibir erros para visitantes; prefira gravar em log e revisar com segurança.

Erro crítico significa que meu site foi hackeado?

Não necessariamente. Pode ser apenas conflito técnico. Mas se houver redirecionamentos, malware, usuários desconhecidos, arquivos estranhos, alertas do navegador ou spam, trate como possível invasão e siga um processo de segurança.

Restaurar backup resolve?

Pode resolver, mas não deve ser a primeira decisão automática. Se o backup é antigo, você pode perder pedidos, leads, posts, comentários ou cadastros recentes. Antes de restaurar, entenda o impacto e faça backup do estado atual.

Posso resolver sem desenvolvedor?

Em casos simples, sim: modo de recuperação, desativar plugin recém-atualizado ou limpar cache podem resolver. Mas se envolver banco, código, loja, segurança, hospedagem ou erro persistente, chame suporte técnico.

Conclusão

Erro crítico no WordPress não deve ser tratado no impulso. A mensagem indica que algo falhou, mas não diz sozinha o motivo. O caminho seguro é preservar o estado atual, verificar modo de recuperação, isolar plugins e tema, ativar debug apenas temporariamente e consultar logs com cuidado.

Se a causa for simples, você pode recuperar o acesso sem grandes danos. Se houver risco técnico, loja ativa, dados recentes, banco de dados ou sinais de invasão, pare antes de improvisar e peça ajuda qualificada.

A melhor proteção continua sendo prevenção: backup completo, hospedagem com suporte, atualizações planejadas, staging e boas práticas de segurança.