Há um erro crítico no seu site: ache o culpado no log

A tela branca com uma frase não é o erro — é o aviso de que existe um

“Há um erro crítico no seu site.” É isso que o visitante vê, com um link para a documentação do WordPress e mais nada. A resposta HTTP é um 500. Quase todo guia responde a essa tela com a mesma lista: desative todos os plugins, troque o tema, aumente a memória, restaure o backup. Funciona às vezes — no escuro, por eliminação, derrubando o que estava funcionando junto.

O WordPress, desde a versão 5.2, sabe exatamente qual arquivo quebrou. Ele registra o tipo do erro, o arquivo, a linha e a mensagem, e em certos casos manda tudo isso por e-mail. O trabalho não é adivinhar o culpado: é ler o que o WordPress já escreveu. Este guia mostra onde essa informação está, por que o e-mail às vezes não chega, e como transformar uma linha de log em um nome de plugin.

A frase exata já diz em que situação você está

O manipulador de erro fatal do WordPress escolhe entre três mensagens, e cada uma revela algo diferente. Os textos abaixo são os da tradução oficial em português do Brasil:

A primeira linha é a mais comum e a que mais engana: se você só olhou o site pelo front-end, o e-mail pode nunca ter sido disparado. A próxima seção explica por quê.

Por que o e-mail de recuperação às vezes não chega

Lendo o código do modo de recuperação do WordPress, o e-mail só sai quando quatro condições se cumprem ao mesmo tempo:

1. O erro está num plugin ou num tema. O WordPress identifica o culpado pelo caminho do arquivo: se está dentro de wp-content/plugins/, o culpado é a primeira pasta depois de plugins/; se está numa pasta de temas, é o tema. Erro em mu-plugins, no núcleo ou no wp-config.php não gera e-mail.
2. O erro aconteceu num endpoint protegido. São três: a tela de login (wp-login.php), o painel (wp-admin, fora de requisições AJAX comuns) e algumas ações AJAX que ajudam a resolver o problema. Erro que só acontece no front-end mostra a tela, mas não manda e-mail.
3. Não houve outro e-mail nas últimas 24 horas. O limite padrão é de um dia, definido pelo filtro recovery_mode_email_rate_limit. Se o erro já aconteceu ontem, o e-mail de hoje não vem.
4. O próprio envio de e-mail do site funciona. O aviso sai pelo wp_mail, o mesmo caminho de qualquer e-mail do WordPress. Site que não envia e-mail também não envia este.

O destinatário é o e-mail de administração em Configurações → Geral. Se essa caixa é de alguém que saiu da agência, o aviso vai para lá. A constante RECOVERY_MODE_EMAIL no wp-config.php muda o destino sem mexer no e-mail de administração:

define( 'RECOVERY_MODE_EMAIL', 'suporte@seudominio.com.br' );

Truque prático: se o site quebrou no front-end e o e-mail não veio, abra /wp-login.php ou /wp-admin/. Se o erro também acontece ali, você está num endpoint protegido e o WordPress tenta mandar o e-mail nesse momento — é quando aparece a segunda mensagem da tabela. Se o site não envia e-mail nenhum, conserte isso depois: o nosso guia de SMTP com teste de envio mostra o caminho, e é ele que garante que o próximo aviso chegue.

Lendo o e-mail linha por linha

O assunto chega como [Nome do site] O seu site está experimentando um problema técnico. O corpo tem quatro partes úteis, e só uma delas costuma ser lida.

1. A causa. Uma frase como “Neste caso, o WordPress detectou um erro com o seu plugin: Nome do Plugin.” ou “…com o seu tema: Nome do Tema.” Esse é o culpado segundo o caminho do arquivo onde o erro explodiu — quase sempre certo, com uma exceção que aparece logo depois da tabela.

2. O link do modo de restauração. Aponta para wp-login.php?action=enter_recovery_mode com um token. O e-mail diz que ele expira em um prazo — por padrão, o mesmo um dia do limite de envio. Se expirar e o erro se repetir depois disso, chega um link novo.

3. As informações de ambiente. Linhas como WordPress versão, Tema atual, Plugin atual (com a versão) e PHP versão. É a parte que mais ajuda e menos gente lê: um erro que surgiu logo depois de a hospedagem trocar a versão do PHP aparece aqui.

4. Os detalhes do erro. Uma frase no formato “Um erro do tipo E_ERROR foi causado na linha 123 do arquivo /home/…/wp-content/plugins/nome-do-plugin/arquivo.php. Mensagem de erro: …”. É a mesma informação do log, e se lê com a tabela abaixo.

O que o modo de restauração faz (e o que ele não faz)

