O site estava a funcionar há um segundo, estava a terminar um artigo ou a configurar o WooCommerce e, de repente, nada. Um ecrã branco em vez do painel de administração. Ou a página inicial desapareceu, embora o painel ainda abra. Parece-lhe familiar? Bem-vindo ao clube, conheceu o Ecrã Branco da Morte, também conhecido como WSOD, também conhecido como "white screen of death" WordPress.

O pânico é o primeiro inimigo aqui. O WSOD quase nunca significa que o site morreu de vez. Na maioria das vezes, a causa é banal: um conflito de plugin após uma atualização, código mal inserido no functions.php ou simples falta de memória para o processo PHP. Neste guia, quatro formas comprovadas de trazer o site de volta à vida e uma quinta integrada no núcleo do WordPress de que até os utilizadores experientes se esquecem.

💡 Visão geral rápida:

• Desative o plugin problemático através de FTP (renomeie a pasta) ou em massa, renomeando o diretório plugins
• Desative o tema conflituoso usando o mesmo método: pasta themes → renomeie o diretório do tema ativo
• Aumente o limite de memória PHP com a linha WP_MEMORY_LIMIT no wp-config.php para 128M ou 256M
• Ative WP_DEBUG e WP_DEBUG_LOG para diagnóstico, saiba a causa exata do erro a partir do ficheiro debug.log
• Use o Modo de Recuperação (WordPress 5.2+), um mecanismo integrado que envia um link para aceder ao painel de administração mesmo durante um erro fatal
• Restaure o site a partir de uma cópia de segurança se os outros métodos não funcionaram

1. Desativar o plugin problemático

Os plugins são a causa mais comum do WSOD. Acabou de atualizar o seu plugin de cache favorito, o ecrã ficou escuro. Instalou um novo slider, o site deixou de abrir. A mecânica é simples: o código PHP do plugin causa um erro fatal e o WordPress para de carregar a página inteira.

O problema é que não pode entrar no painel de administração e clicar em "Desativar", o painel de administração também fica em branco. A solução: desative o plugin diretamente através do sistema de ficheiros.

Como desativar um plugin através de FTP:

• Ligue-se ao servidor via FTP (FileZilla, WinSCP) ou através do gestor de ficheiros do alojamento (cPanel → File Manager).
• Navegue até ao diretório raiz do WordPress.
• Abra wp-content/plugins.
• Encontre a pasta do plugin problemático, o nome corresponde ao título (por exemplo, akismet, woocommerce ou elementor).
• Renomeie a pasta: adicione um underscore ou sufixo, _akismet ou akismet_disabled. O WordPress interpretará a renomeação como a ausência do plugin e desativá-lo-á.

Imediatamente após renomear, abra o site no seu navegador. Funciona, o culpado foi encontrado. Agora pode restaurar o nome original da pasta e, após iniciar sessão no painel de administração, atualizar o plugin para uma versão compatível ou removê-lo e encontrar uma alternativa.

Desativação em massa de todos os plugins de uma vez. Se não for claro qual o plugin que causou a falha, desative tudo em bloco. Renomeie a própria pasta wp-content/plugins para plugins_old e crie um novo diretório plugins vazio ao lado. Todos os plugins são desativados. Depois, reponha-os um a um: mova a pasta do plugin de plugins_old de volta para plugins, inicie sessão no painel de administração, ative-o e verifique o site. Repita até encontrar o culpado.

Alternativa para quem tem WP-CLI. Um comando no terminal substitui a dança do FTP:

1
wp plugin deactivate --all

E depois ative um a um: wp plugin activate <slug>. Rápido, limpo, sem gestor de ficheiros.

2. Desativar o tema conflituoso

O segundo culpado mais frequente é o tema. Os cenários são os mesmos: atualizou o tema para uma nova versão principal, instalou um tema com um functions.php mal escrito ou um plugin entrou em conflito com o tema atual após uma atualização do WordPress.

O mecanismo de correção é quase idêntico ao do plugin:

• Inicie sessão via FTP em wp-content/themes.
• Encontre a pasta do tema ativo (aquele que está atualmente instalado no site).
• Renomeie-a, por exemplo, adicione _disabled ao final do nome.

O WordPress, não encontrando o tema ativo, mudará automaticamente para o tema padrão Twenty Twenty-Five (ou Twenty Twenty-Four, dependendo da versão do WP). O site carregará com o design padrão, mas todo o seu conteúdo permanecerá no lugar. Importante: não elimine o tema padrão, caso contrário não haverá para onde mudar e terá outra ronda de WSOD.

Temas mal codificados e atualizações do WordPress. Após um lançamento principal do WordPress, temas antigos que usam funções ou hooks obsoletos podem quebrar. Temas de qualidade de developers verificados são atualizados poucos dias após o lançamento do núcleo. Se o seu tema não é atualizado há seis meses ou mais, isso é um sinal de alerta: mude para um que seja mantido ativamente.

Editar o functions.php e outros ficheiros do tema. Um erro de digitação no functions.php, um parêntese extra, uma chamada de hook incorreta e o site vai abaixo. Se editou ficheiros do tema imediatamente antes do WSOD aparecer, substitua o ficheiro alterado pela versão original de uma cópia de segurança ou da distribuição do tema. Sem cópia de segurança, descarregue o tema novamente da fonte e carregue o ficheiro limpo.

3. Exceder o limite de memória PHP

O site cresceu, os plugins multiplicaram-se, o tráfego aumentou e, de repente, WSOD. Um sintoma clássico de que o processo PHP ficou sem RAM. Especialmente relevante em alojamento barato, onde um servidor serve centenas de sites e o limite por cliente é reduzido ao mínimo.

O WordPress recomenda oficialmente um mínimo de 64 MB de memória, mas esta recomendação data da era do PHP 5.6 e de cinco plugins por site. Em 2026, um mínimo realista para um site funcional é de 128 MB, e para construções com Elementor, WooCommerce e várias dezenas de plugins, 256 MB.

Como aumentar o limite de memória:

Abra o ficheiro wp-config.php (localizado na raiz da instalação do WordPress) e adicione uma linha antes do comentário /* That's all, stop editing! */:

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

Se o fornecedor limitar estritamente a memória PHP ao nível do servidor, esta diretiva não funcionará, então só há uma saída: mudar o plano ou o alojamento. O alojamento WordPress gerido (SiteGround, WP Engine, Kinsta) configura limites adequados de raiz e o problema de memória praticamente nunca se encontra lá.

4. Diagnóstico através do WP_DEBUG

Por vezes, nem os plugins, nem o tema, nem a memória são culpados, a causa do WSOD escapa. Então precisa de fazer o WordPress dizer-lhe exatamente o que correu mal.

O WordPress tem um depurador integrado WP_DEBUG há décadas. Por defeito, está desativado (ecrã branco em vez de erros, a ideia é não expor o interior do site aos visitantes). Mas para o administrador, este modo é inestimável.

Adicione ao wp-config.php:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

O que acontece:

• WP_DEBUG ativa o modo de depuração;
• WP_DEBUG_LOG escreve os erros no ficheiro wp-content/debug.log, conveniente para ler sem mostrar aos visitantes;
• WP_DEBUG_DISPLAY com o valor false esconde os erros do ecrã (vê um ecrã branco, mas os logs são escritos).

Após ativar, abra o site, reproduza o problema e veja em wp-content/debug.log. Haverá uma linha com o ficheiro, número da linha e tipo de erro, por exemplo, Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. Esta é a morada exata do problema.

Importante: não deixe WP_DEBUG ativado em produção após o diagnóstico, os logs crescem rapidamente e podem encher o espaço em disco.

5. Modo de Recuperação, o salvador integrado do WordPress 5.2+

Desde a versão 5.2, o WordPress pode detetar erros fatais por si próprio e oferecer um caminho alternativo. O Modo de Recuperação (recovery mode) é uma funcionalidade que muitos administradores ainda não usam simplesmente porque não a conhecem.

Como funciona. Quando o código PHP num plugin ou tema causa um erro fatal, o WordPress interceta-o, para a extensão problemática e envia um email para o email do administrador. O email contém um link que abre o acesso ao painel de administração contornando o código problemático. Inicia sessão, vê o plugin que falhou marcado como "causou erro", desativa-o e o site está vivo novamente. Sem FTP, sem renomear pastas.

Limitações do Modo de Recuperação:

• O link é válido por um tempo limitado (cerca de um dia) e está vinculado a um endereço IP;
• Requer o envio de correio configurado a partir do site (plugin SMTP ou correio do alojamento);
• Não salva de erros ao nível do servidor (falta de memória, .htaccess corrompido).

E, no entanto, se o email chegou, poupa uma dúzia de minutos de nervos e movimentos de FTP.

Veja um pequeno guia sobre como corrigir o WSOD, todos os métodos descritos com demonstração ao vivo:

⁉️🤔 Perguntas frequentes

Porque é que o ecrã branco aparece apenas no painel de administração, mas o site abre normalmente?

O erro está localizado em código que é executado apenas no painel de controlo: uma metabox de plugin, página de configurações do tema, widget de administração personalizado. Desative os plugins instalados recentemente um a um, o culpado será encontrado rapidamente. Se não ajudar, ative WP_DEBUG_LOG e verifique o log após tentar iniciar sessão no painel de administração.

Ecrã branco apenas numa página de artigo ou entrada, o que é?

Muito provavelmente, o problema está no conteúdo da entrada específica: um shortcode de um plugin inexistente, HTML corrompido no texto, conflito com campos personalizados. Abra a entrada através de Edição Rápida no painel de administração e altere temporariamente o estado para "Rascunho". A página carrega? Então investigue o interior do conteúdo.

Pode o WSOD ser evitado completamente no futuro?

Eliminá-lo completamente, não, mas minimizar o risco é realista. Três regras: (1) teste sempre as atualizações de plugins e temas numa cópia de teste do site antes de implementar em produção; (2) mantenha cópias de segurança diárias dos ficheiros e da base de dados; (3) não instale plugins e temas de fontes questionáveis, especialmente versões nulled.

O Modo de Recuperação não enviou um email, o que fazer?

O correio de um site WordPress sem um plugin SMTP configurado funciona de forma instável. Configure SMTP (Post SMTP, FluentSMTP ou WP Mail SMTP) como medida preventiva. Se o email já não chegou, volte ao método FTP da secção 1, funciona sempre.

Quanto tempo dura o link do Modo de Recuperação?

O link é válido por 24 horas (mais precisamente, até o token nonce expirar). Depois disso, precisa de reproduzir o erro novamente, o WordPress enviará o email outra vez.

O que fazer se nada ajudou?

Se os quatro métodos acima e o Modo de Recuperação não trouxeram o site de volta, o problema é mais profundo. Talvez o ficheiro .htaccess esteja danificado (renomeie-o e inicie sessão no painel de administração, o WordPress criará um novo através de "Configurações → Links permanentes → Guardar"). Ou incompatibilidade de versão PHP: o WordPress moderno requer PHP 7.4+, mas o alojamento pode ainda ter PHP 5.6.

Outra ferramenta de diagnóstico é o plugin Health Check & Troubleshooting da equipa do WordPress.org. Ele pode lançar uma sessão de modo seguro: desativa todos os plugins e muda para o tema padrão, mas apenas para o seu navegador (os visitantes veem o site normal). Com ele, pode ativar plugins em segurança um a um e apanhar o culpado sem tocar na produção.

Sem tempo para investigar, mas o site precisa de estar no ar agora mesmo? Restaure a cópia de segurança. Se não houver cópia de segurança, uma lição para o futuro: cópias de segurança automáticas diárias custam alguns euros por mês e pagam-se a si próprias no primeiro dia de um desastre. Praticamente todos os alojamentos oferecem esta funcionalidade no painel de controlo.

E o mais importante, não tema o WSOD. É desagradável, mas tem solução. Agora tem um algoritmo de ação passo a passo, não pânico e um ecrã vazio.