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

Significa que o PHP encontrou um erro fatal enquanto montava a página e o WordPress interceptou antes de aparecer a tela branca. A mensagem é vaga de propósito para que visitantes não vejam caminhos de arquivos nem código. O erro de verdade, com arquivo e número da linha, é gravado em um log no servidor.

Onde fica o log do erro crítico do WordPress?

Se você definir WP_DEBUG e WP_DEBUG_LOG como true no wp-config.php, o WordPress grava em wp-content/debug.log. Se estiverem desligados, o erro ainda vai para o log de erros do PHP da sua hospedagem, normalmente acessível no painel de controle em logs ou logs de erro. Verifique os dois antes de concluir que nada foi registrado.

Por que não recebi o e-mail de modo de recuperação do WordPress?

O e-mail vai para o endereço de administração do site definido em Configurações, não para o endereço com que você faz login, e é enviado pelo mesmo PHP quebrado que acabou de travar, então a entrega falha com frequência. Hospedagens compartilhadas também bloqueiam envio de e-mail sem SMTP. Olhe no spam e, se não estiver lá, esqueça o e-mail e desative os plugins por SFTP.

Como resolver um erro crítico se não consigo entrar no wp-admin?

Conecte por SFTP ou pelo gerenciador de arquivos da hospedagem e renomeie a pasta wp-content/plugins para plugins-off. Isso desativa todos os plugins de uma vez e quase sempre devolve o acesso ao painel. Renomeie de volta e depois reative os plugins um a um até o erro voltar, e aí você achou o culpado.

Uma atualização da versão do PHP pode causar um erro crítico no WordPress?

Pode, e é uma das causas mais comuns. Hospedagens atualizam o PHP automaticamente, e código antigo de plugin ou tema que usa sintaxe removida quebra na hora. A entrada do log costuma apontar um arquivo específico dentro de wp-content. Voltar o PHP para a versão anterior no painel da hospedagem confirma o diagnóstico, embora seja uma solução temporária.

A mensagem de erro crítico significa que meu site foi hackeado?

Normalmente não. A esmagadora maioria dos casos é uma atualização de plugin ou tema incompatível com a sua versão do PHP, ou falta de memória. Malware também pode causar erros fatais, mas aí a entrada do log aponta para um arquivo desconhecido ou código ofuscado. Leia o log antes de supor invasão.

Houve um Erro Crítico Neste Site: o Que Significa e Como Resolver

Essa mensagem significa que o PHP encontrou um erro fatal enquanto montava sua página, e o WordPress interceptou antes que virasse uma tela branca. O erro é real, específico e está registrado — o WordPress só se recusa a imprimi-lo no navegador, porque um rastreamento de pilha em uma página pública expõe caminhos de arquivos e código para qualquer visitante.

Então a solução nunca é chutar. É: leia o erro real e depois aja com base no que ele diz.

O que está realmente acontecendo

Desde o WordPress 5.2 existe um tratador de erros fatais embutido no core. Quando o PHP morre no meio da requisição, o tratador entra em ação, substitui a saída do travamento pela frase genérica educada e — se conseguir descobrir qual plugin ou tema causou o problema — tenta enviar ao administrador do site um e-mail com um link para o modo de recuperação.

É por isso que você vê isso no lugar da antiga tela branca da morte. É uma melhoria, mas também significa que a informação de diagnóstico fica escondida por padrão. Existem duas versões da mensagem:

O que você vê	Onde	O que isso te diz
”Houve um erro crítico neste site.”	Site, deslogado	Ocorreu um erro fatal, nenhum detalhe a mais foi exposto
A mesma frase mais “Saiba mais sobre solução de problemas no WordPress”	Site ou wp-admin	Mesmo erro, o WordPress está te oferecendo a página do manual
”…Verifique a caixa de entrada do e-mail do administrador do site para obter instruções.”	Site	O tratador acreditou ter enviado um e-mail de recuperação

Essa terceira variação é a útil. Ela significa que o WordPress atribuiu o travamento a um plugin ou tema específico e tentou te dar um caminho de entrada.

Passo 1: verifique o e-mail de modo de recuperação

O WordPress envia o link de recuperação para o endereço de e-mail de administração do site — o que está em Configurações, Geral — que muitas vezes não é o endereço com que você faz login. Verifique aquela caixa de entrada, e verifique o spam.

O e-mail contém um link longo terminando em algo como ?action=enter_recovery_mode. Abrir esse link te loga no wp-admin em modo de recuperação, onde o plugin ou tema problemático fica pausado e sinalizado em um aviso vermelho no topo. A partir dali você consegue desativá-lo normalmente.

Duas ressalvas honestas. Primeiro, o e-mail é gerado pelo mesmo processo PHP que acabou de travar, em uma hospedagem que pode não ter transporte de e-mail funcionando — a não entrega é comum, e a ausência dele não diz nada sobre o erro. Segundo, o link de recuperação expira (mais ou menos um dia, por padrão), então um e-mail antigo na sua caixa pode simplesmente não funcionar mais; provoque um travamento novo recarregando o site e espere um e-mail novo chegar.

Se você quer que o e-mail vá para um lugar que você realmente lê, defina isso explicitamente no wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Passo 2: leia o erro de verdade

Este é o passo que transforma um site quebrado em um conserto de cinco minutos. Adicione estas linhas ao wp-config.php, acima da linha que diz para parar de editar:

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

WP_DEBUG_DISPLAY como false faz diferença — isso mantém o erro fora do navegador e ao mesmo tempo continua gravando ele em disco, então você não expõe caminhos para os visitantes enquanto depura.

Recarregue a página quebrada uma vez e depois abra o wp-content/debug.log. A última entrada vai parecer mais ou menos com isto:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

O caminho do arquivo é a resposta. Se ele aponta para dentro de wp-content/plugins/, aquele plugin é a causa. Se aponta para dentro de wp-content/themes/, é o tema — muitas vezes algo colado recentemente no functions.php.

Se o debug.log não aparecer, pode ser que a pasta não tenha permissão de escrita ou que um plugin de segurança tenha movido o registro de logs para outro lugar. Recorra ao log de erros do PHP da sua hospedagem — a maioria dos painéis tem uma seção “Log de Erros” ou “Logs”, e o mesmo erro fatal vai estar lá com data e hora.

Cole a entrada no decodificador de log de erros do WordPress para traduzir o texto do PHP para o que ele significa na prática e qual arquivo olhar primeiro.

Apague essas linhas de depuração quando terminar. Deixar o WP_DEBUG ligado em produção enche o disco e, se o WP_DEBUG_DISPLAY for religado em algum momento, imprime caminhos do servidor publicamente.

Passo 3: volte para o wp-admin

Se o wp-admin também está morto e nenhum e-mail de recuperação chegou, desative todos os plugins pelo sistema de arquivos. Conecte por SFTP (ou pelo gerenciador de arquivos da hospedagem) e renomeie uma pasta:

mv wp-content/plugins wp-content/plugins-off

O WordPress não encontra os plugins, então desativa todos e o acesso ao painel quase sempre volta. Em seguida:

Renomeie a pasta de volta para plugins. Tudo continua desativado — o WordPress registrou os plugins como inativos.
Reative os plugins um de cada vez, carregando o site depois de cada um.
Aquele que traz o erro de volta é o seu culpado.

Se o site continua quebrado com todos os plugins desligados, o suspeito é o tema. Renomeie a pasta do tema ativo dentro de wp-content/themes/ e o WordPress cai para um tema padrão, se houver um instalado.

As três causas que vale conhecer

Uma atualização de plugin ou tema que quebra tudo. De longe a mais comum. O log nomeia o arquivo diretamente. Volte aquele plugin específico para a versão anterior, ou deixe ele desativado e procure o desenvolvedor com a linha do log em mãos.

Incompatibilidade de versão do PHP. Hospedagens atualizam o PHP por cronograma, às vezes sem muito aviso. Código escrito para PHP antigo pode nem ser interpretado em uma versão nova. O sinal é que nada mudou do seu lado e tudo quebrou de uma vez. Voltar uma versão menor do PHP no painel da hospedagem é um diagnóstico válido — mas trate isso como comprar tempo, não como solução. Versões antigas de PHP param de receber correções de segurança.

Falta de memória. O log diz “Allowed memory size of X bytes exhausted”. Aumentar o limite no wp-config.php é razoável:

define( 'WP_MEMORY_LIMIT', '256M' );

Seja honesto sobre o que isso faz: remove o teto, não conserta o que consumiu 256MB para renderizar uma página. Se o limite precisa subir sempre, alguma coisa — normalmente uma importação, um construtor de páginas ou uma consulta mal escrita — é o problema de verdade.

Conselhos que você pode ignorar tranquilamente

“É só aumentar o limite de memória.” Só faz sentido se o log realmente disser que a memória se esgotou. Fora isso não muda nada e esconde que você nunca leu o erro.

“Reinstale o core do WordPress.” Arquivos do core raramente são a causa, e substituí-los desperdiça um tempo que você poderia usar lendo uma linha do log.

“Desligue o tratador de erros fatais.” Existe uma constante para desativá-lo, e o resultado é que o erro cru passa a ser impresso no seu site público em vez de interceptado. Isso expõe caminhos de arquivos para os visitantes. Use WP_DEBUG_LOG com WP_DEBUG_DISPLAY desligado — mesma informação, nenhuma exposição.

“Limpe seu cache.” Um erro fatal acontece no PHP antes de qualquer plugin de cache conseguir servir alguma coisa. Se uma cópia em cache da página de erro está sendo servida, limpar ajuda depois que você corrigir a causa — nunca no lugar disso.

Ainda travado?

Se o log aponta para um arquivo do core em vez de algo dentro de wp-content, a explicação mais provável é um plugin carregado antes que quebrou o estado do qual o core depende, e não um core corrompido. Desligue tudo com a renomeação da pasta, confirme que o site carrega limpo e depois reintroduza os plugins um a um — o último que você ativar antes do erro voltar é o que você deve reportar, com a linha do log anexada.