Pelo link, você entra no painel com o plugin ou tema culpado pausado. A nota técnica do WordPress 5.2 é explícita: a pausa vale só para quem está no modo de restauração, e para os outros usuários o site continua quebrado até o problema ser corrigido. Ou seja:

• O modo de restauração não conserta o site para os visitantes. Ele te dá um painel funcionando para consertar.
• Dentro dele, a tela de Plugins mostra o culpado com o erro. Desative, faça rollback ou atualize — e só então clique em Sair do modo de restauração.
• Se você sair sem desativar nada, o visitante continua vendo a mesma tela.

Sem e-mail? O mesmo dado está no debug.log

Quando o e-mail não vem, o log é a fonte. Ligue no wp-config.php, acima da linha que diz para parar de editar:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );          // grava em wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );     // não mostra o erro ao visitante
@ini_set( 'display_errors', 0 );

A documentação oficial de depuração explica as três constantes; o código do núcleo confirma que WP_DEBUG_LOG como true grava em wp-content/debug.log e que, desde o WordPress 5.1, ela aceita também um caminho de arquivo. Prefira um caminho fora da pasta pública — um debug.log acessível pela web entrega caminhos do servidor e nomes de plugins a quem pedir:

define( 'WP_DEBUG_LOG', '/home/usuario/logs/wp-debug.log' );

Recarregue a página que quebra e leia o fim do arquivo:

# as 5 últimas linhas de erro fatal
grep "PHP Fatal error" wp-content/debug.log | tail -n 5

# quais plugins aparecem nos erros fatais, do mais citado ao menos
grep "PHP Fatal error" wp-content/debug.log | grep -o "wp-content/plugins/[^/]*" | sort | uniq -c | sort -rn

# sem debug.log? o log de erros do PHP da hospedagem costuma ter a mesma linha
tail -n 50 ~/logs/error_log

Tabela: linha do log → culpado → ação

O WordPress só trata como crítico os erros dos tipos E_ERROR, E_PARSE, E_USER_ERROR, E_COMPILE_ERROR e E_RECOVERABLE_ERROR. Linhas de PHP Warning, Notice e Deprecated enchem o log, mas não derrubam o site — ignore-as nesta investigação e procure a linha PHP Fatal error ou PHP Parse error mais recente.

A exceção prometida: o WordPress aponta o culpado pelo arquivo onde o erro explodiu, não por quem o provocou. Se o plugin A chama uma função do plugin B com dados errados e o erro estoura dentro de B, o e-mail culpa B. E se o erro estoura dentro do núcleo, o WordPress não identifica plugin nenhum e nem manda e-mail. Nos dois casos, o rastreamento (Stack trace) logo abaixo da linha do erro mostra a cadeia de chamadas: leia de cima para baixo e anote cada caminho de plugin ou tema que aparecer.

Desativar só o culpado, sem painel

Com o nome do plugin na mão, desative só ele. Pelo WP-CLI, os parâmetros --skip-plugins e --skip-themes fazem o comando rodar sem carregar o código que está quebrando:

# confirmar o nome exato da pasta
wp plugin list --skip-plugins --skip-themes

# desativar só o culpado
wp plugin deactivate nome-do-plugin --skip-plugins --skip-themes

# voltar para a versão anterior que funcionava
wp plugin install nome-do-plugin --version=1.2.3 --force --skip-plugins --skip-themes

Sem SSH, renomeie a pasta do plugin por FTP ou pelo gerenciador de arquivos da hospedagem (nome-do-plugin para nome-do-plugin.off). O WordPress só carrega plugins cujo arquivo principal existe, então o plugin renomeado deixa de rodar já na próxima requisição. Para tema, o equivalente é renomear a pasta do tema ativo: ao abrir o painel, o WordPress detecta o tema inválido e volta para o tema padrão — se houver um tema padrão instalado.

Evite o reflexo de desativar todos os plugins. Em loja, isso derruba checkout, cache e segurança de uma vez, e reativar um por um num site com 40 plugins leva mais tempo que ler uma linha de log.

Depois do conserto: desligue o que você ligou

1. Volte o WP_DEBUG para false e apague o debug.log se ele ficou na pasta pública.
2. Saia do modo de restauração pelo aviso no topo do painel.
3. Anote a causa — plugin, versão, versão do PHP. Se foi uma atualização automática, desligue a atualização automática daquele plugin até a correção sair.
4. Confira o site por fora: curl -sI https://seudominio.com.br/ | head -1 tem que voltar 200, não 500.

Erro crítico logo depois de atualização é a regra, não a exceção — vale planejar a atualização em vez de reagir a ela, como detalhamos no guia para atualizar o WordPress com segurança. E se o log mostrar arquivo que você não reconhece, em pasta que você não criou, o problema pode não ser bug: é hora do nosso checklist de hardening do WordPress, começando pela seção de como saber se já entraram.