O Erro Crítico do WordPress (Tela Branca), Explicado

A tela branca da morte é um erro crítico do PHP que você não consegue ver. O WordPress atingiu um erro irrecuperável no meio da renderização, o PHP parou, e como a exibição de erros fica desligada em servidores de produção, a página voltou em branco em vez de mostrar o motivo. A correção quase nunca é no chute: ligue o log de depuração, abra o wp-content/debug.log e leia a última linha de erro crítico. Ela aponta o arquivo exato — quase sempre um plugin ou tema — e essa única linha é todo o conserto.

Por que a tela fica em branco

O PHP tem uma configuração chamada display_errors. Numa máquina de desenvolvimento ela normalmente está ligada, então um erro crítico imprime um stack trace na tela. Num servidor de verdade ela vem desligada por padrão, porque vazar caminhos de arquivos e erros para os visitantes é um problema de segurança. Então, quando algo dispara um erro crítico — uma chamada a uma função que não existe mais, uma classe que não foi carregada, um erro de sintaxe na atualização de um plugin — o PHP morre e não envia nada. Seu navegador renderiza um documento vazio. É essa a “tela branca”.

Desde o WordPress 5.2 existe um manipulador de erros críticos (WP_Fatal_Error_Handler) que tenta capturar essas situações. Quando funciona, você não recebe uma página em branco — recebe “Ocorreu um erro crítico neste site”, além de um e-mail para o endereço do administrador que muitas vezes contém o erro de verdade e um link para o Modo de Recuperação. Uma tela realmente em branco geralmente significa que o erro disparou antes desse manipulador conseguir rodar: um erro de parse/sintaxe (capturado em tempo de compilação), um must-use plugin quebrado, ou um erro crítico no functions.php do tema ativo. De qualquer forma, a causa está registrada em algum lugar. Você só precisa ligar o registro.

Corrija, na ordem

1. Ligue o log. Edite o wp-config.php via SFTP e adicione isto acima da linha /* That's all, stop editing! */:

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

Com WP_DEBUG_DISPLAY em false os erros ficam fora da página pública, enquanto WP_DEBUG_LOG os grava em wp-content/debug.log. Recarregue a página com problema uma vez para gerar uma entrada nova.

2. Leia o último erro crítico. Abra o wp-content/debug.log e olhe o final:

tail -n 30 wp-content/debug.log

Você está procurando uma linha assim:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

O caminho aponta o culpado: plugins/some-addon. Essa é a sua resposta. Se o trace for longo ou a mensagem for enigmática (Allowed memory size exhausted, Cannot redeclare, um nome de classe que você não reconhece), cole no nosso decodificador de log de erro — ele tira o ruído, diz qual plugin ou tema o caminho aponta e explica o que aquele tipo específico de erro significa.

3. Desative o componente indicado. Você não consegue acessar o /wp-admin, então faça isso via SFTP. Renomeie a pasta do plugin problemático, por exemplo some-addon → some-addon.off. O WordPress não consegue carregar uma pasta que não encontra, então ele desativa o plugin e o site volta. Se o log apontar para o seu tema, mude para um tema padrão renomeando a pasta do tema ativo — o WordPress recorre a um twentytwentysomething que já vem embutido.

4. Se o log não gravar, o wp-content não tem permissão de escrita, ou o erro está no nível do servidor. Verifique então o log de erros do PHP da hospedagem:

find . -name "error_log" -newermt "-1 hour"

Mesma informação, arquivo diferente. Ambientes cPanel/Apache costumam deixar um error_log na raiz do site ou no diretório que está falhando.

O que não fazer

Não saia aumentando o limite de memória. O conselho mais repetido na internet é subir o WP_MEMORY_LIMIT para 256M ou 512M. Isso só resolve o erro crítico se o log realmente disser Allowed memory size of N bytes exhausted. Se o erro for Call to undefined function, mais memória não faz nada — você mudou uma configuração no chute e a tela continua branca. Leia o log primeiro, depois aumente a memória só se a memória for o problema declarado.

Não limpe o cache e chame isso de diagnóstico. A tela branca é o PHP morrendo no servidor antes de qualquer HTML existir. Um asset em cache desatualizado não consegue causar um documento em branco. (Um plugin de cache quebrado consegue — mas o log vai nomeá-lo, que é justamente o ponto.)

Não edite nem reinstale o core do WordPress. O erro crítico quase nunca está em wp-includes ou wp-admin; está no plugin ou tema que o log aponta. Reinstalar o core é lento, arriscado e trata um sintoma que você não confirmou.

Não desative todos os plugins e reative um por um às cegas. A bisseção funciona, mas é o caminho lento. O log te diz a pasta exata em um passo. Recorra ao método de “desligar tudo” só quando não houver nenhum erro legível.

Não deixe o display_errors ligado em produção. Assim que o site voltar, remova as definições de depuração (ou coloque o WP_DEBUG de volta em false). Erros impressos para os visitantes expõem os seus caminhos.

Ainda travado?

Se o log nomeia um plugin, mas desativá-lo não limpa a tela, há um segundo erro crítico embaixo do primeiro — ligue o log de novo e leia a nova última linha; erros críticos se empilham. Se a própria mensagem for a barreira, jogue ela no decodificador de log de erro e deixe que ele traduza o tipo de erro e o caminho do arquivo para você. A tela branca só continua um mistério enquanto o log está desligado